[swift-evolution] final + lazy + fileprivate modifiers

Tino Heth 2th at gmx.de
Mon Feb 13 10:50:45 CST 2017

> Personally I’d prefer if we all together with the core team set down (virtually ^^) and:
> Fully re-evaluated all the access modifier mess and sketched a new future oriented model on how this should have been regardless it’s breaking change or not.
imho the current situation is an anti-sweetspot:
It lacks the elegant simplicity of the original model, but still isn't powerful enough for many things.
> Communicated the corrected model with the community.
> Only after #2 we should made a decision on how to proceed.
> The reason I see this that way, because some part of the language seems to be a rushed mistake that everyone should now live with, just because we seek for ABI stability, we are unable to build a rocket, because our hands are tied.
Yes — and I would really appreciate if not only this topic is reviewed with the added experience of real-life usage of Swift.
Maybe there are some things that are to basic even for the list of commonly rejected proposals*, because they are either unthinkable or seem to large for the evolution process (there is a strong preference for proposals that are only small refinements for the language, so it is easy to lose sight of the big picture).
I wouldn't expect actual changes triggered by such a discussion, but I'm also very interested in getting to know the motives of fundamental decisions that happened before Swift went Open source.

- Tino

* Things like:
- Are Repeat-While and While-loops really necessary? I bet many never use them
- Why are optionals modelled as enums? Union types have some nice characteristics for this use case
- What's the point of enums with associated values anyways? Aren't case classes nicer?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170213/7d81ec25/attachment.html>

More information about the swift-evolution mailing list