> 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
I really like this image — especially because it shows the need for a third
Even with a perfect mixture of mortar and bricks, you'll end up with little
more than a pile of rocks and clay if you don't have some kind of blueprint.
Of course, an analogy is just analogy, but I think especially under the light
of the change of rules for the evolution process, it is even more important to
have a bigger picture of the future Swift:
Instead of people just arguing for their favourite type of block to be
integrated as soon as possible, I'd like to see more guidance on which
additions fit into the plan, and how they interact with each other.
Not only because this might protected people from wasting their time with
shaping the wrong bricks, but also to increase consistency in the language.
swift-evolution mailing list