[swift-evolution] private extension

Wed Aug 9 17:52:04 CDT 2017

I counter with the rationale for rejecting SE-0119
<https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000250.html>,
namely:

The review of "SE-0119: Remove access modifiers from extensions" ran from
> July 12...19. The proposal has been *rejected*.
>
> The majority of the feedback on this proposal was opposed to it, because
> it eliminated the useful ability to apply access control to a batch of
> methods and properties.

In other words, access modifiers are allowed on extensions for the express
purpose of being applied to the members in that extension. The fact that in
one of them currently does something *other* than what it says on the tin
is therefore problematic.

Nevin

On Wed, Aug 9, 2017 at 6:31 PM, Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>>>
>>>
> _______________________________________________
> 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/729dbd70/attachment.html>