Use compile-time assertions to deny ZSTy DSTs #1154
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
joshlf
requested changes
Apr 30, 2024
src/util.rs
Outdated
Comment on lines
597
to
607
| const DST_IS_NOT_ZST: bool = { | ||
| assert!(!Self::DST_IS_ZST); | ||
| !Self::DST_IS_ZST | ||
| }; |
There was a problem hiding this comment.
Couldn't we just do this based on the existing KnownLayout::LAYOUT const rather than introducing new machinery in KnownLayout?
jswrenn
force-pushed
the
zesty
branch
3 times, most recently
from
024c37a
to
e4c0450
Compare
jswrenn
changed the title
jswrenn
force-pushed
the
zesty
branch
2 times, most recently
from
0b22ac7
to
d3c2576
Compare
joshlf
requested changes
May 1, 2024
| /// | ||
| /// # Compile-Time Assertions | ||
| /// | ||
| /// This method cannot yet be used on unsized types whose dynamically-sized |
There was a problem hiding this comment.
Suggested change
| /// This method cannot yet be used on unsized types whose dynamically-sized | |
| /// This method cannot be used on unsized types whose dynamically-sized |
IMO we shouldn't imply that we'll lift this restriction in the future. We might, but it's not guaranteed, and it's also pointless cognitive burden for users to think about our long-term plans when there's no specific timeline and so there's no meaningful difference between "you can't yet" and "you can't."
Same elsewhere in this PR.
There was a problem hiding this comment.
We don't want folks relying on this function as a compile-time assert on DST ZSTiness so the "yet" is load-bearing.
joshlf
approved these changes
May 1, 2024
Presently, we deny ZSTy DSTs in our APIs via panicking at runtime. However, the ZSTiness of a DST is statically detectable and can be denied instead at compile time. This PR replaces our ZSTy DST panics with compile-time assertions. Doing gives us the freedom later provide meaningful runtime semantics in such cases. Partially addresses #325 Closes #1149
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Presently, we deny ZSTy DSTs in our APIs via panicking at runtime. However, the ZSTiness of a DST is statically detectable and can be denied instead at compile time. This PR replaces our ZSTy DST panics with compile-time assertions. Doing gives us the freedom later provide meaningful runtime semantics in such cases.
Partially addresses #325
Closes #1149