<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On 19 Apr 2017, at 06:51, Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hello community,</div><div class=""><br class=""></div><div class="">I'm happy to see that SE-0169 got accepted and that we've patched the issues of SE-0025. But it's been a difficult process. And I can't stop asking myself if it could have been avoided. The crux of the problem is that source-compatibility is now becoming a very strong requirement. But at the same time, Swift is still missing some very big systems: reflection, property behaviours, a concurrency paradigm. How can we continue to push Swift boldly forward with very little leeway to correct our mistakes?</div><div class=""><br class=""></div><div class="">Then I listened to the latest episode of the excellent [Swift Unwrapped podcast](<a href="https://spec.fm/podcasts/swift-unwrapped" class="">https://spec.fm/podcasts/swift-unwrapped</a>) where they talk about the access control "saga" and ask themselves the same questions as above. One interesting idea got my attention: JavaScript has a natural breeding ground for future language features with Babel. For those who don't know, it's a transcompiler that compiles bleeding-edge JavaScript into versions supported in browsers. Perhaps Swift could also benefit from a similar experimentation time for each new proposal.</div></div></div></blockquote><br class=""></div><div>I listened to the same podcast (which is generally great btw, even if it doesn’t get all the details right), but they miss an important fact: Swift *does* have an important beta cycle (typically started at WWDC) for major releases of the language. One very important thing with Swift 4 vs Swift 3 is that hopefully there is no feature work for Swift 4 after WWDC, meaning that the only changes are those that are responding to developer usage experience with the new stuff.</div></div></blockquote><div><br></div><div>That's true. In that case, I think the problem with SE-0025 was that it was implemented very late in the Beta cycle (by no fault of the dev team, you had so much on your plate) so we had very little time to experiment with the feature.</div><div><br></div><div>Hopefully, with the tightening of scope in SE proposals, most can get implemented early in the beta cycle.</div><br><blockquote type="cite"><div><div>Also, it remains to be seen, but I strongly believe that we’ve ended up in a good place with access control. The process was painful, but worthwhile to reach a great result.</div></div></blockquote><div><br></div><div>I agree :) I just want to avoid painting ourselves in a backwards-compatibility-corner with another major feature.</div><br><blockquote type="cite"><div><div>-Chris</div><div><br class=""></div><br class=""></div></blockquote></body></html>