Hello community,
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) 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.
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.
As the vast majority of the Swift user base are still Apple platform
developers, I think it would be important for the success of that strategy that
the applications compiled with the `next` flag be accepted on the Apple stores
or it will reduce the group of developers ready to play in this
"breeding-group".
Any comments?
David.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
