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

[Chris Lattner]

> 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 <mailto: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 <mailto: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 <mailto:jgroff at apple.com>> wrote:
>> 
>>> On Jan 29, 2016, at 11:14 AM, Trent Nadeau <tanadeau at gmail.com <mailto: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 <mailto: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 <mailto:jgroff at apple.com>> wrote:
>>> >
>>> >
>>> >> On Jan 29, 2016, at 10:22 AM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> 
>>> 
>>> -- 
>>> Trent Nadeau
>> 
>> 
>> 
>> 
>> -- 
>> Trent Nadeau
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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

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