You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, this isn't how struct expressions actually work. Only the curly braced form is a unique kind of expression. The tuple form is just a CallExpression (referring to the constructor in the value namespace), and the Unit form is just a PathExpression (referring to the const in the value namespace). In terms of building an AST, these forms don't exist.
I can understand presenting "struct expressions" as an "expression constructing a struct", and not trying to immediately confront the actual complexity of how it works. However, I think there is also risk of causing confusion with this presentation approach, since it isn't actually correct.
I recommend removing StructExprTuple and StructExprTuple entirely, removing expr.struct.tuple and expr.struct.unit, and replace the latter two with a note block that explains how the call and unit syntax works.
I traced some history back to rust-lang/rust@8554d5e which started this way of presenting it (and rust-lang/rust@332c046 for unit structs). I don't actually know if Rust has always modeled tuple structs as callable functions in the value namespace (as opposed to a constructor in the type namespace like the braced syntax), but I assume it was and that the docs were just written this way to make it easier for the reader to understand.
The text was updated successfully, but these errors were encountered:
I agree with the recommendation, a note referring to call/path expressions should be much less confusing than the current state. I think we should also add a note to call/path expressions referring to [items.struct.tuple]/[items.struct.unit], so that it's clear that call might refer to a tuple struct, etc.
ehuss
added a commit
to ehuss/reference
that referenced
this issue
Apr 28, 2025
This removes the grammar rules StructExprTuple and StructExprUnit, and
removes these as distinct expressions. Instead, a note block is used to
let the reader know how the constructors can be accessed in the value
namespace.
This stems back to the beginning of this documentation, which presumably
was presenting these as distinct kinds of expressions just as a
simplification or to match what people's mental models might be.
However, they are not distinct expressions, and I think it is misleading
to pretend that they are.
Closesrust-lang#1802
Struct expressions are defined with the grammar:
However, this isn't how struct expressions actually work. Only the curly braced form is a unique kind of expression. The tuple form is just a CallExpression (referring to the constructor in the value namespace), and the Unit form is just a PathExpression (referring to the const in the value namespace). In terms of building an AST, these forms don't exist.
I can understand presenting "struct expressions" as an "expression constructing a struct", and not trying to immediately confront the actual complexity of how it works. However, I think there is also risk of causing confusion with this presentation approach, since it isn't actually correct.
I recommend removing StructExprTuple and StructExprTuple entirely, removing
expr.struct.tuple
andexpr.struct.unit
, and replace the latter two with a note block that explains how the call and unit syntax works.I traced some history back to rust-lang/rust@8554d5e which started this way of presenting it (and rust-lang/rust@332c046 for unit structs). I don't actually know if Rust has always modeled tuple structs as callable functions in the value namespace (as opposed to a constructor in the type namespace like the braced syntax), but I assume it was and that the docs were just written this way to make it easier for the reader to understand.
The text was updated successfully, but these errors were encountered: