Allow return without expression

[skasti]

Small change to allow writing return #5070 instead of return [#5070] and similar.
Still allows the old way of returning only using expressions, but I find this syntax less error-prone.

Also explicitly setting _value to 0 if no value is returned, as I have had some confusion where I get a unexpected _value but _value_returned is 0 😅

[terjeio]

This is a breaking change? Returning an explicit value with e.g. return [123.456] will no longer work?
I am currently without access to a controller so cannot check.

FYI I am going to add expresssion support to ENDSUB and clearing of _value and _value_returned on CALL since these were not in compliance with the LinuxCNC spec.

[skasti]

This is a breaking change? Returning an explicit value with e.g. return [123.456] will no longer work? I am currently without access to a controller so cannot check.

No, it just means you can use any of:

return 1
return [1]
return #5070
return [#<something>+10]
etc

FYI I am going to add expresssion support to ENDSUB and clearing of _value and _value_returned on CALL since these were not in compliance with the LinuxCNC spec.

I don't think I understand. Will read again tomorrow and see if brain is braining :P

[skasti]

@terjeio Do you think this can get merged? I can't see that it is breaking anything from using it for a while 🤔

[terjeio]

I am a bit hesitant to add this as it breaks compatibility with LinuxCNC and is not a neccessary change. I'll come back to it a bit later.

[skasti]

I don't see how this breaks compatibility with anything? it just extends the current mode of operation so that you do not need to encapsulate your return value with []

[skasti]

ngc_read_real_value will call ngc_eval_expression if the first character encountered is [, so this should not break compatibility with current usage. It only adds some flexibility 😅

[skasti]

The reason for setting _value to 0 here, is that just setting it when a macro/subroutine starts does not ensure it is 0 when returning if the macro/subroutine also calls other subroutines or macros. In that case you risk "leaking" the returned _value of an internally called macro/subroutine.

If this is also how it works in other gcode dialects, and it is done on purpose as a feature, I will agree that setting it to zero is a breaking change, and I will remove it 😅