Agree, but again, I tried, and the answer was no, it’s not considered a bug and cannot be fixed without independent discussion. On Wed, Aug 9, 2017 at 16:51 David Hart <da...@hartbit.com> wrote:
> The last thing I want is to launch into a new round of discussions. I am > just hoping it can be considered as a straight bug that can be fixed > without any discussion. > > > On 9 Aug 2017, at 23:47, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > I brought this up after SE-0169, but it was deemed to be a separate issue > and any further consideration was declined. Let’s not initiate another > round of access control discussions. > On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > >> Actually, I think this is this way only as a relic from the original >> private/fileprivate proposal. Swift 3’s private has no meaning as an >> extension modifier, so it was made to alias to fileprivate. But >> since SE-0169 modified private’s meaning so that it would make sense as >> an extension modifier, I think we should fix this. >> >> On 9 Aug 2017, at 23:22, David Hart via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> That behaviour was never explicitly mentioned in SE-0169 but I agree its >> confusing. But I’m also fairly sure the only window to do anything about it >> is Swift 4. Everybody is really worn down by those access level discussions. >> >> For illustration, Vladimir is confused that: >> >> private extension Foo { >> func foo() {} >> } >> >> is equivalent to: >> >> fileprivate extension Foo { >> func foo() {} >> } >> >> making it accessible to another type in the same file: >> >> struct Bar { >> func bar(foo: Foo) { >> foo.foo() >> } >> } >> >> Aren't access levels on extensions supposed to define the default access >> level of the members of the extension?Is this a bug then? >> >> On 9 Aug 2017, at 21:18, Vladimir.S via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> Could someone remind please, was it decided to stick with 'private >> extension' means actually fileprivate access level for members declared in >> such extension or this could be discussed for Swift5? >> >> Currently, when private members are visible in type/extensions of that >> type in the same file, IMO there is no sense to treat 'private extension' >> as 'fileprivate extension', it is reasonable to group some private members >> of type into extension without making them fileprivate, and such members >> can be used from the type/other extensions. >> >> And also this is a huge inconsistency in my opinion: all other access >> modifiers 'work' as expected for extensions, but only 'private extension' >> means not what written, very surprising for one who don't expect this. >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution