Hi, I missed the original thread, but here are my thoughts on SE-0066 right after Chris's email ends with "thoughts?".
Concern 1: I feel like we're forgetting about the functional programming syntax of declaring function types like this: A -> B -> C for a function foo(a: A, b: B) -> C This eliminates the ambiguity of what the parameter types are, and is more legible (less paren hell) than adding parens like this: (A,B) -> C which for a function foo(a: (A, B)) -> C would look like this after the implementation of SE-0066: ((A,B)) -> C instead of (A,B) -> C Concern 2: There's also the potential to transform a function like this A -> B -> C into this B -> C after partial application, something which might not be totally irrelevant to Swift in its future. Here are a few contrived examples of function types showing the paren version (order 66), the parens on the return type too, and the generic functional programming version (right). I want to preface this with, "Remember that Swift is an enjoyable experience because reading Swift is pleasant." | 66 | 66 return type | generic functional style | |--------------------+----------------------+--------------------------| | (A) -> B | (A) -> (B) | A -> B | | (A, B) -> C | (A, B) -> (C) | A -> B -> C | | ((A, B)) -> C | ((A, B)) -> (C) | (A, B) -> C | | ([A]) -> B | ([A]) -> (B) | [A] -> B | | ([A], (B, C)) -> D | ([A], (B, C)) -> (D) | [A] -> (B, C) -> D | | ([A], [B]) -> [C] | ([A], [B]) -> ([C]) | [A] -> [B] -> [C] | | (([A], [B])) -> C | (([A], [B])) -> (C) | ([A], [B]) -> C | - Mish
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution