<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 7, 2017 at 12:12 PM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Aug 7, 2017, at 12:43 AM, Elviro Rocca <<a href="mailto:retired.hunter.djura@gmail.com">retired.hunter.djura@gmail.<wbr>com</a>> wrote:<br>
><br>
> 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.<br>
<br>
</span>Yes, there is a really huge amount of stuff that is missing from Swift. I suspect my list is longer than anyone else’s. :-)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<div class="HOEnZb"><div class="h5"><br>
-Chris<br>
<br></div></div></blockquote><div><br></div><div>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. <br></div></div></div></div>