<div dir="ltr">Personally I'd prefer not to overlap with potential user defined operators. It may be good to make it something like this:<div><font face="monospace, monospace"> (Int, Int) (Float, String)</font></div><div>Becomes:</div><div><font size="2" face="monospace, monospace"><span style="background-color:rgba(255,255,255,0)"> (Int, Int, Float, String)</span></font></div><div><br></div><div>This is similar to C where you can write "hello" " world" to make a string "hello world".</div><div><br></div><div>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.<br></div><div><br>On Monday, 8 February 2016, Maximilian Hünenberger <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>We should clarify whether we see Tuples as Vectors/Matrices or Lists/Arrays since "+" has different meanings:</div><div><br></div><div><br></div><div><span style="white-space:pre-wrap"> </span>Adding individual Numbers<span style="white-space:pre-wrap"> </span>Concatenating</div><div>---------------------------------------------------------------------------------------------------------------------</div><div>Vector: <span style="white-space:pre-wrap"> </span>(1, 2) + (3, 4) = (4, 6)<span style="white-space:pre-wrap"> </span>((1, 2) | (3, 4)) = (1, 2, 3, 4) // mathematically not fully correct</div><div>List: <span style="white-space:pre-wrap"> </span>zip((1, 2), (3, 4)).map{ $0.0 + $0.1 } = (4, 6)<span style="white-space:pre-wrap"> </span>(1, 2) + (3, 4) = (1, 2, 3, 4)</div><div><br></div><div><br></div><div>In my opinion Tuples are generally heterogenous ordered lists since they can also contain elements of different types.</div><div><br></div><div>This thread<b> </b>"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.</div><div><br></div><div>Note: Treating them as vectors operators like "+", "-" and "*" are (almost) only defined on number Tuples and only two Tuples with specific dimensions.</div><div><br></div><div>- Maximilian</div><br><div><blockquote type="cite"><div>Am 07.02.2016 um 19:53 schrieb David Sweeris via swift-evolution <<a>swift-evolution@swift.org</a>>:</div><br><div><div dir="auto"><div>Good point.</div><div><br>Sent from my iPhone</div><div><br>On Feb 7, 2016, at 10:43, Patrick Gili <<a>gili.patrick.r@gili-labs.com</a>> wrote:<br><br></div><blockquote type="cite"><div>"|" denotes bitwise-OR. Not necessarily a great choice.<div><br></div><div>-Patrick</div><div><br><div><blockquote type="cite"><div>On Feb 7, 2016, at 1:41 PM, David Sweeris <<a>davesweeris@mac.com</a>> wrote:</div><br><div><div dir="auto"><div>Yeah, that's better than "+" or "&". What about "|"?<br><br>Sent from my iPhone</div><div><br>On Feb 7, 2016, at 08:12, Patrick Gili via swift-evolution <<a>swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>What about using << to denote concatenation? Many languages use this operator to denote "append", which is essentially concatenate.<div><br></div><div>-Patrick</div><div><br><div><blockquote type="cite"><div>On Feb 6, 2016, at 5:41 PM, Andrew Bennett via swift-evolution <<a>swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">Thanks Tino, it would be good to come up with some alternatives for +.<div><br></div><div>I was initially thinking `<font face="monospace, monospace">(Int,Int) (Int,Int)</font>` without operators. However I think this could potentially be a mistake. I like + as it's familiar with array operators.</div><div><br></div><div>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.</div><div><br></div><div>For some more examples have a look at the linked proposal :)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 31, 2016 at 11:28 PM, Tino Heth <span dir="ltr"><<a>2th@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div><div dir="ltr"><div>I'd like a <span style="color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'">a way to concatenate tuple types together:</span><br></div><div><span style="color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'"><br></span></div><div><div style="margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'"><pre style="overflow:auto;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;margin-top:0px;margin-bottom:0px;line-height:1.45;padding:16px;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-wrap:normal"><span style="color:rgb(167,29,93)">typealias</span> ABCD <span style="color:rgb(167,29,93)">=</span> (A,B)<span style="color:rgb(167,29,93)">+</span>(C,D) <span style="color:rgb(150,152,150)">// Same as (A,B,C,D)</span></pre></div></div></div></div></blockquote></span><div>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 ;-)</div><div>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).</div><span><br><blockquote type="cite"><div><div dir="ltr"><div><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'">Also a way to allow tuples to be converted to other tuples that are the same when flattened:</p><div style="margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'"><pre style="overflow:auto;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;margin-top:0px;margin-bottom:0px;line-height:1.45;padding:16px;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-wrap:normal">(a,(b,c),d) <span style="color:rgb(167,29,93)">as</span> ((a,b),(c,d))</pre></div></div></div></div></blockquote></span></div>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.<div><br></div><div>That leads me to an unrelated thought:</div><div>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...</div><span><font color="#888888"><div><br></div><div>Tino</div></font></span></div></blockquote></div><br></div>
_______________________________________________<br>swift-evolution mailing list<br><a>swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a>swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></blockquote></div><br></div></div></blockquote></div>_______________________________________________<br>swift-evolution mailing list<br><a>swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></blockquote></div>
</div>