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

[Kelvin Ma]

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>