[swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)
kelvin13ma at gmail.com
Mon Aug 7 11:40:42 CDT 2017
On Mon, Aug 7, 2017 at 12:12 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:
> > 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).
The FSA drama is a good example of this. You could either create a special
new syntax for them, or extend the generics system to take value
parameters. Then again there is a problem where people use that as an
excuse to procrastinate on a feature.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution