language icon indicating copy to clipboard operation
language copied to clipboard

Make pseudo-privately named actual arguments an error?

Open eernstg opened this issue 5 months ago • 9 comments

Thanks to @sgrekhov for bringing up this situation.

It is currently a compile-time error for a named parameter to have a name whose first character is _.

void f({int _ = 0}) {} // Error.

However, it is not reported as a compile-time error when an actual argument is passed to such (non-existing) parameters:

void main() {
  Function f = () {};
  try {
    f(_pseudoPrivateName: 1); // OK
  } catch (_) {}
}

Should we make it a compile-time error to use actual arguments with such names?

We may introduce the ability to declare a formal parameter whose name starts with _, but we do not (as far as I can see) have any intentions to allow the parameter to have such a name, it's only considered for situations where the formal parameter name will be computed as the 'corresponding public name'. (The corresponding public name is p when the declared name is _p, but it does not exist when the declared name is _ or __ or _1, so we only intend to allow formal parameters with such declared names when other constraints are satisfied as well.)

@dart-lang/language-team, WDYT? Should we report f(_pseudoPrivateName: 1) as a compile-time error, based on the reasoning that it cannot succeed in current programs, and most likely will never succeed even in future Dart code?

eernstg avatar Aug 29 '24 11:08 eernstg