The second review of "SE-0091: Improving operator requirements in protocols" ran from July 7...12, 2016. The proposal has been *accepted with revision*:
The second iteration of this proposal has been very well received by both the community and core team. The core team requests one minor modification: in an effort to reduce the scope of the proposal, it should specifically require that operator declarations in classes be written as static (or equivalently, as “final class”). In the future, support for operators may be extended to support dynamic dispatch, and the core team wants to keep the design space open. The core team also observed that the impact on the standard library is not captured in this proposal, but that can be incorporated later (as an amendment to this proposal) since it should have little user impact.
Thank you to Tony Allevato and Doug Gregor for driving this discussion forward! I filed SR-2073 to track implementation work on this.
Thanks Chris! I'm happy that the proposal was well-received, and thanks to
Doug for the great improvements for revision 2.
Related, does the acceptance of this proposal imply the removal of the
named methods from FloatingPoint and Arithmetic in favor of static
operators, or do we need a separate proposal for that?
I'll work on a PR to the proposal that covers the changes regarding
classes, and to list the protocols affected by this (FP and Arithmetic
noted above, as well as Equatable and others).
···
On Wed, Jul 13, 2016 at 8:46 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
The second review of "SE-0091: Improving operator requirements in
protocols" ran from July 7...12, 2016. The proposal has been *accepted with
revision*:
The second iteration of this proposal has been very well received by both
the community and core team. The core team requests one minor
modification: in an effort to reduce the scope of the proposal, it should
specifically require that operator declarations in classes be written as
static (or equivalently, as “final class”). In the future, support for
operators may be extended to support dynamic dispatch, and the core team
wants to keep the design space open. The core team also observed that the
impact on the standard library is not captured in this proposal, but that
can be incorporated later (as an amendment to this proposal) since it
should have little user impact.
Thank you to Tony Allevato and Doug Gregor for driving this discussion
forward! I filed SR-2073 to track implementation work on this.
Thanks Chris! I'm happy that the proposal was well-received, and thanks to Doug for the great improvements for revision 2.
Related, does the acceptance of this proposal imply the removal of the named methods from FloatingPoint and Arithmetic in favor of static operators, or do we need a separate proposal for that?
That should be either a separate proposal or a refinement to this one. I suspect we’ll go with the later approach just because the changes are “obvious”, but I don’t speak for the whole core team with that opinion.
-Chris
···
On Jul 13, 2016, at 8:57 PM, Tony Allevato <allevato@google.com> wrote:
I'll work on a PR to the proposal that covers the changes regarding classes, and to list the protocols affected by this (FP and Arithmetic noted above, as well as Equatable and others).
The second review of "SE-0091: Improving operator requirements in protocols" ran from July 7...12, 2016. The proposal has been *accepted with revision*:
The second iteration of this proposal has been very well received by both the community and core team. The core team requests one minor modification: in an effort to reduce the scope of the proposal, it should specifically require that operator declarations in classes be written as static (or equivalently, as “final class”). In the future, support for operators may be extended to support dynamic dispatch, and the core team wants to keep the design space open. The core team also observed that the impact on the standard library is not captured in this proposal, but that can be incorporated later (as an amendment to this proposal) since it should have little user impact.
Thank you to Tony Allevato and Doug Gregor for driving this discussion forward! I filed SR-2073 to track implementation work on this.
在 2016年7月14日，12:56，Chris Lattner via swift-evolution <swift-evolution@swift.org> 写道：
On Jul 13, 2016, at 8:57 PM, Tony Allevato <allevato@google.com <mailto:allevato@google.com>> wrote:
Thanks Chris! I'm happy that the proposal was well-received, and thanks to Doug for the great improvements for revision 2.
Related, does the acceptance of this proposal imply the removal of the named methods from FloatingPoint and Arithmetic in favor of static operators, or do we need a separate proposal for that?
That should be either a separate proposal or a refinement to this one. I suspect we’ll go with the later approach just because the changes are “obvious”, but I don’t speak for the whole core team with that opinion.
-Chris
I'll work on a PR to the proposal that covers the changes regarding classes, and to list the protocols affected by this (FP and Arithmetic noted above, as well as Equatable and others).
The second review of "SE-0091: Improving operator requirements in protocols" ran from July 7...12, 2016. The proposal has been *accepted with revision*:
The second iteration of this proposal has been very well received by both the community and core team. The core team requests one minor modification: in an effort to reduce the scope of the proposal, it should specifically require that operator declarations in classes be written as static (or equivalently, as “final class”). In the future, support for operators may be extended to support dynamic dispatch, and the core team wants to keep the design space open. The core team also observed that the impact on the standard library is not captured in this proposal, but that can be incorporated later (as an amendment to this proposal) since it should have little user impact.
Thank you to Tony Allevato and Doug Gregor for driving this discussion forward! I filed SR-2073 to track implementation work on this.