> On 19 Feb 2017, at 19:14, Chris Lattner via swift-evolution > <swift-evolution@swift.org> wrote: > > >> 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> wrote: >>> >>> >>>> On Feb 17, 2017, at 12:20 AM, Adrian Zubarev via swift-evolution >>>> <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 >>>> >>> 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 >
Amen! Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
