[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types
xiaodi.wu at gmail.com
Fri Nov 24 12:18:59 CST 2017
On Thu, Nov 23, 2017 at 6:27 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:
> 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:
> [ Matrices and projections ] (example:
> [ 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.
FWIW, tuples are only guaranteed to have a C-compatible layout when exposed
to C; that is, Swift doesn't guarantee that there will not be optimizations
in the future that change tuple layout such that a call into C will cause
your tuples to do interop gymnastics.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution