dart-lang / dart-lang/language

Allow creating setter-names with symbol literals.

Open
#301 3 comments 1 reaction 0 assignees View on GitHub
feature small-feature
Dominant language
TeX
Stars
2.9k
Forks
239
Avg merge
2d 18h
Merged PRs (30d)
14

Description

Dart uses symbols to represent "code identifiers" at run-time. It does so for a number of reasons, one being the ability to not retain the source names at run-time unless necessary.

Symbols are introduced by the system in `noSuchMethod` invocations, as the member name or named-parameter names. Those can be compared to user supplied symbols to recognize a specific member being (mis-)called.

User symbols are created using either the `Symbol` constructor or the `#...` symbol literal.

A symbol literal like `#_foo` represents a library private name. It is not equal to `#_foo` that is evaluated in a different library, and it the only thing that is equal to the symbols created by calls of members with that private name.

The `Symbol` constructor, even when called as `const`, cannot create library private symbol names. (Some implementations did so anyway, but not all).

However, the only way to create *setter* names (like `foo=` for the setter `set foo(...)`) is to use the `Symbol` constructor. The `#...` literal syntax does not allow a trailing `=`.

That means that there is currently no (not horribly complicated) way to create a private setter-name.

We should allow symbol literals ending in a single `=`, like `#foo=`.
(We probably should also allow `#foo.bar.baz=` since the Symbol constructor accepts those, even though it doesn't correspond to any source name, whereas `#foo.bar.baz` is a library name).

This is a non-breaking change. The grammar of symbol literals becomes:
```ebnf
::= `#' ( | ( (`.' )*) `='?)
```
(The only change is the addition of ``​`='?``).

This does not conflict with any existing syntax because `#foo = 42` is already not valid (the left-hand-side is not an assignable expression). For parsing disambiguation, a symbol literal always extend as far as possible, like it already does to disambiguate `#foo.hashCode`.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.