This issue goes partway towards addressing #325.
For example, Ref::from_prefix_with_trailing_elements documents a panic if Self is a ZST. However, the ZST-iness (pronounced "zestiness") of a type relevant here is always a static property and can be reported via postmonomorphization error.
The advantages of this are several-fold:
- it allows us to maintain the consistent policy that our APIs do not panic (with the exception of panics in user-supplied
TryFromBytes validators)
- it is forwards compatible with us relaxing the compile error to a panic in future non-breaking releases
- it may have optimizer advantages
Postmonomorphization errors currently have a bit of a 'weirdness' factor (and an unwieldy name), but I suspect that will change. The recent stabilization notes for inline const exprs cite ZST-checking as a motivating case of what the feature will make possible.
This issue goes partway towards addressing #325.
For example,
Ref::from_prefix_with_trailing_elementsdocuments a panic ifSelfis a ZST. However, the ZST-iness (pronounced "zestiness") of a type relevant here is always a static property and can be reported via postmonomorphization error.The advantages of this are several-fold:
TryFromBytesvalidators)Postmonomorphization errors currently have a bit of a 'weirdness' factor (and an unwieldy name), but I suspect that will change. The recent stabilization notes for inline const exprs cite ZST-checking as a motivating case of what the feature will make possible.