[swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

Wed Oct 4 23:35:20 CDT 2017

Just as one small data point, I had no idea private extensions still applied fileprivate access to all members (I thought that had changed when SE-0169 was implemented). I’ve been using private extensions extensively because I thought they *did* apply private access to everything, not fileprivate.

Now knowing this isn’t the case, I can only imagine how many other people would be tripped up be this (especially people who haven’t followed Swift Evolution). I definitely think this inconsistency needs to be fixed.

> On Oct 4, 2017, at 8:48 PM, BJ Homer via swift-evolution <swift-evolution at swift.org> wrote:
> 
> It certainly could break *some* code. But it only breaks code written by an author who wrote ‘private extension’ knowing that ‘fileprivate extension’ was also an option, but still intended it to be shared with the whole file. (If that code was from Swift 2, it would have already been migrated to ‘fileprivate extension’ by the 2->3 migrator.)
> 
> So existing code that says ‘private extension’ was written in a Swift 3 or 4 era when ‘fileprivate’ was an option. If the goal was specifically to share it with the whole file, it seems likely that most authors would have used ‘fileprivate extension’ instead of ‘private extension’, as that better communicates the intention. Regardless, though, we could check against the Swift source compatibility test suite to see how widespread that is.
> 
> Regardless, I think this change makes Swift a better language, and I’m in favor of it.
> 
> -BJ
> 
>> On Oct 4, 2017, at 9:10 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>>> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> 
>>>> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>>> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> 
>>>>> 
>>>>> Sent from my iPad
>>>>> 
>>>>>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>>> 
>>>>>>> On 01.10.2017 1:18, Chris Lattner wrote:
>>>>>>>>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>>>>> 
>>>>>>>>> Vladimir, I agree with you on that change, but it’s a separate topic from this one.
>>>>>>>>> 
>>>>>>>>> Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have.
>>>>>>>> Agreed.  The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability.
>>>>>>> 
>>>>>>> So we have to live with *protected* extension inconsistency for very long time just because core team don't want to even discuss _this particular_ inconsistency(when access level in *private extension* must be private, not fileprivate)?
>>>>>>> 
>>>>>>> Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'.
>>>>>>> 
>>>>>>> Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this)
>>>>>> 
>>>>>> I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter.
>>>>> 
>>>>> I agree with this in principle but would not want to see it become a slippery slope back into extremely long access control discussions.
>>>>> 
>>>> 
>>>> As I've said elsewhere, I too agree with this in principle. I agree with Jordan that the current state of things is justifiable but the alternative would be somewhat superior, agree that in a vacuum this very narrow and specific discussion might be warranted, and agree also that this could be a very slippery slide down a very steep slope.
>>> 
>>> Same here. It’s the only grudge I have left with the current access control situation. I remember Doug Gregor and John McCall discussing this during the last access control proposal. And I wouldn’t mind having a very narrow discussion about only this.
>>> 
>>> I organize my types into extensions for each conformance and for each access control. I can currently implicitly apply public or fileprivate to all members of an extension but I have no way of doing the same for private. That’s why I think it should be fixed.
>> 
>> This will break a bunch of code because `private extension` has always meant `fileprivate extension`. Even Swift 3 had this same behavior. Lowering the access level of the extension members will hide a bunch of code that was visible to the file. 
>> 
>> 169 was not a breaking change but this “fix” would have made it a breaking change. I doubt 169 would had been accepted if it was a breaking change. I don’t think it’s worth it. 
>> 
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>> 
>> 
>> 
>>> 
>>>>>> 
>>>>>> (I maintain that the current model does not include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.)
>>>>>> 
>>>>>> 
>>>>>> I agree that changing the behavior of all access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.)
>>>>>> 
>>>>>> Jordan
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
>> _______________________________________________
>> 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/20171004/9c298a86/attachment-0001.html>