Closed dkorpel closed 3 months ago
Yeah, I tried to push for named arg support to be generic like that, but Walter didn't see the point and refused it. Typical.
But you could imagine the user's named args being available as traits identifiers for the passed tuple or something for stuff like this, and it'd also be automatically attached if you just forward the tuple for the compiler to use. Would be really nice to have.
OpenD merges things like that without red tape just fyi :P
I also think it'd probably be worth it to have an option to use a runtime list of names too. I could always refactor it myself but what I have in mind is something like
callWithNamedArgs(string[] names, args..., positional args...)
and/or
(VARIANT[string] namedArgs, other args...)
The value here would be for things like script language bindings, where the names are not known at compile time but want to use the library anyway.
The CT one would surely just forward to the runtime one, as the call is runtime anyway.
I can add that later, this was just the minimum thing to make me continue with Excel.
I can just hit merge too if you're ready as is, the other function can be added later if/when it is actually useful (day job has a script language thing but the script lang has its own implementation to bridge its internal variants to com anyway so it wouldn't use this hypothetical function even if it existed in all likihood)
I'm using a local copy of arsd.com so I'm not blocked by this PR or anything.
Allows you to do:
('Temporary' is argument 4 and I don't know what the intermediate arguments are lol)
Would be cool to add named argument support to
opCall
, I might write an enhancement / DIP for that. Then it could just be: