Allow setting named private properties

[cedvdb]

I find dart constructors initializer list often hinder readability and needlessly redundant when trying to have private members. They are also sometimes annoying to read in public api scenarios

I would like the ability to populate private members with named parameters without resorting to an initializer list.

What I propose is to have those 2 snippets be equivalent:

Currently:

class House {
  final int _windows;  
  final int _bedrooms;
  final int _swimmingPools;
  House.named({
    required int windows,
    required int bedrooms,
    required int swimmingPools,
  })  : _windows = windows,
        _bedrooms = bedrooms,
        _swimmingPools = swimmingPools
;}

Suggared:

class House {
  final int _windows;  
  final int _bedrooms;
  final int _swimmingPools;
  House.named({
    required this._windows,
    required this._bedrooms,
    required this._swimmingPools,
  });
}

In both cases you'd call House.named(windows: 2, bedrooms: 1, swimmingPools: 4);. The first snippet has needless noise in it.

I'm sure this was a design decision but I can't find an issue other than the closed one I posted above about this.

[mateusfccp]

Although I agree with your reasoning, I find the proposed alternative too much obscure. It's not intuitive to have this._member as a parameter but have to use member: _ as argument.

[Levi-Lesches]

I don't mind the logic. It says that member is private, so even though you can pass it through the constructor like House.named(member: _), you shouldn't be able to access it by doing myHouse.member. It's essentially sugar for the current pattern of redirecting member to _member, which is so common it shouldn't really matter if it makes sense, since it would be recognizable anyway.

In general, there should be no guarantee that passing identifier to a constructor means that obj.identifier is valid, and this proposal is based on that.

[cedvdb]

Further more you can already do

class House {
  final int _windows;
  House(this._windows);
  House.alternatively(int windows) : _windows = window;
}

So there is somewhat of a parallel that will make the proposal feel intuitive. I can see how they both differ but they are also related

[lrhn]

So, basically, if you use an initializing formal for a privately named field as a named parameter, the name of the parameter, in the function type of the constructor, becomes the name of the field without the leading _. It still initializes the private field.

This is non-breaking and new because you currently cannot have named parameters with private names, so there are no existing occurrences of {this._foo} anywhere.

We'd have to decide whether the final variable the initializing formal introduces into the constructor list should have the private name or the non-private name. Either is fine, we just have to make a choice.

We have to decide whether another positional parameter can have the same name as either the private name or the publicized name. (Probably whatever makes it not conflict with the final variable mentioned above, or both).

We have to decide how to handle edge cases like _, __, _2, or __foo. We can disallow all of them, that'd be perfectly reasonable.

I actually also have a problem with positional initializing formals, because they show up in dartdoc.
Maybe we should generalize it and make all privately named initializing formals count as their corresponding public name in the public API (and keep it private internally in the function, so as to not break existing code, for positionals, it only affects DartDoc).

That is:

• For a private-named initializing formal, this._id,
• where id is a valid non-private identifier,
• the parameter name of the function is id instead of _id.
• If id is not a valid non-private identifier, the name of the parameter is _id,
• which is a compile-time error if the parameter is named.
• The local final variable introduced by the declaration, bound to the passed value, is still named _id,
• so existing code for positional initializing formals keeps working, only DartDoc changes.

It does introduce a new concept: The "corresponding non-private name" for a private name, which not all private names have.
And it uses that to invent names which do not occur in the source, which is ... slightly icky.

[jakemac53]

It does introduce a new concept: The "corresponding non-private name" for a private name, which not all private names has.
And it uses that to invent names which do not occur in the source, which is ... slightly icky.

I don't actually agree this is a new concept. Everybody is already doing this, its just not codified in the spec, forcing us to manually spell it out each time :).

I have never heard of any other answer to this question other than removing the leading _ - because that is after all the thing that makes it private. It has to be removed. Other solutions like prepending something other than _ would be pretty bizarre imo.

According to the analysis here https://github.com/dart-lang/language/blob/db9f63185707c4c89a69118e842e4cc6e0e59cc3/resources/instance-initialization-analysis.md, >17% of all initializers are of this form (_field = field).

[leafpetersen]

I have never heard of any other answer to this question other than removing the leading _ - because that is after all the thing that makes it private.

Of course you have, we were just discussing another answer to this question! :) As we were just discussing, we could just... not treat these as private in parameter lists. And then we're done, without any need for renaming schemes.

[jakemac53]

(╯°□°)╯︵ ┻━┻

[cedvdb]

What is the rules behind this ?

class House {
  final int _windows;
  House(this._windows);
}

It just makes sens to me but I can't really explain a reasoning, it's just sugar for

class House {
  final int _windows;
  House(int windows) : _windows = window;
}

Isn't it kind of the same ?

Quoting the analysis above:

But it has to support both positional and named parameters.

Currently only positional is supported

[Levi-Lesches]

it's just sugar for

class House {
  final int _windows;
  House(int windows) : _windows = window;
}

Isn't it kind of the same ?

From my understanding of the proposal, that'd be correct. It's more annoying when there are multiple named private parameters, but that's the simple version.

[cedvdb]

You said would be but that snippet works today. It's not clear from the comment if you knew it or not.

[lrhn]

The snippet works today, but the parameter name is the private identifier _windows. The name of positional parameters are not that important, but it does show up in the DartDoc, which is annoying, because the reader doesn't really need to know that the parameter is initializing a private field. That's an implementation detail leaking into the API (well, the API docs, but still visible).
Which means that it's not entirely equivalent to House(int windws) : _windows = windows;.

With the proposal here, the API docs would say the parameter name is windows. (That also means that the DartDoc should say [windows], not [_windows] when documenting the parameter, which is why it's not an entirely non-breaking change, name conflicts aside).

[munificent]

I think this is a good idea. It definitely feels weird. If I had a time machine, I would sure as heck get rid of _ for privacy because it causes weird stuff like this. But without a time machine, we have to make the best with what we have.

The this. syntax is really popular. More than half of constructor parameters in a large corpus of pub packages use it. Named parameters are also popular—about as common as positional parameters. And we explicitly encourage users to make fields private when possible. So you have three very common, idiomatic features that can't be combined.

It's particularly frustrating because it's very obvious what the user wants to happen when they are combined. Fully 17% of field initializers in initializer lists are _foo = foo where a private field is initialized with a parameter of the corresponding non-private name.

There is (at least) one silly corner we need to worry about. If we say that this._id introduces a parameter named id then that would imply:

class C {
  var _a;
  var _b;

  C(this._a) : _b = a; // <-- Note "a", not "_a".
}

Is that what we want?

[cedvdb]

Is that what we want?

It looks like a has been created out of nowhere but is there an alternative ?

The following is valid today but does it make sens ? Irhn mentioned privacy is leaked in the documentation, which goes against the concept of privacy. It's not really privacy here, it's just the name of the param which happens to have a character reserved for privacy if I understood correctly, but the line is a bit blury and a bit brain busting.

class House {
  final int _windows;
  final int _doors;
  House.valid(this._windows): _doors = _windows;
  House.invalid(this._windows): _doors = windows;
}

If the behavior was the same for positionals, shouldn't valid and invalid be inverted ? (valid becomes invalid and vice versa). Both are imperfect anyway, might as well have one imperfect.

If I understand correctly those today are strictly equivalent:

class House {
  final int _windows;
  House.one(this._windows);
  House.two(int _windows): _windows = _windows;
}

I can't see a good reason to let a character that is also used as an access modifiers at the start of a parameter's name be valid but I'm going on a tangent a bit. It's just that treating it sometimes as a character and sometimes as an access modifier is well, context dependent which is harder on the brain.

[Levi-Lesches]

@munificent, @lrhn proposed earlier:

• The local final variable introduced by the declaration, bound to the passed value, is still named _id.

That is, the parameter is passed in as id, but to the rest of the constructor (initializer list and body), it's still _id