Open Lotes opened 2 years ago
Currently we don't consider alternatives at all in the type inference. This is a simplification that of course makes the result less "correct" / "safe", but it's intentional as it reduces the complexity a lot.
Example:
MyRule: 'a' a=ID | 'b' b=ID;
The most correct representation of the resulting type would be
type MyRule = { a: string } | { b: string }
However, these type declarations would become pretty unreadable for more complex rules. The currently generated interface is less correct, but easier to read:
interface MyRule {
a: string
b: string
}
Provided that we have a data structure that is able to capture all this information (#554), we could consider adding a configuration option to generate the more complex types instead of the simplified ones.
The setup
I have an example grammar:
Which generates the following types:
The problem
Which means that
SubRule
s need to have anage
now. Is this not wrong? If not it is a bit counter-intuitive. The user of a language should know all intrinsic rules after a while of working with it.Side-quest
This also reminds me on the type alternative labels from ANTLR4: if there is only one alternative with a label (having a hash and a name at the end of the line) ALL other alternative should have one too.
A solution
Force the user to add code action also for the other alternatives?