[swift-evolution] SE-0025: Scoped Access Level, next steps

[David Owens II]

I have types where I declare their members (some public, some private) and use extensions to provide the API implementations of protocols. 

These implementations use data that is not public to the type. A file-based access level is the only one that works for me. 

This is actually the common case for me. 

Sent from my iPhone

> On Mar 25, 2016, at 10:11 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> These are special cases — both file-private and module-private is something that is fairly unusual
>> 
>> afaics this is the third time someone mentions that "file-private" is uncommon — so I think it's time someone dissents:
>> That statement is at least subjective… right now, "file-private" is one of three access levels, and I wouldn't dare to say either is more or less important than the others.
>> 
>> I never encountered situations with the current model where I missed a new "private"-level, and maybe "private" will become fairly unusual for the code I'll be writing.
>> 
>> In my existing code, the new meaning of private wouldn't break much, but the current meaning doesn't hurt me, and there are cases where "file-private" is needed.
>> 
>> None the less, I don't care much about the "ugliness" of "fileprivate" — but not because I perceive it as unusual:
>> I just expect that code completion will do the typing for me, so maybe "f" will be all I have to write (half the characters of "pr" ;-)
> 
> I cannot come up with a single use-case in my code for fileprivate and would love
> some real world examples where you'd want visibility in a single file but not across
> an entire module.
> 
> The fileprivate behavior has been a bugaboo of mine for some time, particularly in 
> playground use. 
> 
> As far as I'm concerned, the control I really want is public,  intra-modular, private, and 
> private-even-to-extensions-and-subclasses. I assume the latter is a no-go.
> 
> -- E
> 
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution