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

[Trent Nadeau]

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/d3eb1aff/attachment.html>