Hi Dmitri, thanks for the great feedback. I've updated the pull request < https://github.com/apple/swift-evolution/pull/283>.
On Mon, May 2, 2016 at 5:53 PM Dmitri Gribenko <griboz...@gmail.com> wrote: > On Mon, May 2, 2016 at 9:44 AM, Tony Allevato via swift-evolution > <swift-evolution@swift.org> wrote: > > I've written a proposal to formalize some of the discussion that was had > > over in the thread for the `FloatingPoint` protocol proposal regarding > > improvements to operator requirements in protocols that do not require > named > > methods be added to the protocol and conforming types. Thanks to everyone > > who was participating in that discussion! > > > > The proposal can be viewed in this pull request and is pasted below. > > Hi Tony, > > I'd like to post this feedback on behalf of Dave Abrahams, Maxim > Moiseev and myself. > > We are in favor of your proposal, but we would like to request a few > modifications. > > 1. Could you remove the section about the stretch goal to generate > the trampolines automatically? We think that the proposal provides > enough value by itself, and we generating the trampolines will just > complicate the implementation, delaying the user model improvement. > This can come later. > Done. I left a brief mention (once sentence) of it in "Alternatives Considered" so that the history of it wasn't completely lost. 2. The section about the classes is written in a way that seems to > imply that the proposal regresses the way Equatable works with > classes. We don't think this is the case. Could you change to just > acknowledge the problem and say that we are not fixing it in this > proposal? > Done—I removed all of the code examples and tightened it up into a brief discussion acknowledging the issue. 3. Could you explain in more detail how the name lookup works in the > proposal? In particular, it would be good to emphasize that regular > name lookup done when type checking an infix expression would not find > an operator defined as a type member. > Done. > 4. What do you think about adding a rule to disallow defining member > operators that don't satisfy a protocol requirement? > Added. That seems like a reasonable and appropriate requirement, since the feature is being proposed specifically to improve protocol-required operators.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
