Add optional AST node type

[msujew]

The proposed OptionalAstNode<T> is a generic type that sets all properties, that could be potentially missing due to parser errors, to be optional. However, this excludes specificially:

• Properties inherited from AstNode (mainly the $type property which is always set).
• All boolean properties. Those will be set to false by the parser, even if the property wasn't parsed.
• All array property. Those will be set to [] by the parser.

This change adjusts the arithmetics language validator to use that new type to ensure that all properties are properly checked for truthyness before they are accessed. Inspired by the discussion in #1758.

[sorawee]

Thanks!

Would it make sense to make this recursive too? I believe a child node that we want to recur downward is either AstNode[] or AstNode | undefined or AstNode. Do I miss anything else?

Here's my attempt to take a stab at it. (This is the first time in my life that I do type-level programming actually! Apologies if anything is off)

export type OptionalAstNode<T extends AstNode> = {
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  [P in keyof T]: 
    P extends keyof AstNode ? 
      T[P] : 
      T[P] extends AstNode[] ? 
        OptionalAstNode<T[P][number]>[] : 
        T[P] extends any[] | boolean ? 
          T[P] : 
          T[P] extends AstNode | undefined ? 
            OptionalAstNode<Extract<T[P], AstNode>> | undefined :  
            (T[P] extends AstNode ? OptionalAstNode<T[P]> : T[P]) | undefined;
};

[sailingKieler]

Thanks!

Would it make sense to make this recursive too?

I think it does! 😀

[sailingKieler]

Please add JSdoc documentation to this definition, could essentially be the content of the PR description.
Please also leave a hint on the example/test cases in the arithmetics language.

[sailingKieler]

Suggested change

	[P in keyof T]: P extends keyof AstNode ? T[P] : T[P] extends any[] | boolean ? T[P] : T[P] | undefined;
	[P in keyof T]: P extends keyof AstNode ? T[P] : T[P] extends unknown[] | boolean ? T[P] : T[P] | undefined;

... should do the trick, too, without any need for the linter exclusion.

[sailingKieler]

Thanks!

Would it make sense to make this recursive too?

I think it does! 😀

[msujew]

@sailingKieler @sorawee Making AST nodes deep optional, makes them very difficult to deal with. While technically correct on a type level, you cannot pass them into any method expecting a "normal" AstNode, due to type mismatch. This makes validations/scoping suddenly very difficult to write. I'll probably get back to this in the new year.

I've just tried this out, and it would require a more involved ast reflection API that gives us the optionality of all properties of an AST node. That way we could have a generic hasAllProperties method that returns whether all required properties have been correctly entered.