<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">At a high level, I would think that a tuple would just be considered a “typed” heterogeneous list of values - that you should be able to access the same way that you access any list - same functions (map, reduce, etc.). &nbsp;<div class=""><br class=""></div><div class="">I guess you could view the “labels” as a quasi-column header of some sort, which means although you might not be able to “convert” from (a: Int, b: Int) to (x: Int, y: Int) …. you would be able to `map` the values and the "column headers” to (x: Int, y: Int).</div><div class=""><br class=""></div></div></blockquote><div class=""><br class=""></div>Shameless plug: which of course would make the concept of `cases` within the mapping of values within the tuple (heterogeneous list) very useful :p<br class=""><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On 2016-02-05, at 22:17:55, Craig Cruden &lt;<a href="mailto:ccruden@novafore.com" class="">ccruden@novafore.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">At a high level, I would think that a tuple would just be considered a “typed” heterogeneous list of values - that you should be able to access the same way that you access any list - same functions (map, reduce, etc.). &nbsp;<div class=""><br class=""></div><div class="">I guess you could view the “labels” as a quasi-column header of some sort, which means although you might not be able to “convert” from (a: Int, b: Int) to (x: Int, y: Int) …. you would be able to `map` the values and the "column headers” to (x: Int, y: Int).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 2016-02-05, at 19:41:19, Maximilian Hünenberger via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class="">Sleeping over it I have to give -1 to the proposal. However we should consider making explicit casts with "as" to different tuple types with and without labels (separate proposal).</div><div class=""><br class=""></div><div class="">- Maximilian</div><div class=""><br class="">Am 05.02.2016 um 08:08 schrieb Taras Zakharko via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt;:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">The types are clearly different and the current behaviour is fine as it is.&nbsp;<div class=""><br class=""></div><div class="">However, it would be nice to have more support for tuple types in the language. E.g. I’d expect something like this</div><div class=""><br class=""></div><div class="">&nbsp;&nbsp;<span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures; color: rgb(187, 44, 162);" class="">let</span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class=""> x = (a:</span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures; color: rgb(39, 42, 216);" class="">4</span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class="">, b:</span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures; color: rgb(39, 42, 216);" class="">5</span><span style="font-family: Menlo; font-size: 11px; font-variant-ligatures: no-common-ligatures;" class="">)</span></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">&nbsp;let y = x as (m: Int, n: Int)</span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class=""><br class=""></span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">to work (but it doesn’t currently, you have to use forced cast).&nbsp;</span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class=""><br class=""></span></font></div><div class=""><font face="Menlo" class=""><span style="font-size: 11px;" class="">— Taras</span><br class=""></font><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 05 Feb 2016, at 07:47, Ondrej Barina via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">-1 for proposal. Current behavior is fine. There is no need to change it<br class="">
Ondrej b.<br class="">
</p>
<div class="gmail_quote">On Feb 5, 2016 12:56 AM, "Chris Lattner via swift-evolution" &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br type="attribution" class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
&gt; On Feb 4, 2016, at 3:26 PM, Maximilian Hünenberger &lt;<a href="mailto:m.huenenberger@me.com" class="">m.huenenberger@me.com</a>&gt; wrote:<br class="">
&gt;<br class="">
&gt; Is this behavior intended?<br class="">
&gt;<br class="">
&gt; What disadvantage do I have if a conversion from (a: Int, b: Int) to (x: Int, y: Int) is allowed?<br class="">
<br class="">
If that were allowed, then it also stands to reason that a conversion from “(a: Int, b : Int)” to “(b: Int, a : Int)” would also work… but would not swap the elements.&nbsp; IMO, it is best to disallow things misleading things like this.<br class="">
<br class="">
-Chris<br class="">
<br class="">
&gt;<br class="">
&gt;<br class="">
&gt; Thank you for clarification<br class="">
&gt; - Maximilian<br class="">
&gt;<br class="">
&gt;&gt; Am 05.02.2016 um 00:11 schrieb Chris Lattner &lt;<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>&gt;:<br class="">
&gt;&gt;<br class="">
&gt;&gt;<br class="">
&gt;&gt;&gt; On Feb 4, 2016, at 10:57 AM, Maximilian Hünenberger &lt;<a href="mailto:m.huenenberger@me.com" class="">m.huenenberger@me.com</a>&gt; wrote:<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt; Is there a reasoning behind treating (Int, Int) and (lhs: Int, rhs: Int) as separate types?<br class="">
&gt;&gt;<br class="">
&gt;&gt; I’m not sure what you mean by “separate types”.&nbsp; One has labels, one does not, so they are clearly separate.<br class="">
&gt;&gt;<br class="">
&gt;&gt; Further, "(Int, Int)” needs to be compatible/convertible to "(a : Int, b : Int)”, but “(a : Int, b : Int)” should not be convertible to “(x : Int, y : Int)”.<br class="">
&gt;&gt;<br class="">
&gt;&gt;&gt; Is there a connection to your tuple splat proposal?<br class="">
&gt;&gt;<br class="">
&gt;&gt; No connection at all.<br class="">
&gt;&gt;<br class="">
&gt;&gt; -Chris<br class="">
&gt;&gt;<br class="">
&gt;<br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></body></html>