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
···
On Aug 7, 2017, at 12:43 AM, Elviro Rocca <retired.hunter.djura@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.