[swift-evolution] [pitch] Comparison Reform
jaden.geller at gmail.com
Thu Apr 13 20:29:23 CDT 2017
Oh, I definitely overlooked that part. Thanks for that clarification! I had assumed the compiler changes were only necessary for allowing circular default implementations while still requiring at least one requirement be implemented.
That said, it’s possible to implement something very, very similar without compiler changes:
> On Apr 13, 2017, at 5:58 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> Jaden, the proposal literally says that a compiler feature named "@_implements" is necessary for the proposed design to work. You can see WIP for that feature in the apple/swift repo.
> On Thu, Apr 13, 2017 at 19:55 Jaden Geller <jaden.geller at gmail.com <mailto:jaden.geller at gmail.com>> wrote:
>> On Apr 13, 2017, at 5:18 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Actually, the fact that this behavior cannot even be achieved without currently non-existent compiler features means that it is not possible to understand what's truly going on without reading *this document*, after mastering *both* IEEE floating point *and* Swift generics/protocols/extensions/static vs. dynamic dispatch. All to use `==` correctly. Which is to say, most people will simply not even know if they happen to be using the `==` they did not intend to use.
> If I understand correctly, I think you’re mistaken. The compiler already selects overloads based on generic context. If `T: FloatingPoint`, then it’ll choose the `==` with signature `<T: FloatingPoint> (T, T) -> Bool`. If `T: Equatable`, then it’ll choose the `==` with signature `<T: Equatable> (T, T) -> Bool`. No new compiler features are necessary for this specific behavior.
> Jaden Geller
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution