Skip to content

Consider compiler-erroring instead of panicking in DST APIs #1149

Closed
@jswrenn

Description

@jswrenn

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions