-
First thing and most important: In verse, Error != Decides/Failable
- Error in verse is a a raised exception, it means a crash on the VM without possibility to handle it, verse has no error handling or catch operations due to the nature of the language design.
- <decides>/Failable Expressions are control flow logic (specially built for transactional memory in verse). Think about failable as a syntax sugar for returning true/false if a function succeeded or not (with extra internal logic for transactional memory).
Don’t get confused, these concepts about failable and error are different and should not be mixed.
-
<computes> does NOT always succeeds/finishes. It can still cause Errors or run forever (like what is happening on your case). What you mean by never erroring is a “safe” function/API call that never does anything wrong or crashes. That is the <converges> specifier (Check this for more details)
-
You CAN combine <computes> with <decides>, meaning it CAN fail, the docs also shows it and you can use on your own code if wanted. As I mentioned earlier, being <computes> does not mean that the call is always safe to be made.
-
The docs also states that “Code that provides default values for class fields or values for global variables is required to have this effect.” about the <converges> specifier, and not the <computes>.
That does not mean it is prohibited to use other methods that can work even if not always, but just informing that the behavior is not optimal for it due to other scenarios that can happen such as in your usage…
The code can’t know (at least not yet) if you are building the class instance correctly or not to prevent bad practices and show a warning on these cases (such as inside and outside OnBegin of a creative device or aother class default value).
Your error with your piece of code is still the following: You are trying to hardcode a global value as a class default, where that value is not supported and supposed to be used at that place at that time. (Or at least, should be initialized in a different scenario, like I mentioned on my examples of how to do it properly)
Keep in mind that lots of other APIs also has these same problems if not handled correctly on the expected scenarios, such as constructing a hardcoded material at compile and it not being usable at runtime because of different scenarios (very common problem that I see some people asking help with), and with SpawnProp(), that also used to crash (on this case even the editor) but they changed to just ignore the API call and return false to avoid softlocking editor sessions.