[swift-evolution] Learning from SE-0025, a breeding group for Swift proposals

[Ted Kremenek]

> On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> 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".

Hi David,

I think this is a well-intentioned suggestion, but I see several problems with this approach.

The first problem is one of expectations.  Developers invest in using features because they want to write code to get their work done.  Once someone starts shipping something that depends on a feature they get very grumpy when it gets taken away.  It doesn’t really matter if the feature is “official” or not.  Once enough people invest in using a feature it becomes “unofficially” part of the language.  IMO, that doesn’t promote a model where changes to the language are well-considered.

The second problem is that within the compiler there is still vestigial remnants of earlier days in Swift when we were doing a lot of experimentation.  Before Swift 1 was released we toyed around quite a bit with the syntax, the type checker, pretty much everything.  We’d have a design meeting and then immediately someone would go implement something in the compiler.  During those days such rapid experimentation was helpful to see how ideas would work out and to get a feel for the language we were crafting.  But as time has gone by we’ve repeatedly found ourselves removing cruft from the compiler’s implementation and fixing bugs from technical debt of incompletely implemented features or features that didn’t work well together.  Features added for the purpose of experimentation are almost always incomplete — it’s the very nature of experimentation.  It is also very easy to convince yourself that a new language feature “works” when you try it out on a few examples.

No design process is going to be perfect.  We made a lot design decisions before Swift was publicly announced that were made based on our intuition and experiences, but really those decisions weren’t evaluated until people started writing a lot of Swift code.  We then have gone back — several times — and have revised core design decisions in the language based on learning from real-world usage of Swift.  With the access control saga I think we saw another instance of that story: a lot of discussion happened in the Swift 3 timeframe, but some important factors/implications of the design being discussed that are now obvious in hindsight just weren’t apparent when the discussions were happening.  I believe some number of these sagas are inevitable, and hopefully we learn from them to better inform our design decisions in the future.

I know the idea behind having a “-swift-version next” is to allow people to invest in experimental ideas to provide real feedback, but I don’t think this encourages good language design and many developers would be fearful of using such experimental features.  Those that fall in love with an experimental feature would likely fervently defend their existence, even if they end up being a bad idea.  It’s also not clear by what criteria we would take experimental features into the compiler in the first place, and adding more cruft into the compiler could be very detrimental to its implementation quality.

As Chris said, Xcode betas really are a good time for people to provide feedback about features.  With Swift 3 some of that feedback was delayed because of the upheaval caused by the Grand API Renaming and the migration work projects needed to do to go from Swift 2 to Swift 3.  Going forward the intent is that the evolution of Swift provides a much smoother, continuous experience for users, and allows them to try out new features of the language more easily and thus possible provide feedback sooner.

Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170420/05894c8f/attachment.html>