OK. I'll shut up since I wast your time. > 在 2016年7月14日，12:56，Chris Lattner via swift-evolution > <[email protected]> 写道： > > >> On Jul 13, 2016, at 8:57 PM, Tony Allevato <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
