I read many times the "most users don't care about this" objection but I always 
considered it more like an argument for postponing something than removing it 
completely from the Swift equation (I believe I also read words like that from 
yourself, Chris), because there is a point about scheduling work to make the 
language more useful for more people faster. I'm still acting upon the belief 
that the Swift core team recognizes that the language still lacks a lot of 
absolutely basic and essential features, that every "power user" that pushes 
the boundaries of what Swift has to offer can't wait for to be added.

I would argue that there are 2 kinds of features to be considered in the 
process of a language's evolution:

1) additions and improvements that augment the type/abstraction system and make 
the language itself more expressive;
2) utility tools like alternate declarations for identical concepts (like 
keywords that add some syntactic sugar) and enhancements to the standard 

The difference between the two is the fact that the first allows users 
(including people that work on the standard library) to build better, more 
precise and sophisticated things with the language, while the second can make 
the language more useful and fun to use out-of-the-box by providing ready-made 
tools (for example, I'm glad that the standard library provides a "map" and 
"flatMap" for Optionals, and I 100% recognize the importance of syntactic sugar 
in many contexts, like for example keywords like async/await).

I would also argue that, while a prioritization strategy would probably favor 
the second type of features for the first years of a language's life, the 
effort in improving the language within the realm of the first type of features 
should still be constantly moving forward, along with everything else, if 
nothing because most of the second depends on the first.

For example, it we had conditional protocol conformances from the beginning 
(Swift 2), many aspects of the standard library and of many third-party library 
would be MASSIVELY different, and a lot of work of library-building would have 
been easier and faster.

I think these kinds of considerations are particularly important for Swift, 
because Swift is exactly the kind of language that can be molded to one 
developer's will, and doesn't overly push "conventions" like many more 
loosely-typed languages do: in a language as free to be interpreted as Swift, 
core features that enhance expressivity are, I think, the most important ones.



> Il giorno 04 ago 2017, alle ore 19:32, Chris Lattner via swift-evolution 
> <swift-evolution@swift.org> ha scritto:
>> On Aug 4, 2017, at 9:16 AM, Mathew Huusko V via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> Per 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
>> <https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html>,
>>  the removal of parameter labels entirely was accepted as a temporary loss 
>> for Swift 3 as a means to remove them from the type system. I'm wondering if 
>> they're coming back (syntactically) any time soon?
> The planning approach for Swift 5 hasn’t been announced yet, but it should be 
> soon-ish.
> Responding to the rest of your email in broad terms: there will always be a 
> ton of things that are important and interesting to tackle.  There is also a 
> long road ahead of Swift, so prioritization is not a bad thing: just because 
> something doesn’t happen “now” doesn’t mean it never will.
> I would also argue that it would be *bad* for the language to evolve too 
> fast.  Landing 20 major features all in the same year runs the very high risk 
> that they doesn’t work well together and don’t have time to settle out 
> properly.  It is far more important for Swift to be great over the long term 
> than to have any individual little feature “now”.
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to