Suggestion: keyword args (like python, lua, OC, and more)

1

Just a little thought about function calling.

Since we have structure typing as the an important part of the type system, could we treat “the arguments to a function” an anonymous structure, so that it can be called like Python f(x=1, y=2), Lua f{x=1, y=2}(though you need to access by t.x), and Objective-C [o f:1st, x:2nd, y:3rd], but checked, resolved, and having optional fields filled at compile-time? (yes I’ve read the manual saying defaults are not substituted for now. I hope there will be.)

This helps writing more readable, self commentary code (especially when many args of the function are some kind of options), but not forced to do so like in OC.

Though it’s not so hard to imitate this now, by:
function(args: {doThis: bool, doThat: bool})
But it doesn’t seem to support default value for fields (or can someone tell me how to do this?).
Also you need to access them by arg.doThis, arg.doThat, producing unnecessary syntax noise.

This might conflict to some part of current implementation (though I didn’t read all the code, I can see it in the manual from the function type notation t -> t -> t)…
Also the “bind” would need adjustment, for binding specified keyword arguments.

I think this will give haxe better readability while preserving all advantages of type checking if this was implemented.

2

I love how convenient this is in Python. With that said, Haxe allows an overridden method to use different argument names, but this feature would essentially make the argument name part of the type signature. Would we have to enforce argument naming in child classes?

3

I think I’m not quite prepared to answer this question…

But here’s something I passed by, for reference:

4

For default values, you can use @:structInit
http://try-haxe.mrcdk.com/#584fD
But this only works for haxe from git. In 3.4, the Sets constructor is generated incorrectly and you need to write it yourself. About it: structInit and default values? · Issue #5449 · HaxeFoundation/haxe · GitHub

1 Like
5

If you’re willing to use tink_lang, you get two solutions for this: