<div dir="ltr"><div>Hi Dmitri, thanks for the great feedback. I&#39;ve updated the pull request &lt;<a href="https://github.com/apple/swift-evolution/pull/283">https://github.com/apple/swift-evolution/pull/283</a>&gt;.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 2, 2016 at 5:53 PM Dmitri Gribenko &lt;<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>&gt; 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>
&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt; I&#39;ve written a proposal to formalize some of the discussion that was had<br>
&gt; over in the thread for the `FloatingPoint` protocol proposal regarding<br>
&gt; improvements to operator requirements in protocols that do not require named<br>
&gt; methods be added to the protocol and conforming types. Thanks to everyone<br>
&gt; who was participating in that discussion!<br>
&gt;<br>
&gt; The proposal can be viewed in this pull request and is pasted below.<br>
<br>
Hi Tony,<br>
<br>
I&#39;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 &quot;Alternatives Considered&quot; so that the history of it wasn&#39;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&#39;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&#39;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>