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

[Wallacy]

Em sex, 1 de abr de 2016 às 01:31, Ilya Belenkiy via swift-evolution <
swift-evolution at swift.org> escreveu:

> With these names we lose consistency. The current scheme makes it very
> clear that each next level is a subset of the previous level. With
> "internal", fileprivate looks out of place.
>
> We have several goals for all the names:
> 1) obvious
> 2) using standard terms
> 3) short
> 4) consistent
>
> This discussion shows that we cannot have all of them. We have to pick
> something at the expense of something else.
>
> For me, the order of importance is 2, 4, 1, 3, and I am pretty sure that
> with this order
>
> public
> moduleprivate
> fileprivate
> private
>
> is the best so far.
>
> public
> internal
> fileprivate
> private
>
> is not as consistent. It's also not as obvious, given that many people
> proposed to use internal to mean fileprivate. The biggest advantages of
> these names are that there is less change and short words. If these are the
> most important goals, then my original proposal is even better:
>
> public
> internal
> private
> scoped
>
>
For me this is good, keep  untouched the actual public/internal/private and
just add a new word for the new access level.

It's a non-breaking change, everything retains its meaning, the added name
> is very clear, and all the names are very short. The biggest problem here
> is "private" -- it's not the most private that the language provides, and
> most people would expect that.
>
> Here is another one like that (it solves the "private" problem at the
> expense of using non-standard terms):
>
> public
> internal
> local
> scoped
>
> My main point is that we cannot have everything. We have to pick the order
> of importance.
>
> We heard many times that "short" is not the goal of Swift. Instead, it's
> clarity. If this is the case, then I think
>
> public
> moduleprivate
> fileprivate
> private
>
> is the clearest we've seen. Nobody could possibly be confused about the
> meaning of these names. I doubt that moduleprivate will be required to
> spell out in any style guide, but even so, it's not so bad. We have many
> frequently used class names that are much longer.
>
> On Thu, Mar 31, 2016 at 12:22 AM Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> On Mar 23, 2016, at 10:13 PM, Chris Lattner <clattner at apple.com> wrote:
>> > How about we continue this trend, and follow other existing Swift
>> keywords that merge two lowercase words (associatedtype, typealias, etc),
>> and use:
>> >
>> >       public
>> >       moduleprivate
>> >       fileprivate
>> >       private
>> >
>> > The advantages, as I see them are:
>> > 1) We keep public and private meaning the “right” and “obvious” things.
>> > 2) The declmodifiers “read” correctly.
>> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
>> awkward parenthesized keyword approach.
>> > 4) The unusual ones would be “googable”.
>> > 5) Support for named submodules could be “dropped in” by putting the
>> submodule name/path in parens: private(foo.bar.baz) or
>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
>> natural than putting keywords in parens.
>>
>> I’ve seen a number of concerns on this list about moduleprivate, and how
>> it penalizes folks who want to explicitly write their access control.  I’ve
>> come to think that there is yes-another possible path forward here (which I
>> haven’t seen mentioned so far):
>>
>> public
>> internal
>> fileprivate
>> private
>>
>> The advantages, as I see them are:
>> 1) We keep public and private meaning the “right” and “obvious” things.
>> 2) The declmodifiers “read” correctly.
>> 3) Compared to Swift 2, there is almost no change.  The only thing that
>> changes is that some uses of Swift 2 “private” will be migrated to
>> “fileprivate”, which makes the intent of the code much more clear.
>> 4) fileprivate is the unusual and
>> not-really-precedented-in-other-languages modifier, and it would still be
>> “googable”.
>> 5) The addresses the “excessively long” declmodifier problem that several
>> people are concerned with.
>> 6) Support for named submodules could be “dropped in” by parameterizing
>> “internal”.
>>
>> Thoughts?
>>
>> -Chris
>> _______________________________________________
>> 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/20160401/9aeb3a21/attachment.html>