[swift-evolution] A Comprehensive Rethink of Access Levels in Swift

*Introduction* There has been a deluge of discussion about access levels lately, all attempting to simplify the situation. Shortly after Swift 3 was released, many people realized that the new access modifier story was far more complex than the old one, and expressed the belief that the changes ma

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Thanks for that very well written pitch! Not only I think it summarizes most of the opinions I remember reading across the “myriad” of discussion, but it also proposes a quite reasonable reshaping of the system. There’s just (in my pov) one additional argument in favour of that proposal that I’

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Some very good points. But I’ll concentrate on what I disagree on to see where we can go from there. > On 23 Feb 2017, at 22:56, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Introduction > > There has been a deluge of discussion about access levels lately, all > attempting to sim

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Thanks for the feedback David, The whole design and motivation behind SE-0117 is that it is not rare to > want classes to be freely subclass-able internally while being closed to > subclassing externally. Do you have arguments to contradict the lengthy > points mentioned in the SE-0117 motivation

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 23, 2017, at 2:56 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > The prevailing view from recent discussions is that there should be just one > access level more fine-grained than ‘internal’, and it should be spelled > ‘private’. Let us leave aside for the moment what

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Very well written. Personally I am in favor of very simple systems and to put the responsibility for an application by the application developer (not a library developer). Though I understand that in some cases (Apple!) the developer is the end-customer, and this creates special circumstances w

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

I have to admit I don’t get why there’s so much push back about the whole public/open debate. I understand that completely removing the possibility to declare internally subclassable but publicly closed classes (like it did) might be harmful, but I’m still convinced that this use-case isn’t wort

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 25, 2017, at 12:12 AM, David Waite via swift-evolution > wrote: > >>> On Feb 23, 2017, at 2:56 PM, Nevin Brackett-Rozinsky via swift-evolution >>> wrote: >> > >> >> The prevailing view from recent discussions is that there should be just one >> access level mo

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> I think everybody agrees (at the very least to some degree) that the current > access level system is too complicated. I'm not sure about that — discussions about adding even more access levels aren't that uncommon, and peoples opinions tend to be surprisingly diverse. I guess that the rate of

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

+1000 This is the best of the proposals I have seen. I think it works by itself as a complete proposal, but since we are talking "comprehensive rethink", there is one use case which most of the proposals seem to miss. That is, what if I want to make a class which is both Public and Subclassa

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution > wrote: > > +1000 > > This is the best of the proposals I have seen. I think it works by itself as > a complete proposal, but since we are talking "comprehensive rethink", there > is one use case which mos

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> … > Additionally, the design allows ‘final’ to take any one of those visibility > levels as a parameter, to indicate that the type should be treated as ‘final’ > at and above the specified scope. Thus ‘final(public)’ prevents subclassing > outside the module, while ‘final(internal)’ prevents i

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution > wrote: > >> … >> Additionally, the design allows ‘final’ to take any one of those visibility >> levels as a parameter, to indicate that the type should be treated as >> ‘final’ at and above the specified scope. Thus ‘final(p

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 1:19 PM, Matthew Johnson wrote: >> On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> +1000 >> >> This is the best of the proposals I have seen. I think it works by itself >> as a complete proposal, but since we

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 1:43 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> … >>> Additionally, the design allows ‘final’ to take any one of those visibility >>> level

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 4:01 PM, Jonathan Hull wrote: > >> >> On Feb 25, 2017, at 1:19 PM, Matthew Johnson > > wrote: >>> On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> +1000 >>> >>> This is the bes

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 4:23 PM, Jonathan Hull wrote: > > >> On Feb 25, 2017, at 1:43 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Feb 25, 2017, at 3:27 PM, Kevin Nattinger via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 5:27 PM, Matthew Johnson via swift-evolution > wrote: > > The name that has usually been used for this is `closed`. But no word that > expresses a *restriction* is going to fit well into Swift’s access control > system. The approach of Swift’s access control system (whi

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Just joking of course (???) Exposure levels: World, Module, File, Type (= [ W | M | F | T ]) Access control: Read, Write, Override, Inheritable (= [ R | W | O | I ]) let api = Access(w, [r, -w, -o, -i]) // Access must always be statically resolved let mod = Access(m, [r, w, -o, i]) let cust = Ac

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Sent from my iPad > On Feb 26, 2017, at 10:58 AM, Charles Srstka wrote: > >> On Feb 25, 2017, at 5:27 PM, Matthew Johnson via swift-evolution >> wrote: >> >> The name that has usually been used for this is `closed`. But no word that >> expresses a *restriction* is going to fit well into S

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

This is a very elegant improvement. I think of “fileprivate” as “C legacy”. A submodule system seems to be a much better way to implement grouping a set of tightly coupled code elements. After all, there is no reasonable upper-limit on how large such a set of components might become and it woul

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 2:41 PM, Matthew Johnson wrote: > >> >> On Feb 25, 2017, at 4:01 PM, Jonathan Hull > > wrote: >> >>> >>> On Feb 25, 2017, at 1:19 PM, Matthew Johnson >> > wrote: On Feb 25, 2017, at 2:54 PM, Jonathan Hull via swi

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 26, 2017, at 10:47 PM, Jonathan Hull wrote: > >> >> On Feb 25, 2017, at 2:41 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 25, 2017, at 4:01 PM, Jonathan Hull >> > wrote: >>> On Feb 25, 2017, at 1:19 PM, Matthew Joh

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

What I like about ‘hidden’ vs export of nested submodules is that you can freely intermix those declarations in your code (like you can with private now). >>> >>> Yeah, this is an advantage. It’s not a bad idea, but it’s not a >>> replacement for submodules either. They are co

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Ah, the irony… Having argued against too much complexity, I now encountered an error in my software that shows why there might indeed be a need for “open” and “public”. In an API: class Foo { open func foo(options: Option ...) { foo(options) } open func foo(options: [Options]) { … } }

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Rien, your example shows two things (well, three, but one relates to variadic arguments not access levels). First, it shows the importance of being able to prevent external overrides of individual methods. I did not directly address that in my pitch, however it could easily use the same syntax as

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> as ‘closed’ is a rare niche case. If there is agreement on the importance of closed, imho we shouldn't even need variants of final: You could already build the required class hierarchies if the restriction that a subclass can't have higher visibility as its parent is lifted. Imho this should