Currently nested_tuple.0.0 is not legal and gives the following error
error: unexpected token: `0.0`
--> src/lib.rs:2:19
|
2 | let x = nested_tuple.0.0;
| ------^^^
| | |
| | unexpected token
| help: try parenthesizing the first index: `(tuple.0).0`
error: aborting due to previous error
error: Could not compile `playground`.
To learn more, run the command again with --verbose.
Could we change this behavior to parse it as (nested_tuple.0).0 instead?
I assume that this could only be done if we are fine with not parsing 0. in a future edition, see this thread for discussion about that
This idea was spawned by @jethrogb in the thread about not parsing 0. float literals
I think use of the .0 syntax should be discouraged in general, so I don't feel a need to improve it. Personally, I try to avoid even single-level anonymous fields, because they make the code hard to follow:
x.0 = y.1 + 2;
I try to use destructuring instead, which allows naming the fields:
This doesn't have to do with number type inference, so that doesn't matter. However, I think we should do this after we sort out if we are going to make 0.-like float literals a hard error in future editions. But even if we don't make it a hard error, I still think we should do this. This is because floating point fields identifiers doesn't make sense because floating point weirdness (like NaN and -0.0 != 0.0), so this is the only reasonable interpretation of the syntax.
The lexer sees name.0.0 and spits out [(Ident "name") (Punct ".") (Lit "0.0")]. In order to make this a valid parse, "all" that has to happen is the parser has to learn to accept a float literal as a key for a place (like it does for integer literals already) as a nested tuple access. Alternatively, it can learn to split apart the float literal token in this specific case.
How does name.0.name lex and parse today? Naively, I'd expect the 0. to be lexed as a float currently. (On mobile, can't check.)
Yes please, make this happen. It's a small, annoying ergonomic bug that I stub my toe on fairly regularly. I agree with @kornel that destructuring is generally a better idea, but there are times when I'm writing masses of tests and just using the number notation is easier. In some cases (niche ones) it is also easier, like when you've got a fixed-size vector/matrix and are treating the numbers as indexes.
I prefer your syntax too, but sometimes the compiler generates worse code; I don't have an example at hand but I remember that many times I used to look at the assembly and see that setting let x = y; and then using x would generate copying instructions even if y is not used any more.
Although I agree that destructuring is often more elegant, I see no good reason to forbid writing name.0.0. It's an inconsistency that adds friction when writing code. I was quite surprised when I found out that it doesn't work.