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

[Dave Abrahams]

on Fri Apr 15 2016, Brent Royal-Gordon <swift-evolution at swift.org> wrote:

>> 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?
>
> While it's technically correct, I agree with John's assessment that
> this is "fussy". `T -> U` doesn't confuse people 

Do we have any data on this (in either direction)?

Personally, it has always seemed obvious that T -> U being a function
type would be quite novel to some people, considering the number of
times I've seen in Haskell texts that (surprise!) you don't need
parentheses to invoke functions.  I guess those are invocations and
we're talking about declarations here, but declaration-follows-use is a
kind of principle the language tries to uphold.

But that's just intuition.  Data would be very interesting.

> and doesn't confuse the compiler; removing it would require extra
> punctuation for no particular reason. It would also become
> inconsistent with the paren-less `{ param in … }` syntax, which I
> think is very important for keeping usage sites simple and clean.
>
> What I think we *should* eliminate, however, is using `Void` to mean
> "no arguments" in a closure type. `Void -> Int` should mean that the
> type takes one argument which happens to be an empty tuple. If you
> want no arguments, write `() -> Int`. Similarly, a typedef for a
> 2-tuple (like `Dictionary.Element`) should be recognized as one tuple
> parameter, not two singleton parameters. With that in place, `T -> U`
> becomes merely a convenient shorthand for the canonical form, `(T) ->
> U`.
>
> I mean, it's not that big a deal; if you remove it, everyone will type
> extra parentheses and live with it. But recognize that doing so would
> improve the language, not the end-user experience.

-- 
Dave