> 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.
+1
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?
...
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution