I understand. The same is true about associatedtype. My iPhone just suggested it as a one word completion! I think the same will happen with these names. Chris Lattner already described the rationale in this thread, so I won't repeat it. I also originally wanted short names, but I think that we ended up with a good compromise (crystal clear, searchable keywords that are consistent with other keywords).
On Wed, Mar 30, 2016 at 10:54 AM Paul Ossenbruggen <[email protected]> wrote: > I understand the desire to wrap this up as it has gone on for a long time. > > I just don’t like the length and readability of the moduleprivate and > fileprivate names (and how auto correct is always “fixing” it for me when I > try to write about it). As I mentioned these will likely be used very often > in code and just don’t look very nice. These are potentially used on almost > every method, class, property and struct. I don’t think that we should use > something that is perhaps a little clearer in meaning but hard to read for > something that is used so frequently through the code. There are plenty of > places where you have to look something up the first time you encounter it > in any programming language and this explicitness is not a big enough win > to sacrifice readability. A single word keyword is a requirement for me. > > > > > On Mar 30, 2016, at 6:13 AM, Ilya Belenkiy via swift-evolution < > [email protected]> wrote: > > I am not sure if we will ever get another access level. If we do, great, > but given how long this discussion has been already, I am not counting on > it :-) > > Most likely, if we get more, it will be possible to describe it with a > simple word, or a combination of words or with some common abbreviations, > so I am not worried about extensibility. I think that the names in the > proposal are very consistent with Swift as it is today and will serve us > well. They are also completely unambiguous and don't depend on the reading > context, so if we come up with other ways to label access levels, it should > still be possible to either use these names for backward compatibility or > migrate them automatically to new names without any difference in semantics. > > We also needed to pick something. I waited for about a week to get > everybody's vote, and I think that I picked a compromise that we can all be > at least ok with. (I also originally wanted short single word names). I > think we should close the naming thread at this point. > On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge <[email protected]> > wrote: > >> >> >> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution < >> [email protected]> wrote: >> >> >> If Scala style access modifiers were adopted for Swift then a >> private(file) modifier would also be necessary to give the current private >> functionality. >> > >> > I could imagine having these options: >> > >> > public // visible to all everyone >> > private(scope-name, scope-name, …) // visible to specified scopes >> (plus current scope) >> > private // visible only to current scope >> > >> >> Allowing multiple "scope-name"s is a lot of flexibility and power, but >> not sure it's useful/worthwhile. >> >> For the current discussion, I would think "scope-name" should be limited >> to an enclosing scope only. So you can say "private(Outer)" from an Inner >> class or "private(#file)" from within a class, but not "private(ClassA)" >> from within ClassB. >> >> (This would also solve the ambiguity of how to reference the main ClassA >> or a specific extension to ClassA... "private(ClassA)" can only refer to >> whichever scope of ClassA you are currently in.) >> >> > scope-name could perhaps be: >> > >> > * A type name (or Self, which would mimic C++-style private, or perhaps >> even C++-style protected depending on how we treat inheritance) >> >> But, this is getting into type-based access which is beyond the scope of >> SE-0025 right? >> >> > * A module name (or #module for the current module) >> > * A file name string (or #file for the current file) >> > >> > And then the default would simply be `private(#module)`. >> > >> > Alternatively, the parameterized level could be given a different name, >> like `internal` or `shared`. If that were the case, then `#module` might >> simply be the default. >> > >> > -- >> > Brent Royal-Gordon >> > Architechies >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
