[swift-evolution] Tuple conversion and type composition

[Andrew Bennett]

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 at 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 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>
> wrote:
>
> "|" denotes bitwise-OR. Not necessarily a great choice.
>
> -Patrick
>
> On Feb 7, 2016, at 1:41 PM, David Sweeris <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> 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> 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> 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
> 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
>
>
> _______________________________________________
> 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/4aa2523f/attachment.html>