[swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

[Vladimir.S]

On 22.04.2016 20:17, Антон Жилин wrote:
> Vladimir, I agree with Chris Lattner that function parameters are different
> from function return value in Swift.
>
> Firstly, syntax of function call allows for easy forwarding of values,
> which came from different places, as parameters to a single function:
> f(g(foo, 1), h(bar(buz)))
>
> On the other hand, to play with multiple return values as freely, you need
> to perform pattern matching, which finishes current expression.
>
> Secondly, there is no special sugar for tuples in return values, and
> function grammar does not need to know about it.
>
> Thirdly, there are no special attributes for elements of tuple in function
> return type (second implies this).
>

I see your points regarding the function parameters. And I'm ready to 
totally agree with you.

> Now, to  typealias f4 = () -> ((((((()))))))
> I think it's OK, but we can remove Void and reduce the number of possible
> combinations.

Yes, my question was actually about the result type syntax like (Void) (()) 
(((()))) etc, if you feel this is OK to have this in Swift.
I think the possibility to have (((()))) is weird, not useful, never can be 
used and just shouldn't exist in the language. Why not prevent this just by 
.. compiler/syntax checker/parser..
Probably I'm missing somehting.. ?

About the "Void".. I'm +1 on this idea, but asking myself if we can freely 
remove 'Void' from our language at all without any problem? Can't find the 
answer. It seems like we can, IMO using the syntax like () -> () is OK, 
clear and explicit, especially in "functional" word.

>
> The fact that () and (()) are equal types is a general limitation of Swift
> type system: there are no single-element tuples.
> But it is so for a reason: parentheses in expressions cannot be overloaded
> to construct single-element tuples.


>
> - Anton
>
> 2016-04-22 11:12 GMT+03:00 Антон Жилин <antonyzhilin at gmail.com
> <mailto:antonyzhilin at gmail.com>>:
>
>     +1, but this proposal need further work.
>     Specification of the new function grammar is needed.
>
>     Currently, it looks like:
>
>     function-type → type
>     <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/swift/grammar/type>­|throws­|_opt
>     ­|->­|type
>     <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/swift/grammar/type>
>
>     It is already false, because some attributes can only be used in
>     function types.
>
>     I suggest to rewrite it to something like:
>
>     /function-type/ → |(| /function-parameter-types/_opt  |)| |->| /type/
>
>     /function-type/ → |(| /function-parameter-types/_opt
>      |)| |throws| |->| /type/
>
>     /function-type/ → |(| /function-parameter-types/_opt
>      |)| |rethrows| |->| /type/
>
>     /function-parameter-types/ → /function-parameter-type/
>
>     /function-parameter-types/ → /function-parameter-type/ |,| /function-parameter-types/
>
>     /function-parameter-type/ → /function-parameter-attributes/ /type/
>
>     It will also eliminate situation when you can pass () argument to a ()
>     → T function.
>     Function types Void->T will need to be migrated.
>
>     - Anton
>
>