[swift-evolution] History and future of Swift's parentheses

[Robert Bennett]

At first I thought that task 1 looked innocuous enough; then I discovered this bizarre behavior. Not sure if this was the point of your email. 

func compose<T, U, V>(_ g: @escaping (U)->V, _ f: @escaping (T)->U) -> (T)->V {
return { x in g(f(x)) }
}

func strung(_ tuple: (Int, Int)) -> (String, String) {
return ("\(tuple.0)", "\(tuple.1)")
}

func concat(_ tuple: (String, String)) -> String {
return tuple.0 + tuple.1
}

print(String(reflecting: compose(concat, strung)(3, 4))) // "34"; but shouldn't we need a tuple?
print(String(reflecting: compose(concat, strung)((3, 4)))) // "34"; this makes sense

let f = compose(concat, strung)
print(String(reflecting: f(3, 4))) // ERROR: extra argument in call; but if the first line works, shouldn't this too?
print(String(reflecting: f((3, 4)))) // "34"; also makes sense

On Jun 07, 2017, at 03:03 PM, Jens Persson via swift-evolution <swift-evolution at swift.org> wrote:

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):

  Exercise 1
    Write a (generic) function composition operator in Swift 4
    (working as expected for all function types).

  Exercise 2
    Write a generic type WrappedFunction that can wrap any function in Swift 4
    (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?


PS

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 Objective C++. 

/Jens

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170609/0f63ea3a/attachment.html>