<div dir="ltr"><div>I&#39;ll try to rephrase my initial post a bit, perhaps it will make my point clearer:</div><div><br></div><div>Might it be that some of the confusion regarding the evolution (design/redesign) of tuples, parameter lists, etc. stems from the fact that they all use parentheses? Or put differently: Parentheses, being used for so many different (and similar) things, is perhaps blurring the &quot;real&quot; (possibly simpler) similarities and differences.</div><div><br></div><div>I&#39;m not saying they should not all use parentheses in the final design, I&#39;m only saying that perhaps it is making it harder to think clearly about these things (while designing  the language).</div><div><br></div><div>Let&#39;s say we carry out a thought-experiment in which we assume that<span style="font-size:13px"> argument and parameter lists use eg ≪≫ and tuples use eg ⊂⊃, and normal parentheses are _only_ used for grouping and controlling priority in eg mathematical expressions, but not when creating tuples, parameter lists, pattern matching and closure types.</span></div><div><br></div><div>Using this notation (which is just a thinking-tool, not meant as a final syntax), and reimagining these things from scratch, we could for example try and see what happens if we assume that these are three _different_ types:</div><div><span style="font-size:13px">Int</span></div><div><span style="font-size:13px">⊂Int </span><span style="font-size:13px">⊃</span></div><div><span style="font-size:13px">⊂</span><span style="font-size:13px">⊂ </span><span style="font-size:13px">Int </span><span style="font-size:13px">⊃</span><span style="font-size:13px">⊃</span></div><div><span style="font-size:13px">and also, for example, that it is ok to have single element tuples with an element label.</span></div><div>And:</div><div><br></div><div>((-1) * ((x + y) + (3 * y))) // Still OK. Redundant parens are treated as usual / as before.</div><div><br></div><div><span style="font-size:13px">⊂ String, Int ⊃ // Two element tuple type whose elements are a String and an Int.</span><br></div><div><br></div><div><span style="font-size:13px">⊂ Int </span><span style="font-size:13px">⊃ // Single element Tuple type.</span><br></div><div><br></div><div><span style="font-size:13px">⊂</span><span style="font-size:13px">⊂</span><span style="font-size:13px"> Int </span><span style="font-size:13px">⊃</span><span style="font-size:13px">⊃</span><span style="font-size:13px"> // Single element Tuple type whose only element is another single element tuple type whose only element is an Int.</span></div><div><br></div><div><span style="font-size:13px">≪ Int ≫ -&gt; Int // Function type from Int to Int.</span><br></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Perhaps the </span><span style="font-size:13px">≪</span><span style="font-size:13px">≫ would prove to be unnecessary, so:</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Int -&gt; Int // Function type from Int to Int.</span></div><div><div><div><span style="font-size:13px">(Int -&gt; Int)? // Optional function type from Int to Int.</span></div></div></div><div><div><span style="font-size:13px">((((Int -&gt; Int))))? // Optional function type from Int to Int. (remember parens are _only_ used for grouping this way)</span></div></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">⊂ Int, Int, Int </span><span style="font-size:13px">⊃ -&gt; Int // Function type from a 3-Int-tuple to an Int.</span><br></div><div><div><span style="font-size:13px">⊂</span><span style="font-size:13px">⊂</span><span style="font-size:13px"> Int, Int, Int </span><span style="font-size:13px">⊃</span><span style="font-size:13px">⊃</span><span style="font-size:13px"> -&gt; Int // Function type from a single element tuple whose element is a 3-Int-tuple to an Int. (Yes, nobody would probably write a function of such a type, but allowing it could perhaps make the rules a lot simpler.)</span></div></div><div><span style="font-size:13px"><br></span></div><div>... Well, I think you get the idea.</div><div><br></div><div>I&#39;m wondering if there has been any attempts at such from-the-scratch redesigns of all these parentheses-related-things in the language (including eg pattern matching, associated values and more).</div><div><br></div><div>/Jens</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 6, 2016 at 8:10 PM, Vladimir.S via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06.07.2016 20:51, Joe Groff wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Jul 6, 2016, at 7:47 AM, Vladimir.S via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
On 06.07.2016 3:57, Jens Persson via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please feel free to ignore this naive attempt to engage in this discussion.<br>
<br>
My understanding of the history of Swift&#39;s tuples, argument lists, pattern<br>
matching, associated values, etc. in two steps:<br>
<br>
1. Initial Idealism *:<br>
Simple powerful heavily reused general concept.<br>
<br>
2. Iterative pragmatism / reality *:<br>
Complicated (exceptions to) rules.<br>
<br>
(* Inevitably not taking everything in to account.)<br>
<br>
Has there been any recent attempts to outline a more or less complete<br>
redesign for these things, returning to step 1 so to speak, but taking into<br>
account what has now been learned?<br>
<br>
<br>
As a side note (and supposedly trivial to most but me):<br>
<br>
Parentheses (parenthesized expressions in the grammar?) are used for all of<br>
these parts of the language, and they probably should be, but perhaps the<br>
similarities and differences between the language constructs can be made<br>
clearer to see by pretending that argument and parameter lists are written<br>
with eg ≪≫ and tuples with eg ⊂⊃, etc.?<br>
<br>
For example, I think most people agree that we should be able to use<br>
&quot;sloppy/forgiving&quot; parenthetical grouping in code such as:<br>
((1 + (2 * 3)) * (x + (-5))) - y<br>
This is fine and can be used to express meaning for the person<br>
reading/writing, even though it means that some of the parens can become<br>
superfluous to a machine interpretation.<br>
<br>
AFAICS this need not have anything to do with tuples and/or parameter<br>
lists, but the fact that Swift is treating eg:<br>
func foo(x: ((((Int))))) { print(x) }<br>
as<br>
func foo(x: Int) { print(x) }<br>
and<br>
((Int, Int))<br>
as<br>
(Int, Int)<br>
</blockquote>
<br>
If SE-0110 will be accepted, ((Int, Int)) will mean &quot;1 tuple with Int,Int fields&quot; and (Int, Int) will mean only &quot;list of two Ints in parameters&quot;<br>
</blockquote>
<br>
((Int, Int)) would still be equivalent to (Int, Int). SE-0110 only concerns parameter lists in function types.<br>
</blockquote>
<br></div></div>
Yes, I&#39;m talking about parameter list in function. Perhaps I&#39;m missing something... Quotation from proposal:<br>
<br>
&gt;----------------&lt;<br>
To declare a function type with one tuple parameter containing n elements (where n &gt; 1), the function type&#39;s argument list must be enclosed by double parentheses:<br>
<br>
let a : ((Int, Int, Int)) -&gt; Int = { x in return x.0 + x.1 + x.2 }<br>
&gt;----------------&lt;<br>
<br>
Oh... Or do you(and Jens) mean that this:<br>
let x : (Int, Int) = (1,2)<br>
will be the same as this:<br>
let x : ((Int, Int)) = (1,2)<br>
? and about<br>
func foo(_ x: ((Int, Int))) { print(x) }<br>
vs<br>
func foo(_ x: (Int, Int)) { print(x) }<br>
?<br>
In this case yes, sorry for misunderstanding, SE-0110 will not change this. I don&#39;t see any ambiguity here: foo will be called as<br>
foo((1,2)) - clearly that tuple is sent as argument.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Joe<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
seems to suggest that it somehow does.<br>
<br>
Or maybe I have just forgotten the reasons for why there can be no such<br>
thing as (a nested) single element tuple (type).<br>
<br>
I also can&#39;t remember what the pros &amp; cons of disallowing labeled single<br>
element tuples were.<br>
<br>
Happy to be corrected and pointed to relevant reading : )<br>
<br>
/Jens<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
</blockquote>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote>
<br>
<br>
</blockquote>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>