<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div class="bloop_markdown" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);"><p style="margin: 15px 0px; -webkit-margin-before: 0px;" class="">Personally I’d prefer if we all together with the core team set down (virtually ^^) and:</p><ol style="margin: 15px 0px;" class=""><li style="margin: 15px 0px; -webkit-margin-before: 0px;" class="">Fully re-evaluated all the access modifier mess and sketched a new future oriented model on how this should have been<span class="Apple-converted-space"> </span><em style="-webkit-margin-before: 0px;" class="">regardless</em><span class="Apple-converted-space"> </span>it’s breaking change or not.</li></ol></div></div></blockquote><div>+1</div><div>imho the current situation is an anti-sweetspot:</div><div>It lacks the elegant simplicity of the original model, but still isn't powerful enough for many things.</div><blockquote type="cite" class=""><div class=""><div class="bloop_markdown" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(254, 254, 254);"><ol style="margin: 15px 0px;" class="" start="2"><li style="margin: 15px 0px;" class="">Communicated the<span class="Apple-converted-space"> </span><em style="-webkit-margin-before: 0px;" class="">corrected</em><span class="Apple-converted-space"> </span>model with the community.</li><li style="margin: 15px 0px;" class="">Only after #2 we should made a decision on how to proceed.</li></ol><p style="margin: 15px 0px;" class="">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.</p></div></div></blockquote></div>Yes — and I would really appreciate if not only this topic is reviewed with the added experience of real-life usage of Swift.<div class="">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).<div class="">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.</div><div class=""><br class=""></div><div class="">- Tino</div></div><div class=""><br class=""></div><div class="">* Things like:</div><div class="">- Are Repeat-While and While-loops really necessary? I bet many never use them</div><div class="">- Why are optionals modelled as enums? Union types have some nice characteristics for this use case</div><div class="">- What's the point of enums with associated values anyways? Aren't case classes nicer?</div><div class="">...</div></body></html>