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

[Xiaodi Wu]

On Tue, Nov 28, 2017 at 00:32 Kelvin Ma <kelvin13ma at gmail.com> wrote:

> 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.
>

Yes, that’s what we’re talking about here: workarounds to lack of a fixed
layout type. I’m saying C is the “best option” workaround, not tuples.

plus since it lives across the module boundary, it’s effectively opaque to
> compiler optimizations.
>
What sorts of optimizations are you referring to? Recall that we are
talking about taking a value and unsafe bitcasting for the purposes of
calling other C APIs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171128/c6a14a80/attachment.html>