[swift-evolution] [pitch] Comparison Reform

Karl Wagner razielim at gmail.com
Sat Apr 15 17:05:23 CDT 2017


> On 14 Apr 2017, at 02:58, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> 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.
> 
> Cheers,
> Jaden Geller
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

And actually, it’s a shame that kind of just snuck in as a footnote, because I think it is needed in the language anyway.

I’ve thought about more direct approaches to tackling this problem, such as “conformance regions” or named conformances (compiler-generated wrapper structs), which could allow you to conform to the same protocol more than once with special resolution features (e.g. think String.CharacterView being the default, named “Collection” conformance for String), or to manually specify which members get resolved as witnesses.

But in this proposal it’s just an implementation detail. We still don’t have a general solution to conflicting names for the members of different protocols.

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170416/06818a24/attachment.html>


More information about the swift-evolution mailing list