Page 1 of 1

ZScript equivalent to dev/null

Posted: Thu May 03, 2018 12:50 pm
by Matt
Can we please get a pointer to throw unused output into?

The specific example I've got in mind is the bool that is called by A_SpawnItemEx. Literally every time I've ever needed the output of this function it was to get the actor, and the likelihood of it being false (assuming I wasn't using SXF_NOCHECKPOSITION) was low enough that simply checking for that actor being null was sufficient.

Yet every single time I do this I need to go out of my way to define a new local variable that serves no purpose except to fulfil this requirement, or do some really gross hack involving a flag that I figure that particular calling actor would never use.

It's a minor thing, but it does lead to a lot of needless clutter.

Re: ZScript equivalent to dev/null

Posted: Thu May 03, 2018 1:41 pm
by Graf Zahl
Normally that shouldn't be necessary, but the return values for this function are definitely in the wrong order.

Re: ZScript equivalent to dev/null

Posted: Thu May 03, 2018 4:12 pm
by Marisa the Magician
Unfortunately we can't change that without breaking who knows how many mods.

Re: ZScript equivalent to dev/null

Posted: Thu May 03, 2018 4:47 pm
by Talon1024
JavaScript ES6 destructuring assignment (see "Ignoring some returned values") syntax allows developers to discard unnecessary values.

For example, a line of code from paledit:

Code: Select all

let [start,] = this.subRanges[subRangeIdx].sorted();

Re: ZScript equivalent to dev/null

Posted: Thu May 03, 2018 5:20 pm
by Xaser
Heh, I run into this all the time. It's "cosmetic," but a bit of a PITA.

A suggestion: since there's already precedent for deprecating+renaming functions (e.g. A_FireCustomMissile to A_FireProjectile, albeit that was for a more serious reason) and the name "A_SpawnItemEx" is pretty antiquated anyway ("Ex" suffix, plus it spawns any actor, not just an "Item"), perhaps let's make an "A_SpawnActor" that has the same parameters & functionality but returns the Actor only. Nice n' clean.

[Also yes, we could DIY this mostly by implementing a proxy function, but it'd be nice for everyone to not to have to. ;]

Re: ZScript equivalent to dev/null

Posted: Thu May 03, 2018 5:33 pm
by Chris
C++11 has:

Code: Select all

int ret;
std::tie(ret, std::ignore) = call_returns_a_pair_or_tuple_of_two();
C++17 adds structured bindings:

Code: Select all

auto [ret, ] = call_returns_a_struct_or_array_of_two();
(I think an empty name is okay for ignored elements, I forget).

Re: ZScript equivalent to dev/null

Posted: Fri May 04, 2018 12:27 am
by Graf Zahl
Xaser wrote:Heh, I run into this all the time. It's "cosmetic," but a bit of a PITA.

A suggestion: since there's already precedent for deprecating+renaming functions (e.g. A_FireCustomMissile to A_FireProjectile, albeit that was for a more serious reason) and the name "A_SpawnItemEx" is pretty antiquated anyway ("Ex" suffix, plus it spawns any actor, not just an "Item"), perhaps let's make an "A_SpawnActor" that has the same parameters & functionality but returns the Actor only. Nice n' clean.

[Also yes, we could DIY this mostly by implementing a proxy function, but it'd be nice for everyone to not to have to. ;]
Good suggestion. That's how I'd solve it.
For leaving out single arguments in such a case, unfortunately some more work on the parser and the code generation is needed, and right now I don't have time for that.

Re: ZScript equivalent to dev/null

Posted: Fri May 04, 2018 4:54 am
by Marisa the Magician
Empty names for arguments and such sounds like a good idea to me. Unrealscript does that when you want to skip some arguments in function calls and leave them default.

Re: ZScript equivalent to dev/null

Posted: Fri May 04, 2018 12:16 pm
by Matt
Is "A_Spawn" used for anything that could result in a conflict? I see only one instance of it in something about DEH aliases but I have no idea what the implications are.

Re: ZScript equivalent to dev/null

Posted: Fri May 04, 2018 1:23 pm
by Gez
Matt wrote:Is "A_Spawn" used for anything that could result in a conflict? I see only one instance of it in something about DEH aliases but I have no idea what the implications are.
Yes, it's an MBF codepointer. See CreateSpawnFunc() in src/d_dehacked.cpp for the internal side of the implementation.