[swift-evolution] Tuple conversion and type composition

Maximilian Hünenberger m.huenenberger at me.com
Sun Feb 7 18:34:19 CST 2016


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 at swift.org>:
> 
> Good point.
> 
> Sent from my iPhone
> 
> On Feb 7, 2016, at 10:43, Patrick Gili <gili.patrick.r at gili-labs.com <mailto:gili.patrick.r at gili-labs.com>> wrote:
> 
>> "|" denotes bitwise-OR. Not necessarily a great choice.
>> 
>> -Patrick
>> 
>>> On Feb 7, 2016, at 1:41 PM, David Sweeris <davesweeris at mac.com <mailto:davesweeris at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 at gmx.de <mailto:2th at 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 at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160208/e5eda1f3/attachment-0001.html>


More information about the swift-evolution mailing list