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.
Here's a practical introduction that is possibly worth more than a thousand
words (or perhaps even swift-evo posts):
Write a (generic) function composition operator in Swift 4
(working as expected for all function types).
Write a generic type WrappedFunction that can wrap any function in
(with type parameters for Input and Output).
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).
I've been reporting a lot of parentheses-related bugs since the first Swift
beta, and I'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.
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.
So I wonder if any of you have had any thoughts about what Swift's
parentheses-related future (or evolutionary baggage) will be?
My perhaps unpopular thoughts:
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.
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 ...
Swift, please break my code all you want before it's too late, as long as
it results in increased (rather than decreased) consistency, simplicity,
expressiveness, optimizability and safety. Otherwise I could have used