> On Feb 18, 2017, at 9:59 PM, Kevin Nattinger <sw...@nattinger.net> wrote: > > >> On Feb 18, 2017, at 7:33 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> I’d like to revive an additive proposal that couldn’t make it into Swift 3. >>> This proposal has a small improvement to the language compared to other big >>> features currently being proposed. It almost feels like a bug fix rather >>> than a new feature, but it still needs a full and quick review process. >>> >>> You can read the formatted version here: >>> https://github.com/apple/swift-evolution/pull/608 >>> <https://github.com/apple/swift-evolution/pull/608> >> Just MHO, but I consider this syntactic sugar, not a fundamental feature >> that fits the goal of Swift 4 stage 2. > > Not that I’m necessarily in favor of this change, but my impression was that > the whole point of stage 1/2 was that anything not allowed in stage 1 is fair > game in stage 2 (if it happens; that doesn’t seem to be likely at this > point). What exactly is the goal of stage 2 then, should there actually be > time for it?
As Xiaodi mentioned downthread, that is not the case. Swift 4 stage 2 has specific changes that are accepted, because it has a fixed schedule and we have to prioritize the most important things for the community. The art of evolving Swift forward is to carefully pick and choose areas to focus on, both because we want to ensure a coherent language, but also because implementor bandwidth is limited. Beyond that, though syntactic sugar is always motivated by strong rationale and use-cases, in my opinion, it is the most dangerous kind of additive feature to consider at this point of Swift’s evolution. While these features are useful, they also clearly add complexity to the language, and it is difficult to gauge whether the problem being addressed will even exist in Swift as the other bigger features come in (for example, a macro system). These features can also make future language evolution more problematic because they consume syntactic real estate in the language. If you’re into analogies, I see features like the generics improvements, ownership model, concurrency model, macro system, new frameworks, and other large scale efforts as the “bricks" that make up the house of Swift. In that analogy, syntactic sugar 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. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
