{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig4fu4e55bbkiqzkwlofdz66glugxf5fmoyyexuwrmeewohhbj4vu",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkpxv2up2de2"
  },
  "path": "/t/sized-or-sizeable-str-e-g-str-const-n-usize/24213#post_1",
  "publishedAt": "2026-04-30T14:52:21.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Stringlet"
  ],
  "textContent": "Rust has `str` (where the type system loses size info) or `[u8; N]` (which loses utf-8 info.) I want size **and** utf-8, as for any `\"literal str\"` the compiler does know both.\n\nThis is to fix error handling in the next version of Stringlet. Currently my `From`s illegally panic, if either size or utf-8 are violated. For dynamic data this should be `TryFrom -> Result`. But for `&'literal str` I resist so much ceremony. Here the compiler could already check that the size fits into `[u8; N]`, while maintaining utf-8 well-formedness. (Besides: `Result` can’t be used in `const`.)\n\nIs there already a way of achieving this? Or is there a plan for something like my fantasy optional `str<const N: usize>`?\n\nFor the harder part of the question: I have several kinds of Stringlet where shorter strings can be stored with padding. So actually I’d want something like `str<0..256>`. For this case I do already have a config trait implemented for each possible number. As I’m thinking of making things more flexible, I’d need to add even more such traits and impls. That’s rather cumbersome and possibly quite a drag on the trait resolver.\n\nIf we’re getting configurable ints, and they can generically parametrize `T<const N: UInt<5..9>>([u8; N])`, that might solve this.",
  "title": "Sized (or Sizeable) str, e.g. str<const N: usize>"
}