<div dir="ltr"><div>Swift uses parentheses for a lot of different things (tuples, parameters, calls, grouping, pattern matching, etc), this has led to some confusion, for both language designers and users.<br></div><div><br></div><div>Here&#39;s a practical introduction that is possibly worth more than a thousand words (or perhaps even swift-evo posts):</div><div><br></div><div>  Exercise 1</div><div>    Write a (generic) function composition operator in Swift 4</div><div>    (working as expected for all function types).</div><div><br></div><div>  Exercise 2</div><div>    Write a generic type WrappedFunction that can wrap any function in Swift 4</div><div>    (with type parameters for Input and Output).</div><div><br></div><div>When you have completed (or given up) the exercises, please note that once in the history of Swift, these were simple tasks. You could come up with working solutions very quickly without any boilerplate or special casing (although perhaps not entirely without some of the parentheses-related inconsistencies of that time).</div><div><br></div><div>I&#39;ve been reporting a lot of parentheses-related bugs since the first Swift beta, and I&#39;m only getting more and more worried that the current incremental approach to fixing these is not working very well, resulting in a language that is more complex and less expressive than it could be.</div><div><br></div><div>Discussions often seem to end up being a bit too focused on particular use cases and details, and less on how everything fit together as a system.</div><div><br></div><div><br></div><div><div>So I wonder if any of you have had any thoughts about what Swift&#39;s parentheses-related future (or evolutionary baggage) will be?</div></div><div><br></div><div><br></div><div>PS</div><div><br></div><div><div>My perhaps unpopular thoughts:</div></div><div><br></div><div>I wish the parentheses-related parts of Swift could be carefully evaluated and redesigned from scratch, as a whole, in order to arrive at a solution that is as simple and expressive as possible.</div><div><br></div><div>But perhaps this has already happened and we are now just taking some steps back that are necessary for reimplementing some of the good stuff (that has been - at least IMHO - sort of hinted in earlier versions of Swift). But it feels like there is not enough time ...</div><div><br></div><div>Swift, please break my code all you want before it&#39;s too late, as long as it results in increased (rather than decreased) consistency, simplicity, expressiveness, optimizability and safety. Otherwise I could have used Objective C++. <br></div><div><br></div><div>/Jens</div><div><br></div></div>