Skip to content

Consider removing StructExprTuple and StructExprUnit #1802

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ehuss opened this issue Apr 24, 2025 · 1 comment · May be fixed by #1803
Open

Consider removing StructExprTuple and StructExprUnit #1802

ehuss opened this issue Apr 24, 2025 · 1 comment · May be fixed by #1803
Labels
A-grammar Area: Syntax and parsing

Comments

@ehuss
Copy link
Contributor

ehuss commented Apr 24, 2025

Struct expressions are defined with the grammar:

StructExpression ->
      StructExprStruct
    | StructExprTuple
    | StructExprUnit

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.

@ehuss ehuss added the A-grammar Area: Syntax and parsing label Apr 24, 2025
@WaffleLapkin
Copy link
Member

WaffleLapkin commented Apr 26, 2025

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.

Closes rust-lang#1802
@ehuss ehuss linked a pull request Apr 28, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-grammar Area: Syntax and parsing
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants