ElementsProject
Update return type of Bitcoin time lock jets
The updated function signatures are easier to read and structurally equivalent to the previous signatures.
(Please double-check if I got the output variants in the right order.)
I dunno about this.
AFAIK the other aliases are complicated structural types that realistically only have one meaning (at least, within the set of standard jets).
Here you are aliasing 2^32 which is used everywhere, giving it different names as though the different names somehow defined separate types. I think this is more misleading than useful.
Different units like Kilometers and Miles are the canonical example for using type aliases. We don't have to return exactly Height + Time for parse-lock, but returning 2^32 + 2^32 is definitely confusing. How are left 32-bit values different from right 32-bit values?
Simplicity has no opaque types in which we can wrap different units, so type aliases seem like the best option.
Different units like
KilometersandMilesare the canonical example for using type aliases.
Those docs are insane and wrong. If you have time to spare you should file an issue against them. Having Kilometers and Miles types which can be mixed with no errors or even warnings is dangerously misleading. It's like having a firearm with a "safety" switch which does nothing at all, or a seatbelt which isn't actually attached to the vehicle.
Simplicity has no opaque types in which we can wrap different units, so type aliases seem like the best option.
I think they're worse than nothing because they lead to a false sense of type safety.
Phew. I understand what you mean. Simplicity has no safety features where kilometers can be distinguished from miles, if both are, say, 32-bit integers. However, there are many type aliases in the tech report, in particular for Bitcoin and Elements. Should we drop them all?
No, because most of them are intended as shorthand for structural types (which are otherwise hard to read), not to create further distinctions between types.