Skip to content

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

@jswrenn

Description

@jswrenn
Collaborator

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.

Activity

joshlf

joshlf commented on Apr 29, 2024

@joshlf
Member

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.

added 3 commits that reference this issue on May 1, 2024
e4c0450
0b22ac7
d3c2576
added a commit that references this issue on May 1, 2024
03d13f9
added a commit that references this issue on May 1, 2024
fb51cad
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @joshlf@jswrenn

      Issue actions

        Consider compiler-erroring instead of panicking in DST APIs · Issue #1149 · google/zerocopy