<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>Exactly, everything else is simply an excuse and nothing more. Tuple destructuring is not even aligned to enum case patterns at all, because it only uses the shorthand version and does not allow us to write the full explicit version.</p>
<pre><code class="swift">enum Foo { case a(b: Int, c: Int) }
switch Foo.a(b: 42, c: 0) {
case let .a(b: num1, c: num2): …
// Or the explicit longer version:
case .a(b: let num1, c: let: num2): …
}
</code></pre>
<p>Tuple destructuring do not support the latter, which in our previous example would really be unambiguous.</p>
<pre><code class="swift">let tuple: (x: Int, y: Int) = (3, 1)
// Short version:
let (x: Int, y: Double): (x: Int, y: Int) = tuple
// Not supported explicit version:
(x: let Int, y: let Double) = tuple
</code></pre>
<p>Why is that the case? Because tuple destructuring creates another tuple on the left side of the same tuple type as the tuple on the right side of the assignment operator.</p>
<p>Erica Sudan has a proposal, which could change that for guards and ifs (second design): <a href="https://github.com/erica/swift-evolution/blob/783fdf8d3723d51f350b917af23c207cebdd1ad7/proposals/9999-ifcaseguardcase.md">https://github.com/erica/swift-evolution/blob/783fdf8d3723d51f350b917af23c207cebdd1ad7/proposals/9999-ifcaseguardcase.md</a></p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1494224089726146048" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 8. Mai 2017 um 07:16:50, David Hart via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div dir="auto"><div></div><div>
<title></title>
<div><br></div>
<div>On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>To which human would it be misleading?<br>
<br>
To the writer? No, because the compiler will warn you right away.
By the time you're done with writing the first line, it'll warn you
that Int and Double are unused variables. And if you try to use x
and y, you get an error.<br>
<br>
To the reader? Only if the writer knowingly wrote this misleading
code. In other words, it's a nice puzzle, but no reader will
encounter this in real-world code, unless they're being tormented
by the writer on purpose.<br></div>
</blockquote>
<div><br></div>
<div>IMHO, the fact that the compiler warns you does no change the
fact that it's a very confusing part of the language. It should not
be an excuse for fixing it. Consistency teaches us to expect a type
after a colon.</div>
<br>
<blockquote type="cite">
<div>
<div class="gmail_quote">
<div dir="ltr">On Sat, May 6, 2017 at 16:28 Brent Royal-Gordon
<<a href="mailto:brent@architechies.com">brent@architechies.com</a>>
wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> On May 5, 2017, at 11:06 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> The identifier after a colon is *never* a type in any pattern
matching, and there's no need of which I'm aware to support type
annotations in pattern matching. We put colons after labels, and
the current syntax is perfectly consistent here. What is the defect
you're trying to cure?<br>
<br>
The defect underlying this proposal: `let (x: Int, y: Double)`
looks like it's declaring `x` and `y` of types `Int` and `Double`,
but it's actually declaring `Int` and `Double` and binding them to
`x` and `y`. Your code's meaning is perfectly unambiguous to the
compiler, of course, but it's misleading to the human.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br></blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div>
<span>_______________________________________________</span><br>
<span>swift-evolution mailing list</span><br>
<span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br>
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br>
</div>
</blockquote>
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>