I think that a (4 * Int) syntax or equivalent for uniform tuples and making them subscriptable would be very helpful when dealing with C APIs that export structures with arrays in them.
Félix
···
Le 28 janv. 2016 à 17:46:40, Joe Groff via swift-evolution <swift-evolution@swift.org> a écrit :
On Jan 28, 2016, at 2:40 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
What is a "type-level integer expression"? The only thing I can think of is allowing numeric parameters to generics, like "Tuple<4, Int>", but I don't think that's what you're talking about.
That's what I mean, yeah. If we allow integers as type parameters, you'd conceivably want to use integer literals and expressions in this position too.
-Joe
Jacob
On Thu, Jan 28, 2016 at 2:38 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
> On Jan 28, 2016, at 2:37 PM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
>
>
>> On Jan 28, 2016, at 2:36 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
>>
>> I like this idea, but the syntax seems dangerously close to a call site for "func *(lhs: Int, rhs: Any.Type)" (which is obviously ill-advised, but it is allowed).
>>
>> Maybe we could take advantage of something which would be very invalid under the current grammar, namely (n T) rather than (n * T):
>>
>> let values: (4 Int) = (1, 2, 3, 4)
Bare juxtaposition might be problematic if we ever do introduce type-level integer expressions, though.
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.
Best,
Austin
···
On Jan 29, 2016, at 10:00 AM, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:
Le 29 janv. 2016 à 00:50:52, Chris Lattner <clattner@apple.com> a écrit :
On Jan 28, 2016, at 9:41 PM, Félix Cloutier <felixcca@yahoo.ca> wrote:
I think that (4 x Int) needs to be syntax sugar for (Int, Int, Int, Int). Not having them the same would introduce awkward cases into the language.
Agreed. This means that:
let values: (4 x Int)(repeatedValue: 0) // Is this possible?
will not be possible.
Why will it be possible to add a subscript but not an initializer?
Because of that, I also think that forcing people to use the subscript would have some awkward consequences. What if I have a func<T, U> that uses a (T, U) tuple and both T and U happen to be the same type?
I don’t understand this concern.
If direct element access is disallowed on homogeneous tuples, to me, it would look like a bug that you can use direct element access on a (T, U) tuple from a generic function with <T, U> parameters, but not anywhere else. But regardless, we seem to agree that homogeneous tuples shouldn't lose direct member access.
You'd still need something to define FixedArray<N> in terms of:
struct FixedArray<T,N: Int> { var values: (N x T) }
-Joe
···
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.
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) }
It doesn't foreclose on the future possibility, either. With integer generic parameters you could conceivably build something like that out of a primitive fixed-size tuple type.
-Joe
···
On Jan 29, 2016, at 1:11 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jan 28 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Jan 28, 2016, at 9:41 PM, Félix Cloutier <felixcca@yahoo.ca> wrote:
I think that (4 x Int) needs to be syntax sugar for (Int, Int, Int,
Int). Not having them the same would introduce awkward cases into
the language.
Agreed. This means that:
let values: (4 x Int)(repeatedValue: 0) // Is this possible?
will not be possible.
I think this avenue leaves some really crucial use-cases on the table,
e.g. implementing bounded-size dynamically-growable arrays.
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.
···
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
I really don’t like the x as an operator either, because I use x for so many other things in my code.
My typical use case for contiguous variables would be images, e.g:
struct RGBAPixel {
var red: Int8
var green:Int8
var blue:Int8
var alpha:Int8
}
let myImage : RGBAPixel[512 * 515] = someCFunctionThatReturnsABitmap() as! RGBAPixel
I recently needed to do this kind of thing in a Swift tool that converted images into CIColorCubes, and it was nightmarish. I almost reverted to C to get it done.
On a related note, I’d really love to have a way to declare multi-dimensional arrays and be able to name the axes.
-jcr
···
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 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.
- Dave Sweeris
···
On Feb 9, 2016, at 12:57, Chris Lattner <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).
Tuples currently can’t conform to protocols, can they?
- Dave Sweeris
···
On Jan 29, 2016, at 11:14, Trent Nadeau via swift-evolution <swift-evolution@swift.org> 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.
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
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 Jan 29, 2016, at 11:14 AM, Trent Nadeau <tanadeau@gmail.com> wrote:
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
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?:
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
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@apple.com> wrote:
On Jan 29, 2016, at 1:41 PM, 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.).
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@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?:
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
I know, but I am not a fan of designing language features that are
clearly related to other things we definitely will want to do without
considering specifically how those other things fit into the picture.
···
on Fri Jan 29 2016, Joe Groff <swift-evolution@swift.org> wrote:
On Jan 29, 2016, at 1:11 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jan 28 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Jan 28, 2016, at 9:41 PM, Félix Cloutier <felixcca@yahoo.ca> wrote:
I think that (4 x Int) needs to be syntax sugar for (Int, Int, Int,
Int). Not having them the same would introduce awkward cases into
the language.
Agreed. This means that:
let values: (4 x Int)(repeatedValue: 0) // Is this possible?
will not be possible.
I think this avenue leaves some really crucial use-cases on the table,
e.g. implementing bounded-size dynamically-growable arrays.
It doesn't foreclose on the future possibility, either. With integer
generic parameters you could conceivably build something like that out
of a primitive fixed-size tuple type.
On a related note, I’d really love to have a way to declare multi-dimensional arrays and be able to name the axes.
I would like to strongly second John Randolph’s request for a multi-dimensional arrays, otherwise known as matrices. There is currently GLKMatrix3 and GLKMatrix4, which hold CGFloats. But it would be more useful to for matrix members to be Float, Double, Int, String, etc..
var aMatrix: Matrix<Int> = Matrix(row: 6, columns: 20)
I would also like to request quaternions and tensors in Swift. Currently quaternions can be had via GLKQuaternion, but it holds only CGFloat variables. There are times I would like to instead use Double.
I agree that it wouldn’t be acceptable to take x as a keyword.
-Chris
···
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.
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
···
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 <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.
On Jan 29, 2016, at 1:47 PM, Trent Nadeau <tanadeau@gmail.com> wrote:
On Fri, Jan 29, 2016 at 4:45 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Jan 29, 2016, at 1:41 PM, Trent Nadeau via swift-evolution <swift-evolution@swift.org <mailto: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.).
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@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?:
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
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?:
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
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.
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: Home · SwiftInofficialEvolution/Home Wiki · GitHub)