On Thu, Nov 23, 2017 at 6:27 PM, Kelvin Ma <kelvin1...@gmail.com> wrote:
> > > On Thu, Nov 23, 2017 at 7:08 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> >> On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>> >>> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@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. > 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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
