-
-
Notifications
You must be signed in to change notification settings - Fork 661
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
Support custom implicit Function Arguments like PosInfos via abstract @:fromNothing macro #6616
Conversation
…ype (unify monos)
…efault value and fromNothing args)
let infos = mk_infos ctx p [] in | ||
ordered_args @ [type_expr ctx infos (WithType t)] | ||
else if ctx.com.config.pf_pad_nulls then | ||
(ordered_args @ [(mk (TConst TNull) t_dynamic p)]) | ||
else | ||
ordered_args | ||
ordered_args @ [(mk (TConst TNull) t_dynamic p)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ncannasse does this change, actually ignoring pf_pad_null for bind, does have any effects on real code? The unit tests still pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well it's not ignoring pf_pad_null but is always pushing nulls whereas you're padding or not. I'm not sure I like it, but I guess we can remove extra nulls at a later stage maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, true. I actually wonder if and what implications this actually have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or to be more precise, which negative implications this have.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and just to let you know, there are already cases where this leads to bugs: http://try-haxe.mrcdk.com/#12d04.
You will have to rebase this one. |
It's up to date again |
@ncannasse @Simn @nadako any objections or remarks? |
I'm yet to check this out and see what can I do with it :) |
I think fromNothing is badly named. I suggest using |
I agree that it's badly named. But |
Yes, it does atm, but its not very useful in my opinion because you don't know the expected type. |
What about fields of object literals? Seems like a relatively good use case (will give you prop drilling for example). Would there be anything wrong with also using this for initializing variables? |
@back2dos would love to see an example, because i fail to see how that could be done without having an abstract with a concrete underlying type. |
Let's revisit this for 4.1 |
This branch would need an update. @RealyUniqueName Could you look into this? |
Sure |
This PR is unfortunately unmergeable at this point. I'll link it to #4583 mostly because there are some good tests here, so if we add this feature for Haxe 5 we can add those in some way. |
No description provided.