Whereas RootChecked specifies that the wrapped Hugr has a particular OpType at the "root" (i.e. entrypoint), allowing to move the error from checking onto the caller, the only effect of RootCheckable is to rule out passing in a Hugr that has already been RootChecked to a different type, i.e. cases that are guaranteed to fail. This seems of marginal benefit and probably not worth the code. I suggest either:
-
Give RootCheckable an associated error type, which can be Infallible if you have already RootChecked (the same OpType). Given the function/etc. taking a RootCheckable probably has an error type of it's own, you'd then have to parametrize that over the associated RootCheckable::Error, so I suspect most functions wouldn't bother; but one could (and thus rule out the caller having to match an impossible error) if you wanted. This is probably not worth it....
-
Just remove RootCheckable; functions using it should take either HugrView/Mut or RootChecked.
Thoughts @aborgna-q et al?
Whereas RootChecked specifies that the wrapped Hugr has a particular OpType at the "root" (i.e. entrypoint), allowing to move the error from checking onto the caller, the only effect of RootCheckable is to rule out passing in a Hugr that has already been RootChecked to a different type, i.e. cases that are guaranteed to fail. This seems of marginal benefit and probably not worth the code. I suggest either:
Give RootCheckable an associated error type, which can be
Infallibleif you have already RootChecked (the same OpType). Given the function/etc. taking a RootCheckable probably has an error type of it's own, you'd then have to parametrize that over the associated RootCheckable::Error, so I suspect most functions wouldn't bother; but one could (and thus rule out the caller having to match an impossible error) if you wanted. This is probably not worth it....Just remove RootCheckable; functions using it should take either HugrView/Mut or RootChecked.
Thoughts @aborgna-q et al?