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
While there is good support for making sure that literals in an expression make sense lexically, there is no type safety or rules about which operators work on which values.
For instance, there is no intuitive or unambiguous behavior to checking if a string is ">=" another string, nor is there well-defined behavior for what negating a bool (-(1 > 2)) would do.
Currently if any operation isn't evaluable in golang itself, this library will panic. Panics are bad. Instead, an error should be returned in cases where operations against a type don't make sense.
The text was updated successfully, but these errors were encountered:
While there is good support for making sure that literals in an expression make sense lexically, there is no type safety or rules about which operators work on which values.
For instance, there is no intuitive or unambiguous behavior to checking if a string is ">=" another string, nor is there well-defined behavior for what negating a bool (
-(1 > 2)
) would do.Currently if any operation isn't evaluable in golang itself, this library will panic. Panics are bad. Instead, an error should be returned in cases where operations against a type don't make sense.
The text was updated successfully, but these errors were encountered: