> On Apr 18, 2017, at 1:00 AM, David Hart via swift-evolution
> <[email protected]> wrote:
>
> 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?
>
> Then I listened to the latest episode of the excellent [Swift Unwrapped
> podcast](https://spec.fm/podcasts/swift-unwrapped
> <https://spec.fm/podcasts/swift-unwrapped>) 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.
There are a number of interesting examples in how other languages handle
evolution.
For a language like ECMAScript, proposals follow a specific vetting process
https://tc39.github.io/process-document/
<https://tc39.github.io/process-document/>
- proposals can proceed independent of one another
- a proposal is responsible for the full formal definition (think - if one of
the processes was to update a Swift language specification)
- the process includes a feedback stage based on usage and implementation
- the process is not complete until there is full implementation in language
implementations - the implementation challenges are feedback back into the
process
- there isn’t a single review gate between something being a proposal and an
accepted language feature
- 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
- because implementation is required as part of the process, ideally you do not
have issues where the language spec is released with no implementations
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.
> Here's my rough idea:
> The Swift compiler gains a new off-by-default `next` version triggerable with
> the `-swift-version next` flag.
> All controversial proposals start their implementation in that version.
> Once one of the poposals feels stable enough, it is brought into an official
> version.
> Developers would be encouraged to try the `next` features while being warned
> that source compatibility on that version will *not* be garanteed.
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.
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.
-DW
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
