-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parse error on multiplying two switch expressions #628
Comments
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 |
That's because most normal uses would use it as a statement ( |
It parses as a statement even inside an
|
Yes, that's because things inside a block are statements... Why would you like to multiply two |
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 |
Yes, expressions are intended for real expressions without logic flow... so those are disabled. |
So you want to evaluate expressions which may consist of 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 A ternary |
That's only because, when evaluating expressions, it is more likely to be an error when statements are encountered.
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 |
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 |
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, |
I can see how loops would open you up to DoS attacks if you are running this as e.g. a web service. But |
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 |
OK. I don't think it would be difficult to add. I'll add that support, then you can use |
PR #630 does this - it allows |
|
It works when I parenthesize the first expression:
The text was updated successfully, but these errors were encountered: