New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New function type syntax #23
New function type syntax #23
Conversation
Great addition to Haxe syntax. Currently i have to write typedefs with docblocks for function signatures in public API. |
That's an interesting idea. I think it could be nicely implemented in the parser similar to conditional compilation ( |
That might be an option! |
If anyone wants to play with the syntax, I hacked up a proof-of-concept implementation in a branch here: https://github.com/nadako/haxe/tree/new_function_type_syntax (not PR quality, but I think it at least parses correctly). |
I really like it, and more than that, it was one of our need (in my company). So readable for a system that relies on method signature injection. Thanks for it. |
Can this also handle (or pave the way) for first class (in syntax) tuple support? which is also a way to return multiple arguments. |
let's not lose the focus here. tuples are different topic. i can see tho that if we'll have unnamed arguments, there's gonna be ambiguity with popular tuple type syntax, e.g. |
This is inconsistent if we want to support |
It's not about single-element tuples, but single-argument-type without parenthesis: E.g. if (in the new syntax) we allow |
This inconsistency is what I'm having issue with. And I think it's going to be a PITA for the parser as well (since we parse |
I think we should allow optional names right from the start. As the spec says, this cause a behavior change with this:
Which was parsed as Maybe we should require the parenthesizes around functional return types ( Of course that would also apply to several args types : |
I need those labelled argument badly because node js externs are quite ard to write without them :) Thanks ! |
@delahee Looks like labeled arguments are already merged: HaxeFoundation/haxe#6428 |
@RealyUniqueName That was reverted again: HaxeFoundation/haxe@84615ed |
Cruel world! |
@delahee These externs full of Dynamic don't sound good :) Anyway if it really has to be (that of course doesn't mean that we don't need named arguments, it's just how I deal with situations like yours). |
@ncannasse But I haven't worked on this proposal for quite a while, so I'll have to re-read and update it, will try to incrorporate your suggestion, thanks! |
So I looked into this again and I think it can work with unnamed arguments indeed. Here's what I came up with in my prototype implementation:
Supported new syntax:
For single argument,
I'll update the proposal and prepare an implementation PR with tests for further review. |
Alright, I updated the proposal to reflect latest discussions and prototyping. It now supports unnamed arguments without introducing inconsistency or ambiguity (I think). I'm going to work on polishing the implementation and prepare a PR for the Haxe repo. Meanwhile, I would like the core team to vote (or at least express their opinions) soon, otherwise I'll just merge everything and walk away :) |
Implementation PR ready HaxeFoundation/haxe#6645 |
Good for me |
Good for me too |
Do we also want to emit a warning for old syntax usage (maybe with a |
No warning, both syntaxes are accepted.
…On Wed, Oct 11, 2017 at 3:11 PM, Dan Korostelev ***@***.***> wrote:
Do we also want to emit a warning for old syntax usage (maybe with a -D
switch)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-bwDuMGsXNamvT0JXhtvC9HesZ5Ys0ks5srL6YgaJpZM4OOvbV>
.
|
What about type printing for error messages? Should it use old or new syntax? |
IMO we should steer towards the new syntax. The old currying syntax really doesn't make much sense. |
Agreed. |
For printing I'm ok to have the new syntax only. We need to keep the old
syntax available for backward compatibility. And no warning by default
since it would force users to have their code compatible with haxe4 only or
use #if / #else which is ugly. We can have a warning with -D if we want to,
but I'm not sure it's useful for now.
…On Wed, Oct 11, 2017 at 3:20 PM, Dan Korostelev ***@***.***> wrote:
Agreed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-bwFwF-BdI1ib9OCON1GezzQueTSabks5srMCYgaJpZM4OOvbV>
.
|
Maybe update "Rendered version" link so it points to an accepted version? |
Rendered version