Closed matthewpratt13 closed 1 month ago
An idea:
TupleStructExpr
node entirely due to the ambiguity – this can be resolved at a later stage (see above).TupleStructPatt
– it uses parse_pattern()
instead of parse_expression()
, so although there may be similarities, the parsing function called and field types are technically different, so as long as this is respected, there shouldn't be a problem.TupleStructDef
– it is the blueprint for an instantiated tuple struct object, constructed by a call expression (see above).
It is presently impossible for the parser to syntactically distinguish between a functional call expression (i.e.,
foo(bar, baz)
) and a tuple struct expression (i.e.,Foo(bar, baz)
). This can likely be solved later on, using a symbol table, so it's not a massive problem at present.According to the Rust reference book:
"A struct expression with fields enclosed in parentheses constructs a tuple struct. Though it is listed here as a specific expression for completeness, it is equivalent to a call expression to the tuple struct's constructor."
For example:
It would just be a matter of looking up the type of the symbol
c
and treating its subsequent assignment as a struct constructor function call, wherepos
is the constructed struct.