rhaiscript / rhai

Rhai - An embedded scripting language for Rust.
https://crates.io/crates/rhai
Apache License 2.0
3.73k stars 175 forks source link

? operator / "return if value is ()" #738

Closed msparkles closed 1 year ago

msparkles commented 1 year ago

Currently, as far as we can tell from the language reference, it's rather cumbersome to immediately return () when the value is ().

Is such an operator possible? Alternatively, checking if a value is () could be less awfully looking. Currently it seems that the best way is just to check the type. Or you could cast any non-unit value to boolean true, and unit to false.

There's many ways to go about this.

schungx commented 1 year ago

This can be implemented quite easily... However I am not sure if this would be a good idea...

This potentially opens up new code return paths that are very subtle and hard to catch. There is no type checker as in Rust to make sure users don't make typos.

This may cause bugs in scripts that are very difficult to catch.

msparkles commented 1 year ago

I see. Fair point.

There's also another way, that is to somehow introduce a scope / closure that looks like (borrowing syntax from Kotlin):

some_var?.let { this_wont_be_null ->
   ...
}

Maybe something like that would be better, since it introduces a clear hierarchy?

It doesn't necessarily have to be technically a closure or visually one, something like if let from rust would work as well but we're not sure how the syntax for that would even look.


Semirelated, we looked at the book again, apparently you should be able to say if some_var != ()?

When we tried that it complained about the corresponding == operator for (Foo, ()) isn't implemented, despite the book saying it should be true if not defined if the two types are different.

msparkles commented 1 year ago

We can make a separate issue if that's not an intended behaviour of Rhai.

schungx commented 1 year ago

When we tried that it complained about the corresponding == operator for (Foo, ()) isn't implemented, despite the book saying it should be true if not defined if the two types are different.

This is strange, as it should return false... I suppose Foo is a custom type?

msparkles commented 1 year ago

Yes, it's a custom type.

msparkles commented 1 year ago

Oh, we should've said != not ==, our bad 😓

schungx commented 1 year ago

Let me try that out to check... I suppose it should automatically return true...

schungx commented 1 year ago

@Mg138 you're correct. == and != etc. do not return false and true as expected for custom objects. That's a bug.

Thanks for catching it. The fix should be in the next release.

Unless you're in a hurry? In that case I can release a point fix...

msparkles commented 1 year ago

We can wait, just tag us when it's ready so we can migrate old code.

schungx commented 1 year ago

@Mg138 you can pull from this master to try out the fix.

msparkles commented 1 year ago

It works! :100:

schungx commented 1 year ago

Thanks for catching this.

schungx commented 1 year ago

Closing this for now... Feel free if there are any more issues.