@error passthrough on 'Return' statements

[Ascendant]

It would be nice to be able to use 'Return MyFunction()' to both return the values from that function *and* the @error/@extended codes. It looks ridiculous, and is probably wasteful to change the below code:

Func _ReturnErr()
    Return SetError(1,0,1)
EndFunc

Func _ReturnReturnErr()
    Return _ReturnErr()
EndFunc

_ReturnReturnErr()
If @error Then ConsoleWrite("Error returned correctly"&@CRLF)

to this code:

Func _ReturnErr()
    Return SetError(1,0,1)
EndFunc

Func _ReturnReturnErr()
    ; Wasteful temporary storage
    $tempVal=_ReturnErr()
    ; This looks ridiculous, setting @error to @error:
    If @error Then SetError(@error,@extended)
    Return $tempVal
EndFunc

_ReturnReturnErr()
If @error Then ConsoleWrite("Error returned correctly"&@CRLF)

I recognize that there is function 'localization', but I believe that 'Return FunctionName()' makes more sense to return the value AND the @error\@extended code information. It would save extra work and make more sense in the end.

Actually, even better - I recommend a new keyword - something like 'ReturnWithSubError', which will take the last @error + @extended codes returned by a called function and return them as the @error/@extended values.

This will prevent breaking old code, and make code clearer, easier, and more sensible. Code with SetError(@error) looks (and is) ridiculous, in my opinion. (Sorry, don't mean to offend)

[Valik]

Absolutely not. The design is fine the way it is. It is designed to be verbose for a reason: reliability. If it's possible for values to propagate then it's no longer possible to determine where the value originated from.

Also, the least you could do is actually try to write the "ridiculous" code correctly.

Func _ReturnReturnErr()
    Local $tempVal=_ReturnErr()
    Return SetError(@error,@extended, $tempVal)
EndFunc

Look at that, SetError() makes the ReturnWithExtraGarbage work like you described. And, once again, the behavior exists for a reason. The idea of some magic Return statement was rejected in favor of allowing SetError() to take and return a user-specified value. Its verbose, clean, convenient and fits with the other behavior. A magical keyword would just be confusing.

Lastly, regarding your inline comment about "wasteful temporary storage"... when did you get the source code? How do you know how "wasteful" it is? Somebody who knows far more than you once said, "...Premature optimization is the root of all evil." Think about that the next time you attempt to criticize a language you do not know the implementation details of (even though if you really cared about the implementation details of those supposedly wasteful temporaries you could, I don't know, ask or search since it's not a secret).

[Ascendant]

Okay, it looks like I touched on a nerve - and that wasn't the intention.

By the looks of your "correction" to my code, aren't you sending *more* data back and forth - by passing the temporary variable to SetError() also (before finally returning the value)?

Of course, yes - I *have* searched the forums, and I really don't know the internals of how temporary variables plus SetError() are implemented. But how do I get a developer to answer a post on either matter, when I've had posts before (directed at developers) completely ignored? And with this type of attitude of 'you don't know what you're talking about - and I'm not providing an answer here' (which might have taken less words?), how do I have any hope of learning about the internals?

Maybe it'd be more clear if you think of a huge array being returned. Passing that to a local variable, passing it to SetError() and then Returning it - in any other language, that's a waste. If there is some hidden implementation that avoids all that, yes I'd like to know - but give people like me some place to find that out, rather than from random forum users' guesses. Here in your response would have been nice, but instead i get a lash of the whip.

I do still see use for a keyword like 'ReturnWithSubError', as it would avoid all the extra bits - and would also be clear to the programmer what is being returned. However, if this still seems like a ridiculous idea - please please provide some option on how to get information from developers on the implementation of temporary storage & SetError()'s implementation rather than posting something that will be ignored.

thanks

[Valik]

Wow, what do you know, we have a a forum called ​Developer Chat. I wonder if maybe the developers answer posts there?

Keep in mind, we aren't going to reveal all the implementation details of the language. It's somewhat well known, however, that array's have been implemented as copy-on-write for years and a year or so ago all variables were changed to copy-on-write as well. So as long as you aren't changing the variable in the temporaries then there's not much performance impact - even with massively large arrays.

[Ascendant]

From the name and description, 'Developer Chat' looked as though it was for, well, 'Developers' (and 'C++ geeks'?). That's what turned me away - I had figured I'd need to be one or the other to be allowed to post (if that was worded differently I would have definitely gone there).

Thanks for answering though. Never heard of copy-on-write, but I'll post in the Developer Chat area rather than continue this here.