> On Mar 30, 2016, at 9:06 AM, Paul Ossenbruggen via swift-evolution > <[email protected]> wrote: > > Associatedtype won’t be used nearly as often as these operators, I support > the rational there but not in this case as it will be seen far more often.
What do you mean? No-one needs to write out “moduleprivate” (because it is the default) and “fileprivate” is rarely needed. Since it is rare, it is *better* for it to be explicit. -Chris > > - Paul >> On Mar 30, 2016, at 8:28 AM, Ilya Belenkiy <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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] >> <mailto:[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] <mailto:[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] >>> <mailto:[email protected]>> wrote: >>> >>> >>> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution >>> <[email protected] <mailto:[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] <mailto:[email protected]> >>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <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
