nicklockwood / Expression

A cross-platform Swift library for evaluating mathematical expressions at runtime
MIT License
829 stars 51 forks source link

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

Open nighthawk opened 1 year ago

nighthawk commented 1 year ago

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 commented 1 year ago

@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.