[swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Xiaodi Wu]

A catalog of warts would definitely be a very important thing to continue
this discussion.

Keep in mind that one option that has been suggested on this list, and
which has received some positive thoughts from some core team members, is
to consider whether fileprivate vs. private is carrying its own weight or
whether, given real-world experience, we would be better off rolling back
to Swift 2 access levels.

The old design was self-consistent and kept things focused on what was
exposed to consumers of a module vs. what was not. The possible answers to
"who should be able to see or use this member?" were essentially: anyone at
all, anyone who can modify the declaration by opening another file, anyone
who can modify the declaration by scrolling up or down. Personally, within
a module, I'm not convinced that anything more fine-grained actually helps
you write safer code. For example, if the declaration is staring you in the
face on the monitor, how much does it really do for you to have it
inaccessible in another scope two lines down? In fact, with the possibility
of submodules, I wonder if we can simplify even further: public or not.
(public vs open is another discussion altogether; I'm leaving it aside at
the moment.)
On Fri, Dec 2, 2016 at 09:56 Shawn Erickson via swift-evolution <
swift-evolution at swift.org> wrote:

> I think at this point we really need to build a concrete catalog of
> "warts" that cause implementation details to leak out of a module to
> consumers of a module (by extension submodule). I think that is the first
> things that should be looked at when considering making any changes to the
> access controls. I have a few code examples that I likely can pull together
> from real code that highlights some issues and I bet others do as well.
>
> If we can collect these and look at them more holistically it would be
> helpful.
>
> I think email is likely a week way to do this... hum...
>
> -Shawn
> On Fri, Dec 2, 2016 at 7:51 AM Tino Heth via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Well, anyways, with Swift 3 it no longer is as simple as it is in Obj-C.
> New modifiers were introduced by request. I feel it's good and means
> everybody agrees Obj-C modifiers aren't sufficient for Swift.
>
> Well… no ;-)
> I'm not sure if there is a single thing in the universe where really
> everybody agrees on — right now, there is nothing more than a small group
> that has a vague agreement that there is room for improvement with the
> current access levels; most Swift users aren't even aware of this
> discussion at all (and most likely never will be ;-)
> [In situations like this, I really dislike the restrictions of this
> medium… with something like a Wiki, it would be much easier to set up a
> table so that we could at least collect the opinions from the people
> discussing now.]
>
> What I mean, initial arguments should apply no more and I hope Apple will
> not be too rigid with current status.
>
> I agree on the latter — but it might be the case that fundamental changes
> to Swift won't be considered anymore
>
> What I mean, though, the new introductions of access modifiers feel quite
> some "patchy".
>
> Yes… but imho your suggestion which adds additional levels makes it even
> more patchy:
> "protected" might be familiar to some developers, but "inner" is just a
> new magic word tacked onto the language.
> For me, this is actually the worst direction to take: Adding more and more
> new modifiers instead of really rethinking the topic from scratch.
>
>
> _______________________________________________
> 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/20161202/32c79462/attachment.html>