[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Kelvin Ma kelvin13ma at gmail.com
Thu Nov 23 16:50:02 CST 2017


On Thu, Nov 23, 2017 at 5:45 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:

>
>
> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2th at gmx.de> wrote:
>
>>
>> a good idea on paper, a disastrous one in practice. What happens if every
>> geometry library declares their own Point type?
>>
>> That would be ugly („disastrous“ imho is a little bit to strong — C++
>> had/has similar issues, and other languages as well)
>> But if there would be a simple Point struct in a library that is popular
>> (could be achieved by shipping it alongside the stdlib), this problem would
>> be solved (there has been a pitch lately, but I guess it faded away
>> silently).
>>
>
> it’s ugly in C++ and disastrous in Swift because C++ has fixed layout
> guarantees and everyone agrees that z comes after y comes after x, so you
> can unsafe-bitcast the foreign C++ points into your own points “for free”.
> you can’t do the same thing in Swift
>

ps i remember that pitch because i’m pretty sure i was the one that pitched
that. consensus seemed it was too high level for inclusion (even though
having it at the stdlib level would do wonders for things like SIMD) and
everyone got distracted by “integers as generic parameters” (because we
love `Vector<3>` ig) because everything on this list always devolves into
“but this is *really* a problem with the *generics system*” and since no
one knows how to fix the generics system everyone calls it a day and
forgets about the original issue
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171123/8b2c897d/attachment.html>


More information about the swift-evolution mailing list