<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 8, 2017 at 3:01 PM, Vladimir.S <span dir="ltr"><<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 08.06.2017 12:17, Víctor Pimentel Rodríguez via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
On Thu, Jun 8, 2017 at 5:15 AM, Susan Cheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
<br>
Just a thought<br>
<br>
if parentheses is important, why the tuples are not?<br>
<br>
<br>
This is stated on the proposal (and not in previous proposals):<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md" rel="noreferrer" target="_blank">https://github.com/apple/swift<wbr>-evolution/blob/master/proposa<wbr>ls/0110-distingish-single-<wbr>tuple-arg.md</a><br>
<br></span>
*<span class="gmail-"><br>
<br>
We understand that this may be a departure from the current convention that a set<br>
of parentheses enclosing a single object are considered semantically meaningless,<br>
but it is the most natural way to differentiate between the two situations<br>
described above and would be a clearly-delineated one-time-only exception.<br>
<br>
<br></span>
<<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md#impact-on-existing-code" rel="noreferrer" target="_blank">https://github.com/apple/swif<wbr>t-evolution/blob/master/propos<wbr>als/0110-distingish-single-<wbr>tuple-arg.md#impact-on-existin<wbr>g-code</a>><span class="gmail-"><br>
<br>
This proposal marks a one-time-only exception, to differentiate the parenthesis needed to enclose a list of closure parameters and the parenthesis needed for tuples. That's adding an exception for implementing a regression.<br>
<br>
The more I think about it, the more I hate* this proposal.<br>
<br>
* Well, not _hate_, let's say slightly dislike :P<br>
</span></blockquote>
<br>
Please look here:<br>
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md" rel="noreferrer" target="_blank">https://github.com/apple/swift<wbr>-evolution/blob/master/proposa<wbr>ls/0066-standardize-function-<wbr>type-syntax.md</a><br>
<br>
into "Proposed solution" section:<br>
<br>
Parentheses will be required in function types. Examples:<br>
<br>
Int -> Int // error<br>
(Int) -> Int // function from Int to Int<br>
((Int)) -> Int // also function from Int to Int<br>
<br>
Int, Int -> Int // error<br>
(Int, Int) -> Int // function from Int and Int to Int<br>
((Int, Int)) -> Int // function from tuple (Int, Int) to Int<br>
<br>
let f: () -> Int // function with no parameters<br>
let g: (()) -> Int // function taking a single () parameter<br>
let h: ((())) -> Int // function taking a single () parameter<br>
<br>
f(); g(()); h(()) // correct<br>
f(()); g(); h() // errors<br>
<br>
Do you also hate* SE-0066?
</blockquote></div><br>I'm certainly not a fan, although I must say that it's funny to me to think of the usefulness of a closure that only accepts a single parameter of type "()", and how important it's to be able to model it. It was beautiful to me how tuples and closure arguments were interchangeable, and I hope that some day that feature will be back.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm also not a fan of SE-0029, the original proposal that removed tuple splat and linked from SE-0110. I'm fine if it was better for the compiler to remove that hacky implementation, but that proposal certainly has some disdain for implicit tuple splat:</div><div class="gmail_extra"><br></div><div class="gmail_extra">> This doesn’t seem like a positive contribution - this seems like a "clever" feature, not a practical one.<br clear="all"><div><br></div><div>And going back to SE-0110, I dislike this part too:</div><div><br></div><div>> The current behavior violates the principle of least surprise</div><div><br></div><div>People seems to get more surprised when you migrate some perfectly reasonable code and have to use an intermediate tuple to achieve the same effect as the code example in SE-0110 shows.</div><div><br></div><div>After rereading the proposals the motivation sections read more like "we don't like this feature and it's useless" more than "we don't like this implementation and it's dragging us". Looking at the final implementation of this proposal (the third one!), I don't think the resulting code is easier to maintain, actually the Swift 4 mode seems more complex:</div><div><br></div><div><a href="https://github.com/apple/swift/pull/6133/files">https://github.com/apple/swift/pull/6133/files</a><br></div><div><br></div><div>I'm sorry, but I like this feature. Apart from Dictionary and similar, I'm really going to miss being able to model every type of closure with the type (T) -> U.</div><div><br></div>-- </div><div class="gmail_extra">Víctor Pimentel<div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" style="font-size:12.8px"><div style="font-size:12.8px"></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div>