[Accepted] SE-0067: Enhanced Floating Point Protocols


(Chris Lattner) #1

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md

Hello Swift Community,

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!

-Chris


(Xiaodi Wu) #2

Bravo. This is a welcome improvement to the language.

···

On Mon, May 2, 2016 at 10:56 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md

Hello Swift Community,

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!

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Xiaodi Wu) #3

Last nit (sorry!)--
The enum Sign should have lowercase names for the cases (i.e. `plus` and
`minus` instead of `Plus` and `Minus`).

···

On Mon, May 2, 2016 at 11:05 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Bravo. This is a welcome improvement to the language.

On Mon, May 2, 2016 at 10:56 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md

Hello Swift Community,

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!

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution