Skip to content
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

Lazy evaluation of ternary operator's true/false cases #46

Open
nighthawk opened this issue Jun 10, 2023 · 1 comment
Open

Lazy evaluation of ternary operator's true/false cases #46

nighthawk opened this issue Jun 10, 2023 · 1 comment

Comments

@nighthawk
Copy link
Contributor

I've set up a bunch of expression functions and am hitting an issue where the ternary operator might check a condition and if that condition isn't met, the true part throws an error. Say I have a date: Date variable and a format/2 function that expects a Date and String and throws an error if the first parameter is not a Date. If I then use that in an expression like date != nil ? format(date, "yyyy-MM-dd") : "None" when date = nil, it'll throw that error rather than returning "None".

I could adjust my functions to not throw errors and return nil instead, but then I'm losing useful information when I use them elsewhere. And I'd have to change most functions to always accept nil for every parameter. Not ideal.

I'm wondering if it's possible to have the ternary operator evaluate the true/false cases lazily and, in particular, only evaluate the necessary part.

Or is there another possibility to address this? Feedback appreciated.

@nicklockwood
Copy link
Owner

@nighthawk Expression doesn't currently support lazy evaluation. Unfortunately it's not a simple change because the way that the API is implemented means that the arguments are passed directly by value, and they would have to be passed as closures instead to defer evaluation.

It might be possible for you to work around this by creating a wrapper struct for your values that then evaluates your function lazily, but it would mean writing custom implementations for all the Expression functions and operators to work with your wrapper type.

Alternatively, maybe you could modify your functions to return Result<Success, Failure> values instead of throwing? Then you could preserve the error without aborting execution? You'd probably still have an issue with unwrapping the result inside an expression though.

A third option would be to handle errors C-style by returning nil and having your functions set a global error variable instead of throwing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants