Open jfecher opened 2 years ago
Update: with the approach of preventing side effectful computations in if
branches via passing a boolean condition to the side effectful function, we could use that to implement these operators if we want to as well. The naive desugaring to if
in my previous comment would automatically benefit from handling side effects this way. Then we can implement it as long as it wouldn't incur a large runtime penalty.
@jfecher can this be closed?
No, it is still a valid design question of whether we want these operators. It could make the Rust -> Noir transition slightly easier for example.
Personally I think this is more of a footgun than a useful feature considering the restrictions of ACIR. We could potentially allow this as a brillig-only feature however.
I do think the different precedence of &&
and ||
would make them a useful addition.
I think we should make the change, updating the stdlib to use &&
and ||
over their bitwise variants, then see just how many more constraints are generated so that we can have some estimate.
These logical operators are currently unimplemented presumably because they are sugar for
if a then b else false
andif a then true else b
respectively - and if statements are also unimplemented. If keeping lazy evaluation for these operators would be as slow as we believeif
will be at runtime - it may be preferable to make these operators strict instead.