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.
- Paul > On Mar 30, 2016, at 8:28 AM, Ilya Belenkiy <[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
