<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 12, 2017, at 7:16 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"></blockquote></div></div></div></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jun 12, 2017, at 12:47 PM, Paul Cantrell <<a href="mailto:cantrell@pobox.com" class="">cantrell@pobox.com</a>> wrote:<br class=""><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Concern #2 is that it’s hard to know what to do with a proposal when the ideal answer is “we need to see how it plays out in practice and then decide whether to accept it.” Theoretical discussion untempered by practical prototyping is a great way for a group to talk itself into a bad idea. (This will especially be a problem with future work to build out generics & existentials.)<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I agree. Do you have specific thoughts here on what could be done differently?</span></div></blockquote></div><br class=""><div class="">I think we can partially solve this by having an extra stage of “stability” in our documentation. Right now, things are either officially part of the language or they aren’t (with a very short beta period between WWDC and the Fall). What I would like to see in the documentation is a notion of how sure we are of a particular piece of API or syntax.</div><div class=""><br class=""></div><div class=""><b class="">Unstable</b> - This is actively under development/design and should be expected to change. It is not safe to build frameworks on top of this.</div><div class=""><br class=""></div><div class=""><b class="">Pre-Stable</b> - We think we have a design which works, but we need to see how it works in the larger ecosystem before guaranteeing stability. Anything built on this should be prepared for potentially large changes in the future, and be marked “Pre-Stable” themselves.</div><div class=""><br class=""></div><div class=""><b class="">Stable</b> - This has been extensively tested in the actual swift ecosystem and proven itself a useful addition. Any changes to this in the future are guaranteed to either be source-compatible or have a full depreciation cycle. It is completely safe to build on.</div><div class=""><br class=""></div><div class="">I think being explicit about what we expect to change in the future, and having a notion of “stable” that is truly stable will give us a lot more freedom to experiment as well as room to fix our mistakes.</div></div></div></blockquote><br class=""></div><div>I’m not sure documentation is sufficient… If I only wanted to use the “stable” features, would I have to read the docs on every standard library type I use? And what about unstable or pre-stable compiler features? It’s not like I can right-click on a var and get the type inference rules, for example.</div><div><br class=""></div><div><div class="">Now, I wouldn’t mind the ability to vote (or at the core team’s discretion) that we accept a proposal into a separate “pre-stable” or “staging” <i class="">toolchain</i>, with the understanding that if it doesn’t cause any major issues it’ll automatically be accepted for the next major release. If issues are found, then we’d have a chance to re-review & refine the proposal before committing it to the main toolchain and its source-compatibility requirements. If, upon re-review, the proposal is rejected, it would be deprecated in the next major release’s staging toolchain and removed in the major release after that.</div><div class=""><br class=""></div><div class="">To clarify, the timeline would be something like:</div><div class=""><br class=""></div><div class="">Prior to Swift N: We accept SE-xxxx for Swift N, as well as SE-yyyy and SE-zzzz for Swift N Staging.</div><div class="">Release Swift N:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Standard: implements SE-xxxx</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Staging: implements SE-yyyy and SE-zzzz</div><div class="">Prior to Swift N+1: We accept a proposal to revert SE-zzzz because it turns out to be a horrible idea</div><div class="">Release Swift N+1:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Standard: implements SE-xxxx, SE-yyyy</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Staging: deprecates SE-zzzz</div><div class="">Release Swift N+2:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Standard: implements SE-xxxx, SE-yyyy</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Staging: reverts SE-zzzz</div><div class=""><br class=""></div></div>This would give the people whose code relies on SE-zzzz probably between 1-2 years to find a work-around, given the current pace of major releases, and depending on exactly where in the timeline the problems get discovered. (As a last resort, you could leave the Swift N or N+1 staging toolchains installed, refactor any features relying on SE-zzzz into their own module, and move the rest of your app’s code on to Swift N+2. Certainly not ideal, but AFAIK, it's an option.) And if you’re worried about it, just use the stable toolchain.<div class=""><br class=""></div><div class="">I do have some concerns, though… My understanding is that Rust does something similar and has an “experimental” compiler release… Apparently, all the “cool” stuff is done there, which makes it the “standard" compiler, and relegates the actually-stable compiler to “old version” status. Or so I hear, anyway. I haven’t really used it much. Anyway, I wouldn’t want us to get in a position where everyone’s using some feature of the staging toolchain, but we can’t merge it into the stable toolchain because maybe it breaks some niche use-case that we need to support or something. We do have one thing going for us, though, that Rust doesn’t… a large portion of Swift’s user base needs to ship to Apple's App stores, and Apple controls what toolchains you’re allowed to use for that. OTOH, if we say "no staging toolchain for the app store”, then we have to ask if enough people will use it for the issues to be found.</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></body></html>