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

[Charles Kissinger]

> On Jan 29, 2016, at 12:46 PM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:

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

+1 to separating the addition of tuple subscripts and the new declaration syntax into two separate proposals.

—CK

> 
> 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>
> _______________________________________________
> 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/20160130/82d0e327/attachment.html>