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

Kelvin Ma kelvin13ma at gmail.com
Thu Nov 23 18:27:31 CST 2017


On Thu, Nov 23, 2017 at 7:08 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

>
> On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution <
> swift-evolution at swift.org> 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
>>
>
> Why do you need to have this ability to unsafe bitcast? Is interconversion
> between point types such a common operation that it's a performance
> bottleneck?
>

idk if it’s a performance bottleneck because i use tuples in my geometry
stack and i keep the bottom 2 levels in the same module but it cannot be
good. a lot of the geometry code I write sits atop 2 or 3 other layers of
geometry code beneath it, and it interops with geometry APIs in other
libraries. for example it might be organized like

[ Client geometry code ] ←→ [ Library geometry code ] (example:
Voronoi.voronoi(_:), Noise.perlin(_:_:))
       [ Procedurally generated geometry ] (example:
makeSphere(resolution:))
       [    Matrices and projections     ] (example:
Geometry.clockwise(_:_:center:normal:))
       [               Math              ] (example: Math.cross(_:_:))

converting at every boundary seems like something to avoid. not to mention
the sheer amount of boilerplate all those conversions produce.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171123/f97da040/attachment.html>


More information about the swift-evolution mailing list