dart-lang / dart-lang/language
Allow creating setter-names with symbol literals.
- 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
Assessment
This issue has not been assessed yet.