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.
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.
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.
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!
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.
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.
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.
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!
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.
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.
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.
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!