> On Apr 18, 2017, at 12:00 AM, David Hart via swift-evolution
> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
