<div dir="ltr">Last nit (sorry!)--<div>The enum Sign should have lowercase names for the cases (i.e. `plus` and `minus` instead of `Plus` and `Minus`).</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 11:05 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Bravo. This is a welcome improvement to the language.<div><div class="h5"><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 10:56 PM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Proposal link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md</a><br>
<br>
Hello Swift Community,<br>
<br>
The review of SE-0067: "Enhanced Floating Point Protocols” ran from April 19…April 29, 2016. The proposal is *accepted* for Swift 3. Overall, the feedback on the proposal was very positive, particularly for revision 2 of the proposal.<br>
<br>
The most significant feedback was around the naming issues for the various protocol requirements that map onto operators (e.g. “isLessThanOrEqualTo”). The core team agrees that these are unfortunate - their naming is awkward and they will end up polluting code completion for instances of these numeric types. That said, we are accepting the proposal as written, because the rest of the proposal is great progress in the direction we want to go, accepting it will allow us to get experience living on it, and we can improve this issue with a follow-on proposal.<br>
<br>
To address the naming issues, we’d like to explore Tony Allevato’s ideas in the “Improve operator requirements in protocols” thread on swift-evolution. If that doesn’t work out, we request that these members be reworked to be named static members in the protocol, which will address the code completion issue.<br>
<br>
Thank you to Stephen Canon for driving the design and implementation of this, and to Max Moiseev (and several others) who have been contributing to the implementation. This is a fundamental step to moving Swift numerics forward!<br>
<br>
-Chris<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>