Closed uncomputable closed 2 months ago
Overall fab865793ee296920b2bd3fcd91befe9c58697e4 looks great. I feel there is a bit more we could do here:
get
I think is confusing. It's too generic to be meaningful but not standard. In the stdlib it's usually a form of optional array indexing. We should either use the generic From
/Into
trait or rename the method to build
or both. I would prefer to use From
(see next point).comp
take a non-builder is pretty nifty in PairBuilder
. But if it took a PB: Into<P>
then it could take either a PairBuilder
or a P
, thereby avoiding a lot of get
calls.comp(unit,*)
does not typecheck in general. comp(*,unit)
does, but I guess we don't need this.I think we may have gotten the compiler to the point where every error path is a real error path that can be taken. Would be good to work on a fuzzer to check this.
I will implement your suggestions. Unfortunately, impl From<PairBuilder<P>> for P
fails the orphan rule and impl Into<P> for PairBuilder<P>
fails due to a transitive implementation of Into
from the stdlib. I am looking into using AsRef<P>
.
Frustrating. Ok, AsRef or Borrow might work, or we can just implement a new dummy From-like trait, or we can implement From for the specific P
values that we need to work, or we can add from_pair_builder(PairBuilder) -> Self
to the CoreExt
trait.
I renamed PairBuilder::get
and refactored PairBuilder::<P>::comp
to accept both &P
and &PairBuilder<P>
.
utACK 5d6ffb7a6def31e5f1e0d3220ad680ed6ca35bcd but I'd like to get #73 in first because it's preventing my local tests from completing.
Rebased onto #73
Simfony expressions are translated into Simplicity expressions with a variable source type. This means that pairs can be constructed infallibly. Use
PairBuilder
to ensure this invariant at compile time and remove unnecessary unwraps.