Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)

[Felix_Cloutier1]

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@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@apple.com <mailto:jgroff@apple.com>> wrote:

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

--
Trent Nadeau

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[mwhiteside.dev]

Have people on this thread been suggesting the letter ‘x’ literally for the operator, or was that meant as a shortcut/standin for the unicode cross operator: ×

?

Or maybe they are so similar that neither would be a good keyword…

Matt

···

On Feb 1, 2016, at 12:43, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 1, 2016, at 8:42 AM, John Randolph via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 29, 2016, at 2:40 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:
am I the only one who get creeps because of that "x" in the declaration? I

I really don’t like the x as an operator either, because I use x for so many other things in my code.

I agree that it wouldn’t be acceptable to take x as a keyword.

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Tino]

var aMatrix: Matrix<Int> = Matrix(row: 6, columns: 20)

That can be done already — but it is not possible for the compiler to enforce correct handling (matching dimensions for operations on matrix/vectors).
Adding this would be nice, but I was told it is out of scope for Swift 3.
(the proposal-draft I made is here: https://github.com/SwiftTypesafeCalculations/Home/wiki/compile-time%20parameters)

Tino

[David_Sweeris]

Ah, it’s a non-starter then… Or at the very least *much* more difficult than I’d thought. Thank you

- Dave Sweeris

···

On Feb 9, 2016, at 14:42, Jordan Rose <jordan_rose@apple.com> wrote:

On Feb 9, 2016, at 13:52, Dave via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 9, 2016, at 12:57, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Feb 9, 2016, at 11:33 AM, davesweeris@mac.com <mailto:davesweeris@mac.com> wrote:

This would solve the fixed size array use-case, be much easier to implement, and not have surprising performance issues promoting things to Any. It is also consistent with the fact that we don’t infer the type of [Int(), Float()] to [Any].

-Chris

(Sorry to go so far back… I started replying to this on probably the 29th and somehow forgot about it.)

Out of curiosity, why would the subscript of non-homogeneous tuple have to return an "Any”? If we declare this:
let grohl = (0, “foo”, “fighters”, 0.0)

Why couldn’t subscript (and $0 in map, for that matter) return a type that’s the “intersection” of Int, String, and Double?

Swift has no such intersection type. The closes analogs we have are Any (or if you allow boxing, NSObject/NSValue).

I know. My round-about point was that, if my assumption about how that part of the compiler works is correct, it wouldn’t be hard to add the functionality. At least from the point of view of how to check if the code is correct. Admittedly, I was only thinking in terms of how one would go about extending map() to tuples. I haven’t considered the implications of allowing the “intersection” to be assigned to a variable or returned from a function, or what the syntax could/should be for interacting with such a type outside of the closure passed to map().

If it isn’t out of scope or just a non-starter, I’d like to explore the idea here (or in a different thread). Seems like it could make tuples in general, and specifically generic tuples, a lot more powerful.

Types aren't just bags of operations, which means that taking the intersection of arbitrary types isn't meaningful. Similarly, generics aren't templates to be instantiated, meaning that there has to be a run-time representation of a "value of intersection type".

The constructs that carries the right meaning in Swift are protocols, and in theory you could intersect the protocols of the various types. In practice, though, the current model doesn't have a good way to actually do this, since not all protocols can be used as types of values, and finding the protocol-intersection of N types is a needless amount of extra work for the compiler anyway.

Jordan

[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@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@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@apple.com> wrote:

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

--
Trent Nadeau

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

[Charles_Kissinger]

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

···

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

Félix

Le 29 janv. 2016 à 14:24:17, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@apple.com <mailto:jgroff@apple.com>> wrote:

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

--
Trent Nadeau

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[David_Sweeris]

I can’t speak for everyone else, but I’ve been using it as a stand-in for “whatever”. I think × and x are different enough (at least in Xcode’s default Menlo and, my current favorite, Fira Mono), but I don’t think × is anywhere of the normal keyboard layout. I know it wouldn’t be hard for Apple to have a custom keyboard layout with a bunch of math symbols on the alt layer, but I don’t know how to handle it for other editors.

It’s too bad, really… Not for × in particular, but abstract / math code in general would be a lot more readable if people had easy access the various operators and set notation symbols.

- Dave Sweeris

···

On Feb 1, 2016, at 17:31, Matt Whiteside via swift-evolution <swift-evolution@swift.org> wrote:

Have people on this thread been suggesting the letter ‘x’ literally for the operator, or was that meant as a shortcut/standin for the unicode cross operator: ×

?

Or maybe they are so similar that neither would be a good keyword…

Matt

On Feb 1, 2016, at 12:43, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 1, 2016, at 8:42 AM, John Randolph via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 29, 2016, at 2:40 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:
am I the only one who get creeps because of that "x" in the declaration? I

I really don’t like the x as an operator either, because I use x for so many other things in my code.

I agree that it wouldn’t be acceptable to take x as a keyword.

-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[trs]

Ceylon has intersection and union types and uses the union type for tuples which is a better fit than the intersection type IMO.

How tuples work in Ceylon and how they are used to represent function parameter lists is explained in more detail here: http://ceylon-lang.org/blog/2013/01/21/abstracting-over-functions/

It's definitely worth a read as Ceylon makes tremendous use of union and intersection types IMO.

-Thorsten

···

Am 09.02.2016 um 23:47 schrieb Dave via swift-evolution <swift-evolution@swift.org>:

On Feb 9, 2016, at 14:42, Jordan Rose <jordan_rose@apple.com> wrote:

On Feb 9, 2016, at 13:52, Dave via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 9, 2016, at 12:57, Chris Lattner <clattner@apple.com> wrote:
On Feb 9, 2016, at 11:33 AM, davesweeris@mac.com wrote:

This would solve the fixed size array use-case, be much easier to implement, and not have surprising performance issues promoting things to Any. It is also consistent with the fact that we don’t infer the type of [Int(), Float()] to [Any].

-Chris

(Sorry to go so far back… I started replying to this on probably the 29th and somehow forgot about it.)

Out of curiosity, why would the subscript of non-homogeneous tuple have to return an "Any”? If we declare this:
let grohl = (0, “foo”, “fighters”, 0.0)

Why couldn’t subscript (and $0 in map, for that matter) return a type that’s the “intersection” of Int, String, and Double?

Swift has no such intersection type. The closes analogs we have are Any (or if you allow boxing, NSObject/NSValue).

I know. My round-about point was that, if my assumption about how that part of the compiler works is correct, it wouldn’t be hard to add the functionality. At least from the point of view of how to check if the code is correct. Admittedly, I was only thinking in terms of how one would go about extending map() to tuples. I haven’t considered the implications of allowing the “intersection” to be assigned to a variable or returned from a function, or what the syntax could/should be for interacting with such a type outside of the closure passed to map().

If it isn’t out of scope or just a non-starter, I’d like to explore the idea here (or in a different thread). Seems like it could make tuples in general, and specifically generic tuples, a lot more powerful.

Types aren't just bags of operations, which means that taking the intersection of arbitrary types isn't meaningful. Similarly, generics aren't templates to be instantiated, meaning that there has to be a run-time representation of a "value of intersection type".

The constructs that carries the right meaning in Swift are protocols, and in theory you could intersect the protocols of the various types. In practice, though, the current model doesn't have a good way to actually do this, since not all protocols can be used as types of values, and finding the protocol-intersection of N types is a needless amount of extra work for the compiler anyway.

Jordan

Ah, it’s a non-starter then… Or at the very least *much* more difficult than I’d thought. Thank you

- Dave Sweeris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Chris_Lattner]

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 Jan 29, 2016, at 1:41 PM, Trent Nadeau via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, Jan 29, 2016 at 3:46 PM, Félix Cloutier <felixcca@yahoo.ca <mailto:felixcca@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@swift.org <mailto:swift-evolution@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@apple.com <mailto:jgroff@apple.com>> wrote:

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

--
Trent Nadeau

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[hlovatt]

+1 for the proposal. I think as well as subscript count would be useful.

-1 for N x Type syntax, I wouldn't like x to be tied up. Perhaps Type.N to
mimic the access tuple.0, tuple.1, etc.

···

On Saturday, 30 January 2016, Trent Nadeau via swift-evolution < swift-evolution@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.).

On Fri, Jan 29, 2016 at 3:46 PM, Félix Cloutier <felixcca@yahoo.ca > <javascript:_e(%7B%7D,'cvml','felixcca@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@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@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@apple.com >> <javascript:_e(%7B%7D,'cvml','jgroff@apple.com');>> wrote:

On Jan 29, 2016, at 11:14 AM, Trent Nadeau <tanadeau@gmail.com >>> <javascript:_e(%7B%7D,'cvml','tanadeau@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@swift.org >>> <javascript:_e(%7B%7D,'cvml','swift-evolution@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@apple.com >>>> <javascript:_e(%7B%7D,'cvml','jgroff@apple.com');>> wrote:
>
>
>> On Jan 29, 2016, at 10:22 AM, Austin Zheng via swift-evolution < >>>> swift-evolution@swift.org >>>> <javascript:_e(%7B%7D,'cvml','swift-evolution@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@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

--
Trent Nadeau
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

--
  -- Howard.

[Justin_Kolb]

It seems that while similar to tuples, fixed sized arrays are definitely not a tuple.

1.) There would be a need for two forms of tuple indexing, most likely leading to confusion and complexity.
2.) When a new user wants a fixed size array they aren’t looking for special casing of a tuple, they are going to look in the arrays documentation and not find what they are looking for.
3.) Tuples are generally compile time checked, arrays are usually not.
4.) The count of a tuple isn’t a very useful operation, but on an array it is essential.
5.) The memory layout of a tuple should prefer to be ambiguous (even if it is essentially the same as a fixed array) while a fixed array has a very specific and relied upon memory layout in order to make it useful in low level scenarios.

While researching this I came across the syntax that Rust uses for its fixed size arrays which in Swift would be:

var a: [Int; n] // Where n is a compile time constant

While this is very similar to the existing array syntax I think it is different and straight forward enough that people expecting a dynamic array would use [Int] and a fixed array to be [Int; n], and would allow them to be discussed with each other in the documentation without having to explain why a fixed array would be so vastly different as it would be in the instance it was considered a special case tuple.

I think we have fallen into a trap where it seems like it would be easy to modify tuples to act liked fixed arrays since they somewhat do already. Applying the principle of least surprise I think this is a mistake, when someone wants an array, they want an array. Despite any extra difficulty (that’s not obviously insurmountable) I think it would be beneficial to keep arrays and tuples separate and distinct from each other.

There is still the potential point of confusion that [Int; n] is a low level construct (most likely not allowing user defined methods) while [Int] is syntax sugar for Array<Int>, but I think overall it is still a better trade off and less surprising. It also seems like grammar problems might be lessened when dealing with [] instead of () which is used in more cases.

[David_Sweeris]

Why does n have to be a compile-time constant? Seems like any integer value >= 0 would be ok.

- Dave Sweeris

···

Sent from my iPhone

On Feb 2, 2016, at 20:10, Justin Kolb via swift-evolution <swift-evolution@swift.org> wrote:

It seems that while similar to tuples, fixed sized arrays are definitely not a tuple.

1.) There would be a need for two forms of tuple indexing, most likely leading to confusion and complexity.
2.) When a new user wants a fixed size array they aren’t looking for special casing of a tuple, they are going to look in the arrays documentation and not find what they are looking for.
3.) Tuples are generally compile time checked, arrays are usually not.
4.) The count of a tuple isn’t a very useful operation, but on an array it is essential.
5.) The memory layout of a tuple should prefer to be ambiguous (even if it is essentially the same as a fixed array) while a fixed array has a very specific and relied upon memory layout in order to make it useful in low level scenarios.

While researching this I came across the syntax that Rust uses for its fixed size arrays which in Swift would be:

var a: [Int; n] // Where n is a compile time constant

While this is very similar to the existing array syntax I think it is different and straight forward enough that people expecting a dynamic array would use [Int] and a fixed array to be [Int; n], and would allow them to be discussed with each other in the documentation without having to explain why a fixed array would be so vastly different as it would be in the instance it was considered a special case tuple.

I think we have fallen into a trap where it seems like it would be easy to modify tuples to act liked fixed arrays since they somewhat do already. Applying the principle of least surprise I think this is a mistake, when someone wants an array, they want an array. Despite any extra difficulty (that’s not obviously insurmountable) I think it would be beneficial to keep arrays and tuples separate and distinct from each other.

There is still the potential point of confusion that [Int; n] is a low level construct (most likely not allowing user defined methods) while [Int] is syntax sugar for Array<Int>, but I think overall it is still a better trade off and less surprising. It also seems like grammar problems might be lessened when dealing with [] instead of () which is used in more cases.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[maven]

Hi,

···

On 3 Feb 2016, at 05:10, Justin Kolb via swift-evolution <swift-evolution@swift.org> wrote:

It seems that while similar to tuples, fixed sized arrays are definitely not a tuple.

I sort of disagree, but in my mind (and coming from a C++ background) (compile-time) fixed-size arrays could be regarded as a specific subset of tuples, namely the ones where all elements have the same type.
If we had the capability to have the subscript-operator / indexing return different types depending on the argument (which then would have to be known at compile-time), this would fall in place pretty nicely.

That said, the ability to index the type with value only known at run-time (and something like a .data() contiguous buffer view) would be a refinement only available on the fixed-size array variant.

Either way, I’m not sure whether it’s better to model this as separate types (e.g. std::tuple vs std::array) or not, but I am convinced that the way tuple is used now for mapping fixed-size arrays from C-headers should be improved, especially with some functionality of tuples (e.g. comparison, ordering IIRC?) being restricted to low arities.

  Daniel.

[Brent_Royal-Gordon]

I sort of disagree, but in my mind (and coming from a C++ background) (compile-time) fixed-size arrays could be regarded as a specific subset of tuples, namely the ones where all elements have the same type.
If we had the capability to have the subscript-operator / indexing return different types depending on the argument (which then would have to be known at compile-time), this would fall in place pretty nicely.

A proposal along these lines appears to already be in the works. However, tuple arrays still aren't quite first-class types—you can't even loop over them. Nor does that address other cases like ring buffers with a generic size.

Tuple arrays are a great way to get some extra mileage out of an existing feature, but they're not a 100% solution.

···

--
Brent Royal-Gordon
Architechies

[Tino]

Why does n have to be a compile-time constant? Seems like any integer value >= 0 would be ok.

If n is a variable whose value is determined at runtime, the compiler can't enforce type safety. It is no problem to declare structures of fixed size in Swift, so there is no need for a special syntax unless it has benefits (like improved safety).

[Alexandre_Lopoukhine]

I'm not sure * is a good conceptual fit, since you're really raising T to the power of N. A textual approach seems safer, if more verbose. In an ideal world we'd have something like literal types in Scala, which would allow these integers as type parameters be completely above board, by declaring something like: struct FixedSizeTuple<Value, Power: IntegerLiteralType>.

[SafelySwift]

I just want to point out that FixedArray already exists as an underscored type from GYB.

[xwu]

Please avoid resurrecting three-year-old threads. Among other reasons, it emails previous participants some of whom would not be interested in this topic at this time.

[John_Randolph1]

What are you talking about?

-jcr

[sveinhal]

What are you talking about?

You received this because someone commented on a three year old thread on the (not so) new forums.swift.org website. Ref: Proposal: Contiguous Variables (A.K.A. Fixed Sized Array Type)