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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
