add new function type syntax (closes #4799)

[nadako]

This implements HaxeFoundation/haxe-evolution#23

[nadako]

[Simn]

The grammar part looks good to me.

I don't know about CTNamed though. Shouldn't this be integrated into CTFunction instead? IIRC you wanted to do that for CTOptional as well at some point.

[nadako]

Yes that's an unresolved question in the proposal, but since noone commented on that, I went with the least intrusive change. Do we want to rework CTFunction instead?

[Simn]

We could maybe keep CTOptional because at least it parses on its own and can be used in macros. With CTNamed, it doesn't even parse on its own, so it doesn't make much sense to have a representation for it.

[nadako]

So, CTFunction of (placed_name * bool * type_hint) list * type_hint?

[Simn]

That looks correct.

[nadako]

See #6667

[Simn]

We can close this one, right?

[nadako]

If we're sure we go with the CTFunction change :)

[ncannasse]

Hmm, I would leave `TFunction( args : Array<ComplexType>, ret : ComplexType )` as-it, and add `TNamedFunction( args : Array<{ name : String, t : ComplexType, opt : Bool }>, ret : ComplexType );` (or some other constructor name) for the sake of macro compatibility

…

On Wed, Oct 11, 2017 at 10:36 AM, Dan Korostelev ***@***.***> wrote: If we're sure we go with the CTFunction change :) — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#6645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwGkue8qqy7PhwnUzf6U-CUBZN9Pdks5srH4CgaJpZM4Pv0PE> .

[Simn]

That would be annoying because you would have to handle both constructors whenever you want to handle a function. It would also still be breaking because it's an additional constructor and causes exhaustiveness errors. Unless you use default cases, in which case you would just silently miss it and your code would break.

[ncannasse]

We can always pass TNamedFunction from compiler to macro, but accept both from macro.
But maybe that's not that important given we have reification on complex types, so most of them will be transparent.

[Simn]

That sounds awkward... in that case, the CTNamed approach strikes me as better.

[ncannasse]

Maybe yes.

…

On Wed, Oct 11, 2017 at 6:01 PM, Simon Krajewski ***@***.***> wrote: That sounds awkward... in that case, the CTNamed approach strikes me as better. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#6645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwBBjH-oAV4hOL62X_KG312ABh_dhks5srOZLgaJpZM4Pv0PE> .