[swift-evolution] SE-0066 Reaction

[Mishal Awadah]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160426/124afe0b/attachment.html>