Type signature for return values

[h2non]

I would prefer to tend to simplification and remove syntax noise as much as possible. Therefore, removing the "colon" character.

function Foo(x int32[]) string { return "int32" }

At parser level notation, the function expression would be: ES5:

FunctionExpression:
  function Identifieropt ( FormalParameterListopt? ) FunctionReturnType? { FunctionBody }

ES6 (function declaration with arrow expression):

FunctionDeclaration:
  ( FormalParameterListopt? ) FunctionReturnType? => { FunctionBody }

[sirisian]

I haven't ignored this. Been thinking about it on and off for months. The big idea behind the colon is the hard visual break that I don't believe whitespace gives. It's why I kept it for variables declarations.

The return type is possibly a different case. That said with the way function signatures are defined I don't believe whitespace is a strong visual break.

The grouping in this simple example for a function that returns a function (that returns an int32) is an example:

function Foo(x:int32) (string) int32 { return s => int32.parse(s) + x; }

Or as others might write it:

function Foo(x:int32)(string)int32 { return s => int32.parse(s) + x; }

The way it reads for me in both cases is like two groups of parenthesis. Compared to:

function Foo(x:int32):(string):int32 { return s => int32.parse(s) + x; }

A more complex example is a function that returns a function that returns a function:

function Foo(x:int32) (string) (int32) int32 { ... } function Foo(x:int32):(string):(int32):int32 { ... }

This is still very subjective.

From a consistency perspective the declaration syntax for a function signature ideally shouldn't have spaces. So this:

var foo:(uint8) uint8 = x => x;

Would be:

var foo:(uint8)uint8 = x => x;

That said whitespace isn't something that will ever be defined. Using a colon though removes this decision since everyone I spoke to with the current definition would use:

var foo:(uint8):uint8 = x => x;

A more complex example would be:

var foo:(x:int32)(string)(int32)int32;

With an untyped parameter:

var foo:(x)(string)(int32)int32;

Some might like the function signature to read as: "(any)(string)(int32)int32" though since it looks more minimal. Personally I think it looks confusing, but then again "(any):(string):(int32):int32" isn't that much different.

I'll probably continue to think about this and talk with others. I've put off replying to this for a long time, but I think having these examples might help.

[h2non]

Thanks for the comment. The majority of the statically typed languages uses whitespaces in favor or other separator tokens. I don't think all those language designers are wrong about this.

In terms of parsing level simplicity it makes no difference and does not increase complexibility in any sense.

Think about this as analog to semicolon as statement terminator token: it is only there so simplify things to the parser and the developer who is coding it, but at end user level it just syntax noise.

[Naddiseo]

I think your examples of a function returning a function returning a function etc. are a bit of a false problem which could be solved with type aliases, and at that level of nesting, it doesn't matter what delimiter you use, it's going to be difficult for humans to parse. It reminds me of trying to understand the sentence "women men girls love meet die".

Adding to the discussion, I think that whatever is used for type annotations in the rest of the grammar should be used in the return type; it's probably going to be difficult to read, no matter what delimiter/syntax is used. (Since co-authoring another type hinting spec, I'm a convert from colon to space.)

I don't believe whitespace is a strong visual break.

tongue-in-cheek: please keep your beliefs out of the programming language(s) I use! Use data instead!