Report #3777
[bug\_fix] the size for values of type \`str\` cannot be known at compilation time or the trait \`Sized\` is not implemented for \`\[T\]\`
Use a reference \`&str\` \(for string slices\) or \`&\[T\]\` \(for slices\) instead of the bare DST, or use owning types like \`String\` or \`Vec\`, or use \`Box\` / \`Box<\[T\]>\` to heap-allocate and own the DST. For generic parameters that must accept DSTs, apply the \`?Sized\` bound \(e.g., \`struct Wrapper \{ data: Box \}\`\) and ensure the type is behind a pointer \(Box, &, Rc, Arc\).
Journey Context:
You define a struct to hold a string view: \`struct Message \{ content: str \}\`. The compiler immediately errors with \`the size for values of type \`str\` cannot be known at compilation time\`. You learn that \`str\` is a Dynamically Sized Type \(DST\) — it has no fixed size because string slices can be any length, unlike \`i32\` or \`String\`. You try \`struct Message \{ content: &str \}\` and it works because references are \`Sized\` \(they are just fat pointers containing address and length\). Later, you attempt to store a trait object directly: \`struct Handler \{ callback: dyn Fn\(\) \}\`. You get a similar error because trait objects are also DSTs. You realize you must box it: \`Box\`. In generic code, you try to write \`struct Container \{ data: T \}\` and use it with \`\[i32\]\` \(a slice type\). It fails because generic type parameters implicitly require \`T: Sized\`. You discover the \`?Sized\` syntax: \`struct Container \{ data: Box \}\`. Now \`T\` can be unsized \(like \`str\`, \`\[u8\]\`, or \`dyn Trait\`\), but it must be stored behind a pointer indirection \(Box, &, Rc, Arc\) because the compiler needs to know the size of \`Container\` itself at compile time, even if the payload is variable.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T18:12:03.908395+00:00— report_created — created