[swift-evolution] Swift phases and mis-timed proposals

[David Sweeris]

> On Jun 12, 2017, at 7:16 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Jun 12, 2017, at 12:47 PM, Paul Cantrell <cantrell at pobox.com> wrote:
>>> 
>>> 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.)
>> 
>> I agree.  Do you have specific thoughts here on what could be done differently?
> 
> 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.
> 
> Unstable - This is actively under development/design and should be expected to change. It is not safe to build frameworks on top of this.
> 
> Pre-Stable - 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.
> 
> Stable - 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.
> 
> 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.

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.

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” toolchain, 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.

To clarify, the timeline would be something like:

Prior to Swift N: We accept SE-xxxx for Swift N, as well as SE-yyyy and SE-zzzz for Swift N Staging.
Release Swift N:
	- Standard: implements SE-xxxx
	- Staging: implements SE-yyyy and SE-zzzz
Prior to Swift N+1: We accept a proposal to revert SE-zzzz because it turns out to be a horrible idea
Release Swift N+1:
	- Standard: implements SE-xxxx, SE-yyyy
	- Staging: deprecates SE-zzzz
Release Swift N+2:
	- Standard: implements SE-xxxx, SE-yyyy
	- Staging: reverts SE-zzzz

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.

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.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170613/dd43df33/attachment.html>