A Tuple-struct Pattern Name Must Resolve in Scope

I wrote let Packet(value) = 7_u8 without any Packet constructor in scope. Rust emitted E0531 because it could not find a tuple struct or tuple variant named Packet.

The failing fixture is intentionally small. In a real project, the name often exists somewhere, but a module move, missing import, feature flag, or type-shape change makes it unavailable at this exact pattern.

Parentheses ask for a tuple constructor

Packet(value) is not a function call in pattern position. It is a tuple-struct or tuple-variant pattern. The name must resolve to a constructor whose positional fields can be destructured.

The E0531 explanation points to two common causes: a typo or a forgotten import. I add a third frequent cause in evolving systems: the declaration changed from tuple-like to named fields.

Declare or qualify the real type

The repaired fixture declares:

struct Packet(u8);

let Packet(value) = Packet(7);

For an enum, I normally qualify the variant:

let Event::Packet(value) = event else { return };

Qualification shows which enum owns the constructor and avoids collisions between similarly named variants.

Imports affect patterns as well as expressions

A use declaration can bring a tuple struct or variant into scope for both construction and matching. The use-declaration Reference describes how paths are shortened in scope.

I do not add a wildcard import automatically. use Event::* can be convenient in a small match, but explicit paths are easier to search and remain clear when several protocol enums share names such as Data, Error, or Ready.

Check conditional compilation

The declaration or import may be behind #[cfg(feature = "wire")] while the matching code is compiled without that feature. IDE analysis using one feature set can then disagree with a failing CI target.

I inspect the active feature and target configuration before assuming the name was deleted. A repair that adds another local type with the same name could mask the real build-graph problem.

This is particularly relevant for platform-specific variants and generated bindings.

Verify the declaration's current shape

If Packet now has named fields, the correct pattern is Packet { value }, not Packet(value). If it became a unit struct or unit variant, it takes no field pattern. If it is only an associated function called Packet, it cannot be destructured at all.

The tuple-struct pattern rules tie the syntax to a real tuple constructor. I navigate to the definition instead of guessing from how creation code used to look.

Re-exports can move the public path

Libraries sometimes re-export a type at a shorter path while keeping its defining module private. During a refactor, matching code may use an old internal path or omit the new public prefix.

I prefer the documented public path in downstream code. It is the compatibility surface the library intends callers to use.

For my own crate, I check whether changing the re-export would break pattern paths in users even if the underlying type remains unchanged.

Do not confuse a constructor function with structure

A function can return a Packet, but its function name is not a destructuring pattern. Smart constructors often validate or hide representation deliberately.

If only accessors are public, I use those accessors or match a public enum returned by the type. Trying to reconstruct private structure in a pattern fights the API boundary.

My E0531 checklist

In documentation and error handling, I preserve the fully qualified path at least once near the explanation. Search results for only Packet are noisy, while transport::Event::Packet connects the failure to its schema. This also helps when rust-analyzer suggests several imports with the same final segment. I choose the definition whose field types and crate ownership match the scrutinee rather than accepting the first completion that makes the unresolved name disappear.

• Is the name spelled exactly like the declaration?
• Is it a tuple struct or tuple enum variant?
• Would a qualified path make ownership clear?
• Is the required import active in this module?
• Do cfg features or target conditions hide it?
• Did the declaration change to named fields or unit shape?
• Am I accidentally treating a function as a pattern constructor?
• Is there a stable public re-export path?

The core principle is that pattern syntax is resolved against declared data structure. Parentheses do not invoke a name or search the project heuristically. I find the actual constructor, confirm its scope and shape, and then make the destructuring mirror that definition.