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 looking over #587 I realized that I'm not a huge fan of the current return value for the TRY protocol.
To summarize, since the introduction of the TRY protocol (#544) it uses Result to indicate whether the short circuit or not. While this meshes well with the existing type system (Value::Result already exists and does basically what we want it to) it lacks clarity and becomes a bit messy with types such as Result<T, Result<(), Error>>.
Here I'm proposing we adopt the ControlFlow enum for this protocol.
Internally it also means that we should be able to represent it as a Value to the degree that at least the internal Vm operations are supported, which basically means conversion to and from ControlFlow<Value, Value>.
While looking over #587 I realized that I'm not a huge fan of the current return value for the
TRY
protocol.To summarize, since the introduction of the
TRY
protocol (#544) it usesResult
to indicate whether the short circuit or not. While this meshes well with the existing type system (Value::Result
already exists and does basically what we want it to) it lacks clarity and becomes a bit messy with types such asResult<T, Result<(), Error>>
.Here I'm proposing we adopt the
ControlFlow
enum for this protocol.Internally it also means that we should be able to represent it as a
Value
to the degree that at least the internalVm
operations are supported, which basically means conversion to and fromControlFlow<Value, Value>
.CC: @ModProg
The text was updated successfully, but these errors were encountered: