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
It's a common pattern for developers to perform logic in a unconstrained function and then assert that the output is correct (due to this being cheaper than calculating the result in a constrained context). This relies on the implementation of Eq used by the types crossing the unconstrained boundary asserting an equality on every field within that type.
In the case where the Eq implementation doesn't cover all fields within the relevant type then the prover will be able to mutate any fields which are not asserted on.
We should consider whether we can fix this with a ConstrainEq trait to be used in these situations. However this could result in confusion aroundassert_eq and other functions.
The text was updated successfully, but these errors were encountered:
See: #5940 (comment)
It's a common pattern for developers to perform logic in a unconstrained function and then assert that the output is correct (due to this being cheaper than calculating the result in a constrained context). This relies on the implementation of
Eq
used by the types crossing the unconstrained boundary asserting an equality on every field within that type.In the case where the
Eq
implementation doesn't cover all fields within the relevant type then the prover will be able to mutate any fields which are not asserted on.We should consider whether we can fix this with a
ConstrainEq
trait to be used in these situations. However this could result in confusion aroundassert_eq
and other functions.The text was updated successfully, but these errors were encountered: