Add possibility to consistently get object property name

[DisDis]

We need to get object property name in cases like Angular 2 ngOnChanges (when you need to compare key from changes map with object property name):

ngOnChanges(Map<String, SimpleChange> changes);
It would be great to have something like nameof in C#, so that we could get property name and don't be afraid that someone will rename property.

nameof(obj.propertyName); // 'propertyName'

[matanlurey]

Considering that you can't use this information (i.e. there is no reflective support), what would this accomplish?

[lrhn]

You can use it in noSuchMethod.
It might even help you with the named arguments of Function.apply, but only if you are somehow allowed to denote a named parameter of a function signature.

It's a good idea. The current symbol literals are stupid - they're basically shorthands for strings, there is no relation to the identifier you actually want to match. That makes typos hard to detect and refactoring impossible to automate. Example:

abstract class Foo {
  int bar();
}
class MockFoo implements Foo {
  noSuchMethod(i) {
    if (i.memberName == #baar) return 42;   // Whoops
    return super.noSuchMethod(i);
  }
}

I wouldn't use a macro like nameof (Dart doesn't have precompiler macros otherwise), but I would definitely like something that takes qualified name in scope and provides the symbol for that name. It should be recognizable in renaming and other refactorings.

We can't use #foo since that already works for things that are not in scope.
So, for the giggles, let's try ##foo. It would have a grammar like a symbol, but be interpreted differently:

import "self.dart" as self;
abstract class C {
  static foo({bar});
  baz({qux});
  get toto;
}
main() {
  var c = ##C;
  var cFoo = ##C.foo;
  var cFooBar = ##C.foo.bar; // maybe.
  var cFooBar2 = ##self.C.foo.bar;
  print(identical(cFooBar, cFooBar2));  // true, yey!
  // var wrong = ##C.biff;  // Invalid, no biff declared in C.
}

and

class MockFoo implements Foo {
  noSuchMethod(i) {
    if (i.memberName == ##Foo.bar) return 42;  
    // or just `== ##bar`, using the dynamic this-scope since "bar" isn't otherwise in scope.
    return super.noSuchMethod(i);
  }
}

Other possible, but probably too odd, syntaxes: #foo.bar#, #:foo.bar, #!foo.bar ...
No great syntax so far :(

See also #30518,

[ranquild]

@matanlurey if (changes.containsKey(nameof(field)) ....

[matanlurey]

At least for that particular API, we decided it was probably wrong.

I don't know if I'd push for a language feature to fix the API we created (personally).

[lrhn]

There are many places where using symbols is just making life harder for yourself, but they are still useful in a few places (noSuchMethod is the primary culpit). It is annoying that you can't link a reference to a particular variable or declaration, it means that you don't even detect typos and refactorings won't work. Even DartDoc does better than that.

The language feature by itself makes sense. Whether it carries its own weight, and whether it is worth prioritizing over other language features, are different questions.

[DisDis]

In our big project. Main priority is code support. We have 'toName', 'toSymbol' an analog of nameof. It is made using a transformer and the special code for run vm test.
We very often use this for:
Deserialization/Serialization, Angular.Dart, noSuchMethod

// Deserialization
class AccountDeserializer extends EntityDeserializer {
  static final _rightsSymbol = toSymbol((Account o) => o.rights);
  static final List<DeserializeField> _fields = [
    new DeserializeSingleField("isOwner", toSymbol((Account o) => o.isOwner)),
    new DeserializeSingleField("isAdmin", toSymbol((Account o) => o.isAdmin)),
....

// Angular
ngOnChanges(Map<String, SimpleChange> changes){
   if (changes.containsKey(nameof(field)) ....
}

Interface

toSymbols([o.field1, o.field2]);// => [#field1,#field2]
toSymbol(o.field1);// => #field1
toSymbols((Task o)=>[o.field1, o.field2]);// => [#field1,#field2]
toSymbol((Task o)=>o.field1);// => #field1

toNames([o.field1, o.field2]);// => ['field1','field2']
toName(o.field1);// => 'field1'
toNames((Task o)=>[o.field1, o.field2]);// => ['field1','field2']
toName((Task o)=>o.field1);// => 'field1'

All this is directed to ensure that the code is connected at all parts. Developers should receive a real "Find usages". Developers should safely refactor the code. Also in our company, literals are forbidden. Since literals are potential errors.
Now the transformer has become a problem, as we move to build. 'nameof' solves the problems at the language level.

@matanlurey @lrhn

[jodinathan]

this would help me so much.

All my models are like:

class SomeClass extends Model {
  int _myProp;

  int get myProp => _myProp;
  set myProp(int x) {
    this.modified('myProp', _myProp, _myProp = x);
  }
}

would be amazing to do something like:

class SomeClass extends Model {
  int _myProp;

  set myProp(int x) {
    this.modified(##SomeClass.myProp, _myProp, _myProp = x);
    // becomes
    this.modified('myProp', _myProp, _myProp = x);
  }
}

[kevmoo]

@lrhn @munificent @leafpetersen – is this more of a language request?

I've been hitting this a lot in the last few days – would make a lot of folks very happy!

[munificent]

Yes, this sounds like a language request to me. Want to move it over to the language repo?

[kevmoo]

Yes, this sounds like a language request to me. Want to move it over to the language repo?

Sure!

[eernstg]

I guess the desired guarantee here (cf. the C# nameof) would be that a given symbol corresponding to a single identifier or operator does in fact exist as the name of a declared member of some type.

If we make this a built-in property of certain symbols (say, by spelling them as ##foo rather than #foo), it is not immediately obvious to me how we could support specification of that type. We could of course just require that there is some type, somewhere, that has a member called foo, and if there is no such type then ##foo is a compile-time error.

But that's a rather weak guarantee. So maybe the following would be more practical:

main() {
  const s1 = memberSymbol<A>(#foo); // OK, s1 gets the value `#foo`.
  var s2 = memberSymbol<B>(#bar); // OK, memberSymbol(...) is always const.
  var s2 = memberSymbol<B>(#foo); // OK, `foo` is in the interface of `B`.
  var s3 = memberSymbol<B>(#baz, staticMember: true); // OK.
  var s4 = memberSymbol<A>(#qux); // Compile-time error.
  memberSymbol(#s1); // Error, refuses to infer a type argument, and `s1` not a member.
}

abstract class A {
  foo();
  Symbol get test => memberSymbol(#foo); // OK, type argument `A` inferred.
}

class B extends /*or implements, or mixes in*/ A {
  int get bar => 42;
  static void baz() {}
}

This would allow implementations of noSuchMethod to use a plain memberSymbol and rely on inference (the desired and inferred type argument is always the enclosing class), and all other usages could give an explicit type argument if needed.

The memberSymbol "function" would be special in that an application of it is a constant expression, and its argument must (of course) be a constant expression, and the evaluation just returns its argument if the given type does have a member with that name; with an argument which is not a member, like memberSymbol<A>(#qux) above, the expression is a compile-time error.

We could extend this idea slightly to allow for an optional argument staticMember which would allow us to check that a given symbol is the name of a static member of the given type (which must then be a class type, of course); we could also just omit support for that kind of check, or we could allow it without any special marker (so we'd simply use memberSymbol<B>(baz)).

We could of course also consider checking other symbols at compile-time (classSymbol(#String) ok, classSymbol(#NoSuchClass) compile-time error), and we might be able to offer these services in a more unified manner (using a single isSymbol with various optional arguments), but the main point is that we are likely to want a little bit more than just "this symbol corresponds to a declared name in this program".