[swift-evolution] SE-0025: Scoped Access Level, next steps

[Ilya Belenkiy]

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 <possen at gmail.com> 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 <
> swift-evolution at swift.org> 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 <matthew.judge at gmail.com>
> wrote:
>
>>
>>
>> On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution <
>> swift-evolution at swift.org> 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
>> > swift-evolution at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> _______________________________________________
> 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/20160330/3a036ac4/attachment.html>