Skip to content

Feat: Allow member access on literal expressions such as [1,2,3].length #36

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

quaaantumdev
Copy link

@quaaantumdev quaaantumdev commented Jun 21, 2025

This pull request enhances the expression parser to support member access directly on literal expressions. This change makes the expression syntax more intuitive and aligns it with common patterns found in other programming languages.

The problem

Previously, the parser grammar could not handle expressions like 'hello'.length or [1, 2, 3].length. The parser treated literals and member-accessible expressions (like variables or grouped expressions) as mutually exclusive starting points. This forced the unnatural workaround of wrapping literals in parentheses, such as ([1, 2, 3]).length, just to make the expression parsable.

The Solution

The parser grammar in lib/src/parser.dart has been refactored to resolve this limitation:

  1. A new private parser rule, _primary, has been introduced. This rule unifies several types of expressions—literal, group, this Expression, and identifier — that can serve as the base of a member or index access chain.
  2. The variable parser, which is responsible for handling these access chains, was updated to use _primary as its starting point.
  3. The top-level token parser was simplified to delegate literal parsing to the variable rule, which elegantly resolves the ambiguity and allows literals to be followed by member access.

These changes make the grammar more flexible while correctly handling the new syntax.

Testing

A new test group, 'literal members', has been added to test/expressions_test.dart. It includes tests that specifically verify the new capability by accessing the .length property on list and string literals, confirming that the changes work as expected. This test would fail without the changes made. All other tests are unaffected and work just fine.

Fixes #37.

@quaaantumdev
Copy link
Author

@rbellens would be great if you want to take a look at this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Parser does not allow member access on literal expressions such as [1,2,3].length
1 participant