Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sizeness Trait #5

Open
HeroicKatora opened this issue Mar 12, 2020 · 1 comment
Open

Sizeness Trait #5

HeroicKatora opened this issue Mar 12, 2020 · 1 comment
Labels
new trait Proposal for a new trait to be added

Comments

@HeroicKatora
Copy link

HeroicKatora commented Mar 12, 2020

There are some parts of the language with special-cased interaction based on the size information ot types. The plain core::mem::transmute requires the compiler to prove size-equivalence of two types, in a much less generic setting than the type bounds themselves suggest. The core::mem::transmute_copy requires the caller to unsafely uphold that the first parameter is not smaller than the second. And zero sized types (ZST) have additional properties:

  • They are not really allocated but instead are expressed as dangling pointers.
  • Transparent wrapper types are allowed to have an arbitrary number of zero-sized fields without losing the property of inheriting the layout of a single non-zero-sized field, especially if the alignment requirement of the ZST itself is 1.
  • All ZSTs have the exact same validity requirements: none.

These properties allow skipping or entirely eliding some validity checks. This is the size equivalent of Unaligned for alignment. For example, transmuting into a ZST can never violate its validity requirements and is always sound, although it might violate a type's safety requirements. This does not imply that all ZSTs implement ZeroSafe, which is also concerned with safety requirements.

Prior art

  • zerocopy and bytemuck do not have this concept.
  • typic has SizeOf which is an alias to <T as Layout>::Size where the Size associated type of Layout is an typenum::marker_traits::Unsigned.
@Lokathor
Copy link

Small point of order: violating safety invariants isn't actually sound if you don't clean up your mess properly before things go wrong.

That's why the ZeroSafe proposal is about safe, not just valid.

@rylev rylev added the new trait Proposal for a new trait to be added label Mar 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new trait Proposal for a new trait to be added
Projects
None yet
Development

No branches or pull requests

3 participants