[swift-evolution] access control

[Matthew Johnson]

> On Jan 27, 2016, at 10:35 AM, David Owens II via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Sorry if I've missed it, but I didn't see these comments addressed in a way that I thought was sufficient.
> 
>> On Jan 25, 2016, at 3:47 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> The place where I'm most concerned about this is in playgrounds.  If
>> we're going to use them to teach programming, it should be possible to
>> demonstrate encapsulation there.
> 
> Playgrounds support multiple files. Doesn't this alleviate this problem? Of course you can't model Swift's model in a single-file, but that's by-design. 
> 
> 
>> On Jan 27, 2016, at 7:44 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Aside from that, as has been noted several times, the most common need is “current scope only”.  It would be nice if that could actually be expressed in the language.  There are often valid reasons to organize code such that more than one scope exists in the same file without a desire to share implementation details between the scopes.  Right now there is a tension between code layout and the visibility semantics we actually desire and intend.
> 
> I disagree. You can pattern your code so that this appears to be the "most common need", but you can also pattern identical functioning code so that this feature doesn't even work.
> 
> For instance, I know in my code, this really isn't the "most common need". In fact, in nearly all of my code, local would be completely useless because I put the majority of my APIs in extensions. I like to model the data on the type definition and the APIs in extensions.
> 
> This proposal would make using extensions as a means of grouping functionality impossible:
> 
> struct Foo {
>     local count: Int = 0
> }
> 
> extension Foo {
>     func hidden() { count += 1 }  // error: count is not visible
> }
> 
> So now we have to arbitrarily make `count` private, move `hidden()` into the `Foo` definition, or make `local` a whole lot more complicated.
> 
> If you design and write your code like you do in other languages, then ok, I can see a margin of usefulness from `local`. 

Sure, if you use this method of organizing code `local` would be less useful and the need for file-level access would be much more common.  I can see the benefits of organizing code this way; it is how code is organized in functional languages.  When you follow this approach `local` would still be useful if you have helpers inside an extension.  But you are right, it would not be the most common need.

I haven’t seen much Swift code actually organized this way in the wild.  Maybe that will change, maybe not.  But I stand by the assertion that they way most people are writing Swift today leads to “current scope only” is the most common need in practice.

Both `local` and `private` are useful.  I would like to see both of them in the language.

-Matthew

> 
> -David
> _______________________________________________
> 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/20160127/f773c17b/attachment.html>