Closed ttencate closed 1 year ago
It is parsing it as a statement. This works...
let x = switch 1 {} * switch 2 {};
That's what I thought. Why is there a non-expression switch
statement anyway? 1; 2; 3;
is a valid Rhai program, so clearly expressions can be statements too.
That's what I thought. Why is there a non-expression
switch
statement anyway?1; 2; 3;
is a valid Rhai program, so clearly expressions can be statements too.
That's because most normal uses would use it as a statement (if
also). Parsing it as an expression will incur an additional indirection every time it is encountered.
It parses as a statement even inside an if
expression:
let x = if true { switch 1 {} * switch 2 {} }
^ Unexpected '*'
Yes, that's because things inside a block are statements...
Why would you like to multiply two switch
statements without assigning the result to anything?
Why would you like to multiply two
switch
statements without assigning the result to anything?
I'm not saying you shouldn't or can't do it... but usually there is no great need.
I'm using https://rhai.rs/book/engine/expressions.html. Edit: actually, I'm not using that anymore because for some reason it disallows if
and switch
expressions, but my primary purpose is still to evaluate expressions.
ctually, I'm not using that anymore because for some reason it disallows
if
andswitch
expressions, but my primary purpose is still to evaluate expressions.
Yes, expressions are intended for real expressions without logic flow... so those are disabled.
So you want to evaluate expressions which may consist of switch
? That would be a bit involved, as the action blocks in a switch
may be statements, so you'll end up running statements.
Unless it is also restricted to expressions there.
I'm running some Rhai code to compute some value from some inputs. It's intended to be a pure function. I'm exposing no functions to the engine that have side effects, and the scope is truncated afterwards back to its initial size. Whether Rhai thinks my code is an "expression" or a "statement" or a "block of statements" or a "box of chocolates" does not matter to me :)
It's strange to me that if
and switch
expressions would be disabled while evaluating expressions. We can emulate the same behaviour by exposing a Rust function to the engine.
A ternary condition ? value_if_true : value_if_false
, would that be considered a "real expression without logic flow"? How about (condition as f64) * (value_if_true) + (1.0 - (condition as f64)) * (value_if_false)
?
It's strange to me that
if
andswitch
expressions would be disabled while evaluating expressions. We can emulate the same behaviour by exposing a Rust function to the engine.
That's only because, when evaluating expressions, it is more likely to be an error when statements are encountered.
A ternary
condition ? value_if_true : value_if_false
, would that be considered a "real expression without logic flow"? How about(condition as f64) * (value_if_true) + (1.0 - (condition as f64)) * (value_if_false)
?
In Rhai, a form of the tenary operator can be easily implemented as a custom syntax expressions... so yes it is an expression... I know that's not the most ideal...
What I can do is to add an advanced version of compile_expression
such that it takes a parameter allowing statements. It is a very small change in the code (changing from false
to true
), but right now there is no out-of-the-box method to parse an expression with if/switch-expressions.
That's okay. Since a statement block also evaluates to the last statement, I can just use that. It also helps with more complex expressions, e.g. if the user wants to introduce helper variables or eve functions. On second thought, I don't really understand the use case of eval_expression
, but that might just be me :)
I don't really understand the use case of
eval_expression
, but that might just be me :)
Different use cases. Many people don't need a full-blown scripting language. All they need is to evaluate expressions for customized config. They don't need scripts; they need only expressions.
For these cases, eval_expression
is ideal for them as they don't have to worry about users throwing in loops and variable declarations etc.
I can see how loops would open you up to DoS attacks if you are running this as e.g. a web service. But if
and switch
expressions can't be used for that. Nor can variable declarations.
That's true, except that they both have blocks which can run anything inside...
Maybe I can restrict the blocks to have only expressions... then it is OK to have if
and switch
in expressions...
OK. I don't think it would be difficult to add. I'll add that support, then you can use Engine::eval_expression
and both if
and switch
will work as long as their blocks contain only expressions.
PR https://github.com/rhaiscript/rhai/pull/630 does this - it allows if
and switch
expressions.
switch 1 {} * switch 2 {}
will continue to cause a parse error because the first switch
is parsed as a statement. This is by design.
It works when I parenthesize the first expression: