[swift-evolution] SE-0066 Reaction
Mishal Awadah
a.mamish at gmail.com
Tue Apr 26 12:52:44 CDT 2016
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>
More information about the swift-evolution
mailing list