When a generic prelude function like option_unwrap_or<T> is instantiated with T=Decimal, the monomorphizer does not produce a specialised copy (e.g. option_unwrap_or$Decimal). The compilability checker then rejects the generic version (parameter type T is "unsupported"), and any caller that depends on it is also skipped.

Impact

Functions returning Option<Decimal> (decimal_div, decimal_from_string) and Ordering (decimal_compare) cannot be used with match or option_unwrap_or. The same limitation would apply to any future opaque handle type.

Option<Int> from map_get works because the monomorphizer recognises Int and produces option_unwrap_or$Int. Decimal (and potentially Map/Set handles themselves) are not in that recognised set.

Root cause

The monomorphizer (vera/codegen/monomorphize.py) infers type variable bindings from call-site arguments. When the argument type is an opaque handle type like Decimal, it either:

1. Fails to infer T=Decimal from the expression, or
2. Infers it but doesn't generate the specialisation because Decimal isn't in the set of types it considers monomorphisable.

Workaround

Avoid match and option_unwrap_or with Option<Decimal> or Ordering from decimal_compare. Use decimal_eq for equality checks and avoid division patterns that require unwrapping.

Fix

Investigate vera/codegen/monomorphize.py to understand why Decimal (and other AdtType names registered as opaque handles) are not recognised during type variable inference. The fix should generalise to all opaque handle types so future additions don't hit the same wall.

Affects: #333 (Decimal), potentially #62 (Map/Set handle values in generic contexts)