Currently, any Expr that we wish to represent a value of 0 has to be specified with a fixed machine-integer type, a choice which may rely on non-local analysis of what sequences of operations are performed using the 0-value elsewhere in the Format or Expr we are constructing, and where there is almost always only one sound choice of primitive Expr::U*, with all other potential choices resulting in failure during type-inference (in the general case). While there are some exceptions to this, e.g. add(Expr::U8(0), Expr::SeqLength(...)) will yield a root ascription of U8, even in these cases the choice of which machine-rep to use for our zero-value may have cascading implications for the rest of the tree.
Given that 0 is a representable value for all machine integer types (including as-yet unimplemented signed-int types), and a good number of constant-values we might use have a slight bias towards wanting to be zero compared to most other definite values (e.g. expr_eq(SeqLength(seq), Expr::U*(0)) for checking if a sequence is empty, NULL checks for Offset16/Offset32 values in OpenType, using a base address of 0 for writing absolute WithRelativeOffset offsetting under the refactored implementation in #226), it is both quite simple to implement a distinguished primitive Expr::Zero, and would offer a minor but noticeable QoL improvement to writing zero-valued expressions in a usage-agnostic fashion.
As an alternative, the idea behind Expr::Zero can be extrapolated to a more broadly-applicable Expr::PolyConst(u8) that accepts an integer value that can be represented in every currently-supported integer type in our model (and though would clash with signed-int types as propsosed in #213, would cease to be necessary in the event #228 is adopted). Such a primitive would have the same general properties of Expr::Zero at the type-level, but would be able to represent any value small enough to fit into a u8 in a context that might require it to receive non-U8 type-ascription for the Format to be well-typed.
Currently, any
Exprthat we wish to represent a value of0has to be specified with a fixed machine-integer type, a choice which may rely on non-local analysis of what sequences of operations are performed using the0-value elsewhere in theFormatorExprwe are constructing, and where there is almost always only one sound choice of primitiveExpr::U*, with all other potential choices resulting in failure during type-inference (in the general case). While there are some exceptions to this, e.g.add(Expr::U8(0), Expr::SeqLength(...))will yield a root ascription ofU8, even in these cases the choice of which machine-rep to use for our zero-value may have cascading implications for the rest of the tree.Given that
0is a representable value for all machine integer types (including as-yet unimplemented signed-int types), and a good number of constant-values we might use have a slight bias towards wanting to be zero compared to most other definite values (e.g.expr_eq(SeqLength(seq), Expr::U*(0))for checking if a sequence is empty, NULL checks forOffset16/Offset32values in OpenType, using a base address of0for writing absoluteWithRelativeOffsetoffsetting under the refactored implementation in #226), it is both quite simple to implement a distinguished primitiveExpr::Zero, and would offer a minor but noticeable QoL improvement to writing zero-valued expressions in a usage-agnostic fashion.As an alternative, the idea behind
Expr::Zerocan be extrapolated to a more broadly-applicableExpr::PolyConst(u8)that accepts an integer value that can be represented in every currently-supported integer type in our model (and though would clash with signed-int types as propsosed in #213, would cease to be necessary in the event #228 is adopted). Such a primitive would have the same general properties ofExpr::Zeroat the type-level, but would be able to represent any value small enough to fit into au8in a context that might require it to receive non-U8 type-ascription for the Format to be well-typed.