> On Jun 12, 2017, at 7:16 PM, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>>> On Jun 12, 2017, at 12:47 PM, Paul Cantrell <cantr...@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_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
