You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I often write utility "functions" as labels with parameters. Due to Python-style indentation I often forget to add a final return clause, as it looks obvious to me that the label ends with the indent.
This makes the script execution leak after the end of the label to the next label, which generally has at least one parameter, causing a runtime error:
labelsay_hello_and_wait(duration):
call_say_text_and_wait("hello", duration)
# comment out to demonstrate bug# returnlabelsay_goodbye(duration):
call_say_text_and_wait("goodbye", duration)
# comment out to demonstrate bug# returnlabel_say_text_and_wait(text, duration):
"[text]"
pausedurationreturn
In this example, say_hello_and_wait will leak to say_goodbye where duration will not be defined, and say_goodbye will leak to _say_text_and_wait where text (and duration) is not defined.
Proposal
It would be nice if Renpy detected that we entered a parametered label directly from above (without a proper jump/call with parameters), so it can warn us about illegal parameter label "default" entrance. This seems the easiest way to warn the user against this case.
Alternatives
If this could be detected earlier via parsing before game start it would be even better, but I understand how difficult it can be to verify (because runtime code could enter branching differently depending on the context, therefore making it not obvious that all branches return, making the parser complain that a final return is missing even if reaching the end of the block was impossible at runtime).
Finally, Lint could be a more lightweight way to check such issues and only warning us if some code is suspicious (missing return statement) without causing a strict error. But in my case I hadn't even thought about linting before I fixed the issue manually, so YMMV - and again, parsing branches is not obvious.
The text was updated successfully, but these errors were encountered:
Lint can check whether a given label statement is reachable or not (as part of the reachability analysis system). It can also check if the labels take parameters and, thanks to the recent signature reimplementation ( 😎 ) it can even check whether there are required parameters or if they all have defaults (in which case I find it slightly weird but it may be intentional).
I'm just addressing the feasability aspect though, not whether it's a good idea.
Context
I often write utility "functions" as labels with parameters. Due to Python-style indentation I often forget to add a final
return
clause, as it looks obvious to me that the label ends with the indent.This makes the script execution leak after the end of the label to the next label, which generally has at least one parameter, causing a runtime error:
Example
In this example,
say_hello_and_wait
will leak tosay_goodbye
whereduration
will not be defined, andsay_goodbye
will leak to_say_text_and_wait
wheretext
(andduration
) is not defined.Proposal
It would be nice if Renpy detected that we entered a parametered label directly from above (without a proper jump/call with parameters), so it can warn us about illegal parameter label "default" entrance. This seems the easiest way to warn the user against this case.
Alternatives
If this could be detected earlier via parsing before game start it would be even better, but I understand how difficult it can be to verify (because runtime code could enter branching differently depending on the context, therefore making it not obvious that all branches return, making the parser complain that a final
return
is missing even if reaching the end of the block was impossible at runtime).Finally, Lint could be a more lightweight way to check such issues and only warning us if some code is suspicious (missing return statement) without causing a strict error. But in my case I hadn't even thought about linting before I fixed the issue manually, so YMMV - and again, parsing branches is not obvious.
The text was updated successfully, but these errors were encountered: