<html><body><div><div class="_stretch"><span class="body-text-content">• What is your evaluation of the proposal?</span></div><div><div><span><br data-mce-bogus="1"></span></div><div><span>I am against it. For me requiring parentheses around single arguments is just visual clutter.</span></div><div><span><br data-mce-bogus="1"></span></div><div><span>An alternative for eliminating the ambiguities would be to require parentheses around<br data-mce-bogus="1"></span></div><div><span>- single tuple arguments<br data-mce-bogus="1"></span></div><div><span>- multiple arguments<br data-mce-bogus="1"></span></div><div><span><br data-mce-bogus="1"></span></div><div><span>Int -> Int // single non-tuple argument, no parentheses required<br data-mce-bogus="1"></span></div><div><span>(Int, Int) -> Int // multiple arguments, parentheses required<br data-mce-bogus="1"></span></div><div><span>((Int, Int)) -> Int // single tuple argument, parentheses required<br data-mce-bogus="1"></span></div><div><span><br data-mce-bogus="1"></span></div><div><span>=> No ambiguities anymore.<br data-mce-bogus="1"></span></div><div><span><br data-mce-bogus="1"></span></div><div><span></span><span class="body-text-content"></span><br><span class="body-text-content"></span><div class="_stretch"><span class="body-text-content"> • Is the problem being addressed significant enough to warrant a change to Swift?</span></div></div><div><span><br data-mce-bogus="1"></span></div><div><span>The ambiguity should be solved, but I'd prefer an alternative solution (see above).</span></div><div><span class="body-text-content"><br data-mce-bogus="1"></span></div><div><span class="body-text-content"></span><br><span class="body-text-content"></span><div class="_stretch"><span class="body-text-content"> • Does this proposal fit well with the feel and direction of Swift?</span></div><div class="_stretch"><span class="body-text-content"><br data-mce-bogus="1"></span></div><div class="_stretch"><span class="body-text-content">No, it introduces visual clutter which is IMHO unnecessary. Additionally it creates a slippery slope as there have already been voices to require parentheses around argument lists of closure expressions, just for consistency reasons, although there is not even an ambiguity problem (if parentheses would be prohibited there except for tuples).<br data-mce-bogus="1"></span></div><div class="_stretch"><span class="body-text-content"><br data-mce-bogus="1"></span></div></div><div><span></span><span class="body-text-content"></span><br><span class="body-text-content"></span><span class="body-text-content"> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span></div><div><br data-mce-bogus="1"></div><div>Haskell does not need parentheses at all as all functions there are conceptually one argument functions, so it is not a fair comparison.<br></div><div><br data-mce-bogus="1"></div><div><span class="body-text-content"></span><br><span class="body-text-content"></span><div class="msg-quote"><div class="_stretch"><span class="body-text-content"> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></span></div><div class="_stretch"><span class="body-text-content"><br data-mce-bogus="1"></span></div><div class="_stretch"><span class="body-text-content">I read the proposal, and followed the discussion.</span></div><div class="_stretch"><span class="body-text-content"><br data-mce-bogus="1"></span></div><div class="_stretch"><span class="body-text-content">-Thorsten<br><br></span></div></div></div></div></div></body></html>