> On Nov 10, 2017, at 6:01 PM, Chris Lattner <sa...@nondot.org> wrote: > > It is. It is strictly sugar, as mentioned in the proposal.
All new code has a cost. > I do not expect any SIL or IRGen changes associated with this proposal, just > type checker changes. The type checker changes should be straight-forward, > but you can evaluate that when there is a patch. Like I said, the type checker’s code for solving member constraints and applying the solution is already a rats-nest of special cases to deal with the rich semantics of method calls in Swift. We’ve been trying to simplify it over time and fix bugs, and adding new special cases is a step in the wrong direction. > Our goal is for Swift to be awesome, not comparable to “other statically > typed languages”. Ok, but being awesome is not the same as adding every possible feature to the language. > swift-evolution isn’t about priorities. I’m not asking someone else to > implement this, and you don’t tell me how I spend my engineering time :-) :-) Again, my point here is that implementing a new feature is just the first step. New code also has to be maintained going forward. > I’m open to requiring these to be the same type if there is a benefit to > doing so. What benefit do you see? Can you think of a case where they have to be different? Slava _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
