Repository navigation
Consider compiler-erroring instead of panicking in DST APIs #1149
Description
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
TryFromBytesvalidators) - 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.
Activity
joshlf commentedon Apr 29, 2024
Note that this partially addresses #325. I think we should leave #325 open and continue the main discussion there, but it's good to have this as a separate issue so we can block #671 on it.
Use compile-time assertions to deny ZSTy DSTs
Use compile-time assertions to deny ZSTy DSTs
Use compile-time assertions to deny ZSTy DSTs
Use compile-time assertions to deny ZSTy DSTs
Use compile-time assertions to deny ZSTy DSTs (#1154)