How would this proposal affect curried functions? Would this: func foo(int: Int) -> Int -> String -> String
become this? func foo(int: Int) -> (((Int) -> String) -> String) As I understand, that transformation is an accurate representation of the actual return type of “foo”, but it’s certainly going to raise some complaints among the functional Swift community if required. -BJ > We currently accept function type syntax without parentheses, like: > > Int ->Float > String ->() > > etc. The original rationale aligned with the fact that we wanted to treat all > functions as taking a single parameter (which was often of tuple type) and > producing a tuple value (which was sometimes a tuple, in the case of void and > multiple return values). However, we’ve long since moved on from that early > design point: there are a number of things that you can only do in a > parameter list now (varargs, default args, etc), implicit tuple splat has > been removed, and the compiler has long ago stopped modeling function > parameters this way. Beyond that, it eliminates one potential style war. > > Given all this, I think it makes sense to go for syntactic uniformity between > parameter list and function types, and just require parenthesis on the > argument list. The types above can be trivially written as: > > (Int) ->Float > (String) ->() > > Thoughts? > > -Chris > > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
