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

Kelvin Ma kelvin13ma at gmail.com
Tue Nov 28 00:32:38 CST 2017

On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:
>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>> On Mon, Nov 27, 2017 at 15:46 Taylor Swift <kelvin13ma at gmail.com> wrote:
>>>> they use packed buffers of floats, which for type safety are better
>>>> rebound to a structured type. right now (Float, Float, Float) works because
>>>> the tuple is laid out contiguously and the GPU can’t tell the difference
>>>> but it’s not guaranteed. also you’re ignoring all the CPU stages that occur
>>>> before anything even gets sent to the GPU.
>>> Precisely, there is no guarantee of performance if you call these APIs
>>> with an array of Swift tuples.
>> which is exactly why i support a dedicated language-level vector type
>> which guarantees contiguous, fixed storage, and which the compiler knows
>> about so it can vectorize operations on them.
> That's an entirely separate discussion.
>> tuples right now try to fill too many roles and that makes life difficult
>> for both the compiler and the programmer. however, until then, we need some
>> kind of common, fixed layout currency type for vector data, and by
>> implementation-detail, *tuples are our best option* since for some
>> reason everyone is so opposed to the simple solution of baking vec2, vec3,
>> … vec5 into the language and the generic integer Vector<Float, k>
>> solution everyone wants likely isn’t going to materialize for the
>> foreseeable future.
> Disagree. If you want a particular memory layout, define your type in C.
> Swift's interop story is very good, and your type will have a fixed layout
> forever.

“*write it in c and import it*” is *not* a solution,, it is a workaround.
plus since it lives across the module boundary, it’s effectively opaque to
compiler optimizations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171128/d8b48953/attachment.html>

More information about the swift-evolution mailing list