[swift-evolution] private extension

[Xiaodi Wu]

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035885.html

On Wed, Aug 9, 2017 at 17:05 David Hart <david at hartbit.com> wrote:

> Do you a have a link to that discussion?
>
>
> On 10 Aug 2017, at 00:04, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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 <david at 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.wu at 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 at 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 at 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 at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170809/7c69e521/attachment.html>