<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 class=""><blockquote type="cite" class=""><div class="">On Apr 18, 2017, at 1: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=""><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></blockquote><br class=""></div>There are a number of interesting examples in how other languages handle evolution.<div class=""><br class=""></div><div class="">For a language like ECMAScript, proposals follow a specific vetting process</div><div class=""><a href="https://tc39.github.io/process-document/" class="">https://tc39.github.io/process-document/</a></div><div class=""><br class=""></div><div class="">- proposals can proceed independent of one another </div><div class="">- a proposal is responsible for the full formal definition (think - if one of the processes was to update a Swift language specification)</div><div class="">- the process includes a feedback stage based on usage and implementation</div><div class="">- the process is not complete until there is full implementation in language implementations - the implementation challenges are feedback back into the process</div><div class="">- there isn’t a single review gate between something being a proposal and an accepted language feature</div><div class="">- the language is on a release schedule, and proposals are put into the language release schedule when complete. Language releases (e.g. ES2017) are not tied to a “MVP” set of proposed features</div><div class=""><div class=""><div class="">- because implementation is required as part of the process, ideally you do not have issues where the language spec is released with no implementations</div><div class=""><br class=""></div><div class="">I don’t know if the level of formalism here would work for Swift yet, to be honest. Swift still has known deficiencies that make sense to have be focus areas for a language revision. I suspect features within that revision schedule may also wind up being too interdependent. This division of labor also only makes sense when you have enough independent parties trying to drive evolution and implementation - Swift just might not be big enough yet.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">Here's my rough idea:</div><div class=""><ul class=""><li class="">The Swift compiler gains a new off-by-default `next` version triggerable with the `-swift-version next` flag.</li><li class="">All controversial proposals start their implementation in that version.</li><li class="">Once one of the poposals feels stable enough, it is brought into an official version.</li><li class="">Developers would be encouraged to try the `next` features while being warned that source compatibility on that version will *not* be garanteed.</li></ul></div></blockquote><div class=""><br class=""></div></div><div class="">Re: -swift-version next, care would have to be taken to make sure this doesn’t mean that multiple language features aren’t being developed within the same branch. There is also the risk that such features are *not* going to make the next release, or any release, due to implementation challenges or later user feedback. I’d recommend that this instead be an experimental version focused on periodic merging of beta features - there isn’t a requirement that such be a single tree, or be @ apple/swift, or to only contain features which have hit a certain process maturity stage.</div><div class=""></div></div><div class=""><br class=""></div><div class="">I believe there are still challenges for users to experiment with such versions - in particular, I believe the majority of Apple platforms still don’t support building with anything other than an official release. I might expect a vendor running a store to require an official toolchain, but I believe even adhoc and local/simulator development is required to be on shipped toolchain releases.</div></div><div class=""><br class=""></div><div class="">-DW</div></body></html>