[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu]

On Fri, Mar 24, 2017 at 8:45 PM, Drew Crawford via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
>
> On March 24, 2017 at 7:53:09 PM, Jonathan Hull (jhull at gbis.com) wrote:
>
> It isn’t the fact that there are multiple models, but they way those
> models interact with each other in the brain.  You can actually have lots
> of different models without causing confusion, as long as the models fit
> well together.  It also isn’t the number of access levels that is a
> problem.  For example, you can have a ton of shirt sizes (XS, S, M, L, XL,
> XXL, 3XL) and it doesn’t cause more confusion as you add more sizes because
> they don’t conflict with one another.
>
> A big part of the issue with our current access scheme is how similar the
> concepts are without being the same.  That is then made worse by the fact
> that they have been given similar names.
>
> It is unclear what distinction you intend to draw here.  For example,
> value types and reference types are similar without being the same.  The
> names of both concepts also contain the substring "type".  So the
> difference you draw between that situation and the private/fileprivate
> situation is not immediately clear.
>
> Note also that your list above is a list of typical stumbling blocks for
> new programmers in most languages. Swift has actually done a remarkable job
> with most of these through careful design of the way that they are framed /
> exposed to the programmer.  In general, these things are well separated
> from each other.
>
> I do not think Swift has done even a *good* job framing these concepts.
> For example
>
> protocol Foo {
>
>     func foo() { }
>
> }
>
> extension Foo {
>
>     func bar() {}
>
> }
>
> One of these is statically dispatched and the other one is dynamically
> dispatched.  I would guess the vast majority of Swift developers are not
> aware there's a difference at all, let alone can explain why one is slower
> in a benchmark.
>
> Swift is good at giving programmers flexibility in their tools.  Here we
> have two superficially similar tools with slightly different features and
> performance characteristics, and for most problems it does not even matter
> which one you choose.  IMO shipping a full toolbox with plenty of overlap
> is one of the core values of Swift.
>

I could hardly disagree more with this opinion. Figuring out what's
statically vs. dynamically dispatched can be very difficult with Swift.
Although each rule is defensible when dissected individually, the overall
scheme once `final`, `dynamic`, `@objc`, etc. are included is supremely
inelegant. Far from being an example of a core value, I would say it's an
example of a major weakness. I see one of the key goals of the Swift
evolution process as reducing and, where possible, eliminating such designs
from the language.

I would suggest that the practicable reason we are talking about removing
> private/fileprivate instead of protocol/extension or reference/value is
> that while `extension` etc. makes your code more powerful, `private` makes
> it less powerful.  It is not obvious to everyone why less power is
> desirable and so here we are.
>
> Do you feel that allowing both scoped private & file-based private is
> actually important enough to warrant the significant design work it would
> take to bring it up to par with these other features?
>
> It is not clear to me what design work is actually outstanding.  I would
> love to see submodules, but that seems only indirectly related to
> visibility keywords, and I'm not aware of what you seem to believe we need.
>
> I do use scoped access extensively, and I've left some examples of that
> upthread.
>
> It is not impossible, but it really doesn’t feel worth the effort to me
> (say compared to using that time/energy/thought to check off features from
> the generics manifesto).
>
> Rather, as Carl Brown argued, it would take a lot of time/energy to
> migrate even the official projects off of private/fileprivate.  Keeping
> what we have is free, change is what is expensive, and this proposal is
> change.
>
>  In general, Swift is an opinionated language
>
> Not clear what you mean here either.  Swift is clearly less opinionated
> than ObjC for example.  I am having trouble connecting this claim to a
> practical application.
>
> _______________________________________________
> 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/20170324/dcf3875d/attachment.html>