> 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.
I really like this image — especially because it shows the need for a third ingredient: 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. - Tino
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
