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