[swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

[Elviro Rocca]

I agree with everything you wrote, in particular I agree with the idea that it is more important to get the big efforts right, and that they should take priority. But I would consider a distinction:

- big efforts that add huge new features to the language so that things that were done in userland with libraries can be done natively and idiomatically (concurrent programming, for example);
- more "theoretical" big efforts, that allow one, while building a single app or a big library, to "express" more things more precisely in the language, and improvements to the generics and protocols systems fall in this second realm;

The reason why I consider the second kind of feature as more important than the first (thus, earning higher priority) is that, apart from reducing the amount of busywork to be done in many cases where the abstraction power is not good enough, it gives more tools for the community to build upon, it allows many people to do more with the language than probably me, you and the core team have ever though of, it fosters the explosion of creativity that's only possible when a language is expressive enough and it's not only based on certain conventions (that, by definition, constraint the way a language is commonly used).

What do you think?

Thanks


Elviro

> Il giorno 07 ago 2017, alle ore 18:11, Chris Lattner <clattner at nondot.org> ha scritto:
> 
> 
>> On Aug 7, 2017, at 12:43 AM, Elviro Rocca <retired.hunter.djura at gmail.com> wrote:
>> 
>> 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.
> 
> Yes, there is a really huge amount of stuff that is missing from Swift.  I suspect my list is longer than anyone else’s. :-)
> 
> My point on this is that it is more important to get the big efforts right than it is to over-prioritize the small efforts.  This is both because of implementation bandwidth reasons, but more importantly because it leads to a better design.  Big efforts are *hard*, and tend to be less driven by the community at large, but they really should take priority.
> 
> If you’re into analogies, I see features like the generics improvements, concurrency model, ownership system, macro system, ABI stability, new frameworks, and other large scale efforts as the “bricks" that make up the house of Swift.  In that analogy, smaller proposals are “mortar” that fills in the cracks between the bricks.  If we add too much mortar too early on, we run the risk of the house of Swift being built out of mortar, or of not being able to fit the bricks into the right places.  That would be very bad, given that we all want the house of Swift to be strong and beautiful over the long term.
> 
> Clearly there is a balance to be made, which is why major Swift releases are a mix of large efforts (e.g. Codable improvements, typed keypaths, String redesign...) as well as smaller ones (e.g. multiline strings, dictionary API improvements, etc).
> 
> -Chris
> 
>