[swift-evolution] [Accepted] SE-0091: Improving operator requirements in protocols

[Cao Jiannan]

OK. I'll shut up since I wast your time.

> 在 2016年7月14日，12:56，Chris Lattner via swift-evolution <swift-evolution at swift.org> 写道：
> 
> 
>> On Jul 13, 2016, at 8:57 PM, Tony Allevato <allevato at google.com <mailto:allevato at 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).
>> 
>> On Wed, Jul 13, 2016 at 8:46 PM Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md <https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md>
>> 
>> 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.
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160811/ebbf40d8/attachment.html>