-
-
Notifications
You must be signed in to change notification settings - Fork 658
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
Rest arguments #9274
Rest arguments #9274
Conversation
@jdonaldson Could you please add a lua implementation? |
import haxe.iterators.RestIterator; | ||
|
||
@:coreType | ||
abstract Rest<T> { |
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.
to Iterable<T>
for static extension support might be nice?
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.
No, because it's not compatible with Iterable
.
The only thing we can to is adding @:to Iterable
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.
Hm... but it has iterator()
?
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.
But it only exists at compile time, while Iterable
needs iterator
to exist at run time.
Looks like a good start... I got things working for Lua in your test cases. I think we'll need to add some more restrictions for Rest.... here's some things that are possible, but add a lot of complications to support:
These should probably be restricted, with a helpful compiler message:
I'm not handling any of these cases yet |
These are handled by the compiler |
There's not a very clear/explicit error message for these cases... function rest(r:Rest<Int>, o :Int){
return o;
}
[...]
var r = rest(3, 2, 1, 0); or function rest(r:Rest<Int>, o : Rest<Int>){
trace(r + " is the value for r");
return o;
} Gives:
|
Looks like it's only checked for fields. Will add for local functions too. |
import lua.TableTools.maxn; | ||
import lua.TableTools.pack; | ||
import lua.Table; | ||
|
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.
Spaces -> Tabs again, to be consistent with the stdlib.
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 just run haxe-formatter over it, there's other formatting issues too. :D
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.
FWIW I added haxe-formatter to this vim plugin : vim-autoformat/vim-autoformat#297
I have it set to autorun when I open a haxe file now.
Should we support returning a Rest argument? I added a breaking test for it. |
So... does this support calling rest-argument functions by passing |
Not yet. I have to figure out inlining for this case first. Or disable inlining functions with rest args completely. |
This PR will need an update. Also, we have to stop randomly stopping to work on things like these. |
This was not planned and I've started this because I thought it wouldn't take a lot of effort, but it turned out I was wrong, so I moved back to planned tasks. Main issue is an absence of syntax for passing a collection as rest arguments (e.g. |
Curious why Neko isn't supported so far. It supports variadic functions and dynamic function application, no? |
Closed in favor of #9961 |
Closed in favor of #9961
Implements rest arguments as an abstract over targets native corresponding features.
Closes #7306
Softly deprecates
haxe.extern.Rest
(no warning for now).