Named parameters cannot start with an '_' character

[peter-ahe-google]

The specification contains this line:

"It is a compile-time error if the name of a named optional parameter begins with an ‘_’ character."

There is no reason for this restriction, please remove it.

[DartBot]

This comment was originally written by sammcca...@google.com

---

+1, I don't like this restriction.

That said, I think there's a slight issue - optional parameter names are part of the public API, but in general names beginning with underscores are not.

(The limitation bothers me more than the inconsistency would, though)

[DartBot]

This comment was originally written by @jinmingjian

---

Maybe, it is better to revise the "Privacy" section before resolving the bug. Firstly, Dart only "supports two levels of privacy". Then, the idea of "Privacy is indicated by the name of a declaration" itself is unusual(in my very limited language experience, athough I think it is funny^_^). All of these are restricted. I suggest to considering some modularized ways in current Java community, like osgi, jigsaw(java 8) to declare the privacy side concern(module boundary) in one standalone way(like in dart source self or pub spec kinds) to decouple the privacy from name.

[DartBot]

This comment was originally written by scribe....@gmail.com

---

I was doing this:

class CRSelect {
  List<int> _selectArray;
  List<int> _inputArray;
  int _selectValue;
  int _selectCount;

  CRSelect(this._selectArray, this._selectValue, this._selectCount,
      [this._inputArray]);

  List<int> get data() => _selectArray;
  List<int> get input() => _inputArray;
  int get value() => _selectValue;
  int get count() => _selectCount;
}

But now I get this error on the optional parameter, which seems kind of odd, as if I need to make the optional parameter public but it's ok that the first three required parameters can be private. Besides this bug, would there ever be a reason to enforce such a restriction? Just confused by this, as if I'm thinking about this fundamentally wrong. Thanks.

[gbracha]

a. The pain point will be addressed by optional positional parameters.

b. There is a reason for the restriction, otherwise it wouldn't be there. It is discussed in the spec in some detail.

---

Set owner to @gbracha.
Added WontFix label.

[feinstein]

@gbracha could you please link here the specs so we could understand the rationale behind this restriction?

[eernstg]

The spec addresses this question here.

The main point is that (1) it seems natural to consider a named parameter whose name starts with _ to be private, and (2) if an instance method has a private named parameter _x then it is not possible to override it by a declaration in a different library (because an override must accept at least the same named parameters, but if it declares its own named parameter _x then the two occurrences of _x are not considered to be the same name, according to the rules of other parts of the language). So it's just too quirky and we won't do it. ;-)