[swift-evolution] Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

[Trent Nadeau]

Correct. That's why I mentioned primitive types. I believe Float80 and
Vec3f are both structures.

On Fri, Jan 29, 2016 at 4:45 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Jan 29, 2016, at 1:41 PM, Trent Nadeau via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> While true for general arrays in C, you can use memcmp() to compare arrays
> of primitive types, and that case is the main one for arrays with large
> numbers of elements (char[], int[], etc.).
>
>
> That’s not true in general in C, because some types have undefined padding
> - Float80 and Vec3f come to mind.
>
> -Chris
>
>
> On Fri, Jan 29, 2016 at 3:46 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
>
>> Regarding ==: to be fair, C doesn't allow this kind of comparison either,
>> so I don't think that it will bother a lot of people who need C interop. It
>> is, however, unfortunate for people who want to use it as a first-class
>> Swift construct.
>>
>> Regarding the generalized `N x expr` syntax: if we allow it to appear in
>> more places, should we be worried about the fact that x is also a common
>> identifier?
>>
>> Also regarding the `N x expr` syntax: how many times should it evaluate
>> `expr`? Once, or N times?
>>
>> There seems to be a consensus around allowing subscripts on uniform
>> tuples, regardless of how you actually declare them. However, that part
>> decidedly needs more discussion, so like Joe said earlier, maybe we should
>> spin it off.
>>
>> Félix
>>
>> Le 29 janv. 2016 à 14:24:17, Trent Nadeau via swift-evolution <
>> swift-evolution at swift.org> a écrit :
>>
>> So what if you have a struct containing a 100 element fixed-sized
>> array/tuple? To have that struct conform to Equatable, etc., would you have
>> to explicitly equate the elements?:
>>
>> self.data.0 == other.data.0 && self.data.1 == other.data.1 && ...
>>
>> Given that large element fixed-sized arrays are common in C, this seems
>> like a huge burden.
>>
>> On Fri, Jan 29, 2016 at 2:17 PM, Joe Groff <jgroff at apple.com> wrote:
>>
>>>
>>> On Jan 29, 2016, at 11:14 AM, Trent Nadeau <tanadeau at gmail.com> wrote:
>>>
>>> Is having fixed arrays with large numbers of elements (256, 1024, etc.)
>>> going to cause issues with protocol conformance of tuples? I believe that
>>> since the type system doesn't currently have type-level integers, tuple
>>> protocol conformance is done via a hard-coded limit.
>>>
>>>
>>> Tuples still don't really conform to protocols, we just provide
>>> overloads for the <>== operators for small tuples now. Proper language
>>> support for tuple protocol conformance ought to account for arbitrary
>>> variadic-ness.
>>>
>>> -Joe
>>>
>>>
>>> On Fri, Jan 29, 2016 at 1:30 PM, Austin Zheng via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> That makes sense, thanks. I'm wondering if the N x T syntax might
>>>> 'naturally fall out' of such a system for any other use cases.
>>>>
>>>> Daydreaming aside, I think this is a great proposal and it'll make
>>>> 256-member C array tuples less awful to work with.
>>>>
>>>> Austin
>>>>
>>>> > On Jan 29, 2016, at 10:29 AM, Joe Groff <jgroff at apple.com> wrote:
>>>> >
>>>> >
>>>> >> On Jan 29, 2016, at 10:22 AM, Austin Zheng via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>> >>
>>>> >> I like the (Count x Type) design, but if Swift got integer generic
>>>> parameters in the future is this what tuple shorthand syntax would still
>>>> look like (not rhetorical, actually asking)? It would be nice to
>>>> future-proof whatever design we come up with, to a reasonable extent.
>>>> >
>>>> > You'd still need something to define FixedArray<N> in terms of:
>>>> >
>>>> > struct FixedArray<T,N: Int> { var values: (N x T) }
>>>> >
>>>> > -Joe
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>
>>>
>>>
>>> --
>>> Trent Nadeau
>>>
>>>
>>>
>>
>>
>> --
>> Trent Nadeau
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
>
> --
> Trent Nadeau
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/e8c7956c/attachment.html>