support argument names in function type (closes #4799)

[nadako]

This PR adds support for specifying argument names in a function type with the following syntax:

arg1:Type1 -> arg2:Type2 -> Ret

This syntax is the most obvious choice as people are already familiar with it because Haxe prints function type with argument names like that.

The parsing part is super-easy and the change is tiny: we parse an identifier, then check if it's followed by a colon (:), then we parse a named argument, otherwise we continue parsing as a type path.

The AST representation takes the same approach as optional args: we add a CTNamed variant next to CTOptional and handle it similarly.

The typing part is the smallest change: when we loop through CTFunction arguments, we filter out CTNamed and extract name from it (again, similar to how we extract optional-ness CTOptional).

---

Here's why I believe adding this is a good idea, considering how non-invasive this change is:

Self-documenting code. Just compare these two:

typedef GetUserCallback = Int -> String -> Int -> Void;
// vs
typedef GetUserCallback = id:Int -> name:String -> age:Int -> Void;

Good signature hints for callbacks:

IDEs have the info to autogenerate a callback function/method with sensible argument names:

It's useful when we want to generate a function type from a macro. For example, latest node.js API have this util.promisify function that transform a callback-style function into a promise-returning one. With the information about argument names, we can provide a type-safe way of dealing with it:

(note how we transform stdout/stderr from argument names to promise object fields, and how we have the same command argument name for the generated function).

---

The only thing that's breaking about this change I think is the added ComplexType.TNamed constructor, which I think is fine, considering all the gained benefits and that we're aiming at Haxe 4 which already breaks macros in worse ways :)

[nadako]

If we merge this (I hope we will!), it might make sense to handle CTParent for function type args as well, so one could write var cb:(a:Int)->(b:String)->Void for better readability.

[Simn]

Shouldn't the parse_type_path2 go in this pattern?

[nadako]

Does it make a difference? I called it outside of the pattern because we need to unpack n to n,p, but we might as well just use (fst n), (snd n). I'm not sure what's better performance-wise.

[nadako]

Thanks!

Any opinion regarding handling CTParent for named/optional argument types?

Right now the following will fail at Typeload.load_complex_type:

var cb:(?Int)->Void; // this one was failing before as well
var cb:(arg:Int)->Void;
var cb:(?arg:Int)->Void;
var cb:?(arg:Int)->Void;

Do we want to allow (some of) them, or parenthesed types are only meant to distinguish function types in function type arguments?

Parens for named args (e.g. var cb:(id:Int)->(name:String)->Void) would be an option, but I don't have any strong opinion on this.

[Simn]

I don't know... (arg:Int) -> Void looks like you could also write (arg1:Int, arg2:Int) -> Void. But you can't...

[nadako]

Unfortunately we had to revert this because of a parser regression found #6433. We'll have to take another approach here with a different unambigous syntax.

[back2dos]

How about using the short lambda syntax for it (FWIW that's pretty much what TypeScript does)?

var add:(x:Int,y:Int)->Int = (x:Int,y:Int) -> x + y;

Alternatively use argument list + return type syntax:

var add:(x:Int,y:Int):Int = (x:Int,y:Int) -> x + y;

I have no idea how the Haxe parser works, but I think it should be as easy/hard to distinguish from TParent as distinguishing EObjectDecl from EBlock, i.e. on ( look ahead if there's an ident and a : next. If so, assume function type syntax and parse ,-separated ident : ComplexType tuples until hitting ) then expect -> or : for the alternative syntax and parse return type.

Personally I like the arrow form more, since it looks so close to the expression itself.

It also nests fine:

var stat:(name:String,callback:(error:Error, stat:Stat)->Void)->Void = js.Lib.require("fs").stat; 

As for representation (speaking in terms of the macro API to conceal my ignorance) I would just use FunctionArg (with null or empty name to support X->Y->Z syntax) for TFunction which also makes it more similar to haxe.macro.Type.TFun. This would make TOptional obsolete since optionality is encoded with the argument for functions and with @:optional for fields.

[nadako]

How about using the short lambda syntax for it

Yeah that's what we coming up with as well, I'm currently preparing an evolution PR because this is a larger change.

[nadako]

For anyone interested in this, there's an evolution proposal now: HaxeFoundation/haxe-evolution#23