Consider "un-aliasing" function named-node kind vs function token kind?

[helixbass]

This isn't a bug I suppose but given that at least in the Rust tree-sitter bindings Node::kind() returns the "token value" for non-named nodes, there is a bit of a "namespace conflict" where actual (function) named nodes report their kind as "function" but then the non-named nodes for the function keyword (in function expressions/declarations) also reports its kind as "function"

So were one doing it from scratch, I'd probably suggest using eg (function_expression) instead of (function)

But I'm guessing "breaking" grammar changes should be minimized?

So I don't know if eg aliasing the function keyword token (alias('function', 'function_keyword')) would be less likely to break existing code?

The current situation should be work-around-able in most if not all situations, but it just "bit me" so figured I would raise the concern

Perhaps there is a deeper question there of whether named-node kinds should be sharing the same "namespace" as non-named-node kinds (at the Rust API level or wherever)?

[helixbass]

(same thing with (class) vs class keyword node)

[amaanq]

i see what you mean - it can be a bit confusing. what about function_definition

[helixbass]

what about function_definition

As a renaming idea for (function) -> (function_definition)? Ya that also seems reasonable. My suggestion of (function_expression) comes from the names I've seen used by JS/Typescript AST's, which arguably differentiates "function expression" vs "function declaration" a bit more clearly

[amaanq]

Can you link to where you saw those ASTs? More official = more better :wink:

[helixbass]

Sure here are a couple astexplorer.net links:

Babel AST ESLint (espree) AST Typescript AST