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

[Kelvin Ma]

On Tue, Nov 28, 2017 at 3:18 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

>
> 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.
>
> you misunderstand the use-case. C and C APIs usually don’t show up in the
story until the very last step, when you send the buffer to the drawing
library (cairo, opengl, etc). all the stages that come before are swift and
involve passing data between two swift interfaces.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171128/076387e2/attachment.html>