Tuple conversion and type composition

Evolution Discussion
1

Hi Swift Evolution populace,

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

Also a way to allow tuples to be converted to other tuples that are the
same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

This proposal aims to make the minimal changes possible, with the most
familiar syntax, and give tuples this power.
Examples
These are things that will be possible after these changes.
Joining two tuples together

let a = (1,2), b = (3,4)let c = join(a, b) // (Int,Int,Int,Int)

Stack like operations on tuples

let (abcde) = (1,2,3,4,5)let (abcd,e) = pop(abcde)let (abc,d) =
pop(abcd)let (abce) = push(abc, e)assert(abce == (1,2,3,5))

Chained ZipSequence

let a = [1,2,3]let b = ["a", "b", "c"]let c = [1.2, 2.3, 3.4]let d =
[nil, nil, 123]let abc = a.zip(b).zip(c).zip(d) //
AnySequence<(Int,String,Float,Int?)>

Turn any function with a callback into one with a promise

func promise<A,B,C>(f: (A + (B->Void)) -> C) -> A -> (C, Promise<B>)

This proposal, and more examples, can be seen in more detail here:

I'll keep this file up to date over the course of the discussion, PRs are
welcome.

*Related proposals:*

This proposal's use cases relate to at least a few other currently active
proposals:

   - *Compile-time parameters*
   - *http://thread.gmane.org/gmane.comp.lang.swift.evolution/5240
      <http://thread.gmane.org/gmane.comp.lang.swift.evolution/5240&gt;\*
   - *Contiguous Variables (A.K.A. Fixed Sized Array Type)*

···

-
*http://thread.gmane.org/gmane.comp.lang.swift.evolution/4809
      <http://thread.gmane.org/gmane.comp.lang.swift.evolution/4809&gt; *
   -
*Remove implicit tuple splat behavior from function applications *
      - *http://thread.gmane.org/gmane.comp.lang.swift.evolution/4681
      <http://thread.gmane.org/gmane.comp.lang.swift.evolution/4681&gt;\*

Thanks!

2

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to tuples would be neat… you just need to find examples with convincing motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of tuples in language and libraries, so I wouldn't be surprised if their importance rises in the future (and maybe we can think of nice ways to combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two types have a compatible memory-layout, and if that is the case, let me use them interchangeable when I tell you to do so) could be extended to structs — that could solve the problem of different implementations of fundamental types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one side, and structs and tuples on the other — tuples feel very much like anonymous structs (restricted by the fact that you cannot add methods like custom getters & setters). It's not related to you proposal, but I wonder if there are implications visible from this point of view...

Tino

3

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However I
think this could potentially be a mistake. I like + as it's familiar with
array operators.

As for the prevalence of tuples in the language, every function and value
in Swift has a tuple in it. The associated values in an enum are a tuple.
They are everywhere.

For some more examples have a look at the linked proposal :)

···

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to
tuples would be neat… you just need to find examples with convincing
motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of
tuples in language and libraries, so I wouldn't be surprised if their
importance rises in the future (and maybe we can think of nice ways to
combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the
same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two
types have a compatible memory-layout, and if that is the case, let me use
them interchangeable when I tell you to do so) could be extended to structs
— that could solve the problem of different implementations of fundamental
types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one
side, and structs and tuples on the other — tuples feel very much like
anonymous structs (restricted by the fact that you cannot add methods like
custom getters & setters). It's not related to you proposal, but I wonder
if there are implications visible from this point of view...

Tino

4

If we had a sufficiently generalized "splat" operation to unpack tuples into argument or tuple lists, you could conceivably use it to do this:

typealias AB = (A,B)
typealias CD = (C,D)
typealias ABCD = (AB..., CD...)

func join<T, U>(_ a: (T...), _ b: (U...)) -> (T..., U...) {
  return (a..., b...)
}

func pop<T, U>(_ tuple: (T..., U)) -> ((T...), U) {
  let (a..., b) = tuple
  return (a, b)
}

func push<T, U>(_ tuple: (T...), _ back: U) -> (T..., U) {
  return (tuple..., back)
}

-Joe

···

On Jan 30, 2016, at 9:14 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org> wrote:

Hi Swift Evolution populace,

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)
Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))
This proposal aims to make the minimal changes possible, with the most familiar syntax, and give tuples this power.

Examples

These are things that will be possible after these changes.
Joining two tuples together

let a = (1,2), b = (3,4)
let c = join(a, b) // (Int,Int,Int,Int)

Stack like operations on tuples

let (abcde) = (1,2,3,4,5)
let (abcd,e) = pop(abcde)
let (abc,d) = pop(abcd)
let (abce) = push(abc, e)
assert(abce == (1,2,3,5))
Chained ZipSequence

let a = [1,2,3]
let b = ["a", "b", "c"]
let c = [1.2, 2.3, 3.4]
let d = [nil, nil, 123]
let abc = a.zip(b).zip(c).zip(d) // AnySequence<(Int,String,Float,Int?)>
Turn any function with a callback into one with a promise

func promise<A,B,C>(f: (A + (B->Void)) -> C) -> A -> (C, Promise<B>)
This proposal, and more examples, can be seen in more detail here:

    https://github.com/therealbnut/swift-evolution/blob/therealbnut-tuple-manipulation/proposals/0000-tuple-operators.md

I'll keep this file up to date over the course of the discussion, PRs are welcome.

Related proposals:

This proposal's use cases relate to at least a few other currently active proposals:
Compile-time parameters
http://thread.gmane.org/gmane.comp.lang.swift.evolution/5240
Contiguous Variables (A.K.A. Fixed Sized Array Type)
http://thread.gmane.org/gmane.comp.lang.swift.evolution/4809
Remove implicit tuple splat behavior from function applications
http://thread.gmane.org/gmane.comp.lang.swift.evolution/4681
Thanks!
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

How about "&"? That way you can still define:
func + (lhs: (Int, Int), rhs: (Int, Int)) -> (Int, Int) {...}
Without either removing the ability to concatenate tuples, or having to annotate types all over the place to resolve the ambiguities. (I'd love to use a different operator for concatenating Arrays & Strings, as well, but that's not what this thread is about)

- Dave Sweeris

···

On Feb 6, 2016, at 14:41, Andrew Bennett via swift-evolution <swift-evolution@swift.org> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However I think this could potentially be a mistake. I like + as it's familiar with array operators.

As for the prevalence of tuples in the language, every function and value in Swift has a tuple in it. The associated values in an enum are a tuple. They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to tuples would be neat… you just need to find examples with convincing motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of tuples in language and libraries, so I wouldn't be surprised if their importance rises in the future (and maybe we can think of nice ways to combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two types have a compatible memory-layout, and if that is the case, let me use them interchangeable when I tell you to do so) could be extended to structs — that could solve the problem of different implementations of fundamental types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one side, and structs and tuples on the other — tuples feel very much like anonymous structs (restricted by the fact that you cannot add methods like custom getters & setters). It's not related to you proposal, but I wonder if there are implications visible from this point of view...

Tino

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

6

What about using << to denote concatenation? Many languages use this operator to denote "append", which is essentially concatenate.

-Patrick

···

On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However I think this could potentially be a mistake. I like + as it's familiar with array operators.

As for the prevalence of tuples in the language, every function and value in Swift has a tuple in it. The associated values in an enum are a tuple. They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to tuples would be neat… you just need to find examples with convincing motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of tuples in language and libraries, so I wouldn't be surprised if their importance rises in the future (and maybe we can think of nice ways to combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two types have a compatible memory-layout, and if that is the case, let me use them interchangeable when I tell you to do so) could be extended to structs — that could solve the problem of different implementations of fundamental types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one side, and structs and tuples on the other — tuples feel very much like anonymous structs (restricted by the fact that you cannot add methods like custom getters & setters). It's not related to you proposal, but I wonder if there are implications visible from this point of view...

Tino

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

7

Yeah, that's better than "+" or "&". What about "|"?

···

Sent from my iPhone

On Feb 7, 2016, at 08:12, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

What about using << to denote concatenation? Many languages use this operator to denote "append", which is essentially concatenate.

-Patrick

On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However I think this could potentially be a mistake. I like + as it's familiar with array operators.

As for the prevalence of tuples in the language, every function and value in Swift has a tuple in it. The associated values in an enum are a tuple. They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to tuples would be neat… you just need to find examples with convincing motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of tuples in language and libraries, so I wouldn't be surprised if their importance rises in the future (and maybe we can think of nice ways to combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two types have a compatible memory-layout, and if that is the case, let me use them interchangeable when I tell you to do so) could be extended to structs — that could solve the problem of different implementations of fundamental types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one side, and structs and tuples on the other — tuples feel very much like anonymous structs (restricted by the fact that you cannot add methods like custom getters & setters). It's not related to you proposal, but I wonder if there are implications visible from this point of view...

Tino

_______________________________________________
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

8

"|" denotes bitwise-OR. Not necessarily a great choice.

-Patrick

···

On Feb 7, 2016, at 1:41 PM, David Sweeris <davesweeris@mac.com> wrote:

Yeah, that's better than "+" or "&". What about "|"?

Sent from my iPhone

On Feb 7, 2016, at 08:12, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What about using << to denote concatenation? Many languages use this operator to denote "append", which is essentially concatenate.

-Patrick

On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However I think this could potentially be a mistake. I like + as it's familiar with array operators.

As for the prevalence of tuples in the language, every function and value in Swift has a tuple in it. The associated values in an enum are a tuple. They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to tuples would be neat… you just need to find examples with convincing motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of tuples in language and libraries, so I wouldn't be surprised if their importance rises in the future (and maybe we can think of nice ways to combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two types have a compatible memory-layout, and if that is the case, let me use them interchangeable when I tell you to do so) could be extended to structs — that could solve the problem of different implementations of fundamental types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one side, and structs and tuples on the other — tuples feel very much like anonymous structs (restricted by the fact that you cannot add methods like custom getters & setters). It's not related to you proposal, but I wonder if there are implications visible from this point of view...

Tino

_______________________________________________
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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

9

What about using << to denote concatenation? Many languages use this operator to denote "append", which is essentially concatenate.

Random comment: the swift approach is generally to define new operators for new operations. We really don’t like the C++ approach of overloading existing operators to mean different things in different contexts.

-Chris

···

On Feb 7, 2016, at 8:12 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

-Patrick

On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However I think this could potentially be a mistake. I like + as it's familiar with array operators.

As for the prevalence of tuples in the language, every function and value in Swift has a tuple in it. The associated values in an enum are a tuple. They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to tuples would be neat… you just need to find examples with convincing motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of tuples in language and libraries, so I wouldn't be surprised if their importance rises in the future (and maybe we can think of nice ways to combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two types have a compatible memory-layout, and if that is the case, let me use them interchangeable when I tell you to do so) could be extended to structs — that could solve the problem of different implementations of fundamental types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one side, and structs and tuples on the other — tuples feel very much like anonymous structs (restricted by the fact that you cannot add methods like custom getters & setters). It's not related to you proposal, but I wonder if there are implications visible from this point of view...

Tino

_______________________________________________
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

10

Good point.

···

Sent from my iPhone

On Feb 7, 2016, at 10:43, Patrick Gili <gili.patrick.r@gili-labs.com> wrote:

"|" denotes bitwise-OR. Not necessarily a great choice.

-Patrick

On Feb 7, 2016, at 1:41 PM, David Sweeris <davesweeris@mac.com> wrote:

Yeah, that's better than "+" or "&". What about "|"?

Sent from my iPhone

On Feb 7, 2016, at 08:12, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

What about using << to denote concatenation? Many languages use this operator to denote "append", which is essentially concatenate.

-Patrick

On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However I think this could potentially be a mistake. I like + as it's familiar with array operators.

As for the prevalence of tuples in the language, every function and value in Swift has a tuple in it. The associated values in an enum are a tuple. They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to tuples would be neat… you just need to find examples with convincing motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of tuples in language and libraries, so I wouldn't be surprised if their importance rises in the future (and maybe we can think of nice ways to combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two types have a compatible memory-layout, and if that is the case, let me use them interchangeable when I tell you to do so) could be extended to structs — that could solve the problem of different implementations of fundamental types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one side, and structs and tuples on the other — tuples feel very much like anonymous structs (restricted by the fact that you cannot add methods like custom getters & setters). It's not related to you proposal, but I wonder if there are implications visible from this point of view...

Tino

_______________________________________________
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

11

We should clarify whether we see Tuples as Vectors/Matrices or Lists/Arrays since "+" has different meanings:

    Adding individual Numbers Concatenating

···

---------------------------------------------------------------------------------------------------------------------
Vector: (1, 2) + (3, 4) = (4, 6) ((1, 2) | (3, 4)) = (1, 2, 3, 4) // mathematically not fully correct
List: zip((1, 2), (3, 4)).map{ $0.0 + $0.1 } = (4, 6) (1, 2) + (3, 4) = (1, 2, 3, 4)

In my opinion Tuples are generally heterogenous ordered lists since they can also contain elements of different types.

This thread "Contiguous Variables (A.K.A. Fixed Sized Array Type)" which discusses the use of "(4 x Int)" as sugar for "(Int, Int, Int, Int)". It suggest more of a vector/matrix-like behavior of Tuples.

Note: Treating them as vectors operators like "+", "-" and "*" are (almost) only defined on number Tuples and only two Tuples with specific dimensions.

- Maximilian

Am 07.02.2016 um 19:53 schrieb David Sweeris via swift-evolution <swift-evolution@swift.org>:

Good point.

Sent from my iPhone

On Feb 7, 2016, at 10:43, Patrick Gili <gili.patrick.r@gili-labs.com <mailto:gili.patrick.r@gili-labs.com>> wrote:

"|" denotes bitwise-OR. Not necessarily a great choice.

-Patrick

On Feb 7, 2016, at 1:41 PM, David Sweeris <davesweeris@mac.com <mailto:davesweeris@mac.com>> wrote:

Yeah, that's better than "+" or "&". What about "|"?

Sent from my iPhone

On Feb 7, 2016, at 08:12, Patrick Gili via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What about using << to denote concatenation? Many languages use this operator to denote "append", which is essentially concatenate.

-Patrick

On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However I think this could potentially be a mistake. I like + as it's familiar with array operators.

As for the prevalence of tuples in the language, every function and value in Swift has a tuple in it. The associated values in an enum are a tuple. They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de <mailto:2th@gmx.de>> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to tuples would be neat… you just need to find examples with convincing motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of tuples in language and libraries, so I wouldn't be surprised if their importance rises in the future (and maybe we can think of nice ways to combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two types have a compatible memory-layout, and if that is the case, let me use them interchangeable when I tell you to do so) could be extended to structs — that could solve the problem of different implementations of fundamental types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one side, and structs and tuples on the other — tuples feel very much like anonymous structs (restricted by the fact that you cannot add methods like custom getters & setters). It's not related to you proposal, but I wonder if there are implications visible from this point of view...

Tino

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

12

What about using << to denote concatenation? Many languages use this operator to denote "append", which is essentially concatenate.

Random comment: the swift approach is generally to define new operators for new operations. We really don’t like the C++ approach of overloading existing operators to mean different things in different contexts.

Thank you!

···

Sent from my iPhone

On 8 Feb 2016, at 20:55, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 7, 2016, at 8:12 AM, Patrick Gili via swift-evolution <swift-evolution@swift.org> wrote:

-Chris

-Patrick

On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution <swift-evolution@swift.org> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However I think this could potentially be a mistake. I like + as it's familiar with array operators.

As for the prevalence of tuples in the language, every function and value in Swift has a tuple in it. The associated values in an enum are a tuple. They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to tuples would be neat… you just need to find examples with convincing motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of tuples in language and libraries, so I wouldn't be surprised if their importance rises in the future (and maybe we can think of nice ways to combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two types have a compatible memory-layout, and if that is the case, let me use them interchangeable when I tell you to do so) could be extended to structs — that could solve the problem of different implementations of fundamental types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one side, and structs and tuples on the other — tuples feel very much like anonymous structs (restricted by the fact that you cannot add methods like custom getters & setters). It's not related to you proposal, but I wonder if there are implications visible from this point of view...

Tino

_______________________________________________
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

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

13

Personally I'd prefer not to overlap with potential user defined operators.
It may be good to make it something like this:
    (Int, Int) (Float, String)
Becomes:
    (Int, Int, Float, String)

This is similar to C where you can write "hello" " world" to make a string
"hello world".

I don't think there's any syntactic ambiguity with that. I think it's fine
to use special syntax rather than an operator as it requires compile/time
support anyway.

···

On Monday, 8 February 2016, Maximilian Hünenberger < swift-evolution@swift.org> wrote:

We should clarify whether we see Tuples as Vectors/Matrices or
Lists/Arrays since "+" has different meanings:

Adding individual Numbers Concatenating

---------------------------------------------------------------------------------------------------------------------
Vector: (1, 2) + (3, 4) = (4, 6) ((1, 2) | (3, 4)) = (1, 2, 3, 4) //
mathematically not fully correct
List: zip((1, 2), (3, 4)).map{ $0.0 + $0.1 } = (4, 6) (1, 2) + (3, 4)
= (1, 2, 3, 4)

In my opinion Tuples are generally heterogenous ordered lists since they
can also contain elements of different types.

This thread "Contiguous Variables (A.K.A. Fixed Sized Array Type)" which
discusses the use of "(4 x Int)" as sugar for "(Int, Int, Int, Int)". It
suggest more of a vector/matrix-like behavior of Tuples.

Note: Treating them as vectors operators like "+", "-" and "*" are
(almost) only defined on number Tuples and only two Tuples with specific
dimensions.

- Maximilian

Am 07.02.2016 um 19:53 schrieb David Sweeris via swift-evolution < > swift-evolution@swift.org>:

Good point.

Sent from my iPhone

On Feb 7, 2016, at 10:43, Patrick Gili <gili.patrick.r@gili-labs.com> > wrote:

"|" denotes bitwise-OR. Not necessarily a great choice.

-Patrick

On Feb 7, 2016, at 1:41 PM, David Sweeris <davesweeris@mac.com> wrote:

Yeah, that's better than "+" or "&". What about "|"?

Sent from my iPhone

On Feb 7, 2016, at 08:12, Patrick Gili via swift-evolution < > swift-evolution@swift.org> wrote:

What about using << to denote concatenation? Many languages use this
operator to denote "append", which is essentially concatenate.

-Patrick

On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution < > swift-evolution@swift.org> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However
I think this could potentially be a mistake. I like + as it's familiar with
array operators.

As for the prevalence of tuples in the language, every function and value
in Swift has a tuple in it. The associated values in an enum are a tuple.
They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to
tuples would be neat… you just need to find examples with convincing
motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of
tuples in language and libraries, so I wouldn't be surprised if their
importance rises in the future (and maybe we can think of nice ways to
combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the
same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two
types have a compatible memory-layout, and if that is the case, let me use
them interchangeable when I tell you to do so) could be extended to structs
— that could solve the problem of different implementations of fundamental
types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one
side, and structs and tuples on the other — tuples feel very much like
anonymous structs (restricted by the fact that you cannot add methods like
custom getters & setters). It's not related to you proposal, but I wonder
if there are implications visible from this point of view...

Tino

_______________________________________________
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

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

14

Even though I do a lot of matrix maths I would prefer a homogeneous tuple
to be a collection; it has more use cases.

···

On Monday, 8 February 2016, Maximilian Hünenberger < swift-evolution@swift.org> wrote:

We should clarify whether we see Tuples as Vectors/Matrices or
Lists/Arrays since "+" has different meanings:

Adding individual Numbers Concatenating

---------------------------------------------------------------------------------------------------------------------
Vector: (1, 2) + (3, 4) = (4, 6) ((1, 2) | (3, 4)) = (1, 2, 3, 4) //
mathematically not fully correct
List: zip((1, 2), (3, 4)).map{ $0.0 + $0.1 } = (4, 6) (1, 2) + (3, 4)
= (1, 2, 3, 4)

In my opinion Tuples are generally heterogenous ordered lists since they
can also contain elements of different types.

This thread "Contiguous Variables (A.K.A. Fixed Sized Array Type)" which
discusses the use of "(4 x Int)" as sugar for "(Int, Int, Int, Int)". It
suggest more of a vector/matrix-like behavior of Tuples.

Note: Treating them as vectors operators like "+", "-" and "*" are
(almost) only defined on number Tuples and only two Tuples with specific
dimensions.

- Maximilian

Am 07.02.2016 um 19:53 schrieb David Sweeris via swift-evolution < > swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>>:

Good point.

Sent from my iPhone

On Feb 7, 2016, at 10:43, Patrick Gili <gili.patrick.r@gili-labs.com > <javascript:_e(%7B%7D,'cvml','gili.patrick.r@gili-labs.com');>> wrote:

"|" denotes bitwise-OR. Not necessarily a great choice.

-Patrick

On Feb 7, 2016, at 1:41 PM, David Sweeris <davesweeris@mac.com > <javascript:_e(%7B%7D,'cvml','davesweeris@mac.com');>> wrote:

Yeah, that's better than "+" or "&". What about "|"?

Sent from my iPhone

On Feb 7, 2016, at 08:12, Patrick Gili via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

What about using << to denote concatenation? Many languages use this
operator to denote "append", which is essentially concatenate.

-Patrick

On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Thanks Tino, it would be good to come up with some alternatives for +.

I was initially thinking `(Int,Int) (Int,Int)` without operators. However
I think this could potentially be a mistake. I like + as it's familiar with
array operators.

As for the prevalence of tuples in the language, every function and value
in Swift has a tuple in it. The associated values in an enum are a tuple.
They are everywhere.

For some more examples have a look at the linked proposal :)

On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <2th@gmx.de > <javascript:_e(%7B%7D,'cvml','2th@gmx.de');>> wrote:

I'd like a a way to concatenate tuple types together:

typealias ABCD = (A,B)+(C,D) // Same as (A,B,C,D)

I don't like the use of "+" for concatenation, but giving more power to
tuples would be neat… you just need to find examples with convincing
motivation ;-)
Obviously, the value of tuple-operation increases with the prevalence of
tuples in language and libraries, so I wouldn't be surprised if their
importance rises in the future (and maybe we can think of nice ways to
combine tuple-related ideas).

Also a way to allow tuples to be converted to other tuples that are the
same when flattened:

(a,(b,c),d) as ((a,b),(c,d))

It would be cool if such a concept ("compiler, please check if those two
types have a compatible memory-layout, and if that is the case, let me use
them interchangeable when I tell you to do so) could be extended to structs
— that could solve the problem of different implementations of fundamental
types nicely.

That leads me to an unrelated thought:
It seems to me there is a duality between methods and closures on one
side, and structs and tuples on the other — tuples feel very much like
anonymous structs (restricted by the fact that you cannot add methods like
custom getters & setters). It's not related to you proposal, but I wonder
if there are implications visible from this point of view...

Tino

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

--
  -- Howard.

15

Assuming things move forward in terms of tuples/bridging, my primary use-case is/will/would be Accelerate, CGContext buffers and stuff like CGColor 4-tuples.

-- E

···

On Feb 8, 2016, at 2:02 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

Even though I do a lot of matrix maths I would prefer a homogeneous tuple to be a collection; it has more use cases.