Incorporate handling private named parameters in primary constructors

[munificent]

The primary constructors proposal now incorporates most of the declaring constructors proposal, which is great. But there's a piece that isn't in primary constructors yet that I think should be: handling private named parameters gracefully.

This subfeature lets you have initialize a private field using a named parameter whose name has the leading _ stripped off. Instead of having to write:

class House {
  int? _windows;
  int? _bedrooms;
  int? _swimmingPools;

  House({
    int? windows,
    int? bedrooms,
    int? swimmingPools,
  })  : _windows = windows,
        _bedrooms = bedrooms,
        _swimmingPools = swimmingPools;
}

You can do:

class House({
  int? _windows,
  int? _bedrooms,
  int? _swimmingPools,
});

This solves a problem users have complained about for years (#2509). I think it's important to get this in at the same time as primary constructors, because users are going to really want to use primary constructors as much as they can since they're so much shorter. If we don't handle private named parameters, then if a user wants:

• A primary constructor
• Named constructor parameters
• Encapsulated state

Then they can only pick two. I suspect they'll pick the first two and sacrifice privacy, which goes against good software engineering practices and our recommended guidance. If we strip off the _ automatically and let users have private named parameters, then they can have all three.

The declaring constructors proposal already has, I think, an excellent specification of the behavior (thanks, @lrhn!), so I don't think there's a lot of design work required to take the feature. It's pretty well baked.

[rrousselGit]

Nooo :(
I'm all for this feature, but not with the proposed syntax!

I don't like the idea of having Foo({_name}) shortcut to Foo({name}): _name = name, because that would conflict with named private parameters everywhere else.

For instance, IMO we should be able to write:

class Example {
  int _windows;

  Example copyWith({int? _windows}) => ...;

  void method() {
    copyWith(_windows: 42);
  }
}

Currently, we cannot "clone" private properties without having them leak in the public API. That's very inconvenient!

Yet private named parameters on methods couldn't work like with constructors.

---

IMO for named private parameters, they should be allowed if they are optional.

void function({int? _value}) {} // OK
void function({int _value = 0}) {} // OK
void function({required int _value}) {} // KO

As for the shortcut for initializers, I'd use a different syntax.

Maybe this? Foo({int :_name})

This syntax would be unique to constructors and would not conflict with named parameters on normal functions.

[gryznar]

Maybe it is time to fix all this privacy issues and introduce keyword for handling private members (like Kotlin)? Underscore leads to various problems like this one. Underscore may still exist, but for primary ctors only keyword declaration would work as expected

[eernstg]

I'll create a PR on the primary constructor proposal to include this feature. I didn't want to bundle several orthogonal features because that would just create more points of friction as the proposal is debated. However, if it isn't a showstopper to include this feature then I'm all for it.

@lrhn argued here that there's no need to make privately named positional parameters an error. I agree on that, and I'll use other parts of that comment to make various other clarifications and improvements.

Now, @rrousselGit wrote a comment that we need to understand and think about:

... we should be able to write:

class Example {
  int _windows;

  Example copyWith({int? _windows}) => ...;

  void method() {
    copyWith(_windows: 42);
  }
}

The only thing which will not work as written is that call sites must use the corresponding public name of the identifier, that is, we must write copyWith(windows: 42) rather than copyWith(_windows: 42).

I don't see any issues here, because there is no ambiguity and there are no name clashes.

We could consider allowing the private name as well as the corresponding public name to be used when an actual argument is passed to a named formal parameter with a private name, but I still think we'd have to allow the public name to be used (in the same library as well as in other libraries). This implies that there cannot be another named parameter whose name is the public name of a privately named parameter, which means that we can't even use this extra feature to make it possible to do anything that we couldn't already do. That is, even if we can call copyWith(_windows: 42) in the same library, that wouldn't allow us to use something like copyWith(_windows: 42, windows: 'something_else').

that would conflict with named private parameters everywhere else.

The conflict that I can see arises because it isn't possible to have a private instance variable named _id together with an instance variable named id and use initializing formals to initialize both of them.

However, developers are generally able to rename the privately named instance variable because it can't be used in other libraries, so it should be possible to work around that kind of conflict.

Do you have an example where there is a concrete conflict?

[rrousselGit]

I think there's a misunderstanding here.
I'm not talking about name clash. I'm talking about a language feature clash.

We have two features discussed here:

• Syntax sugar for Constructor({public}): _private = public. This is what this issue is about.
• Support for function(_private: ...). This is what I want, which is a separate feature.

I fear that if we implement the former, than the latter becomes not reasonable

My comment was about how aliasing _windows > windows is explicitly what I do not want:

int _windows;

Example copyWith({int? _windows});

void method() {
  copyWith(_windows: 42); // ✅ _windows is still private
  copyWith(windows: 42); // ❌ _windows leaks to the public API!
}

My concern is that if we implement the feature described in this issue, then this would conflict with private named parameters.

That is because if we are to implement this issue and private named parameters, then somehow the language treats privacy in an inconsistent manner:

// Same syntax for both named parameters
class Class({int? _a});
Class copyWith({int? _a}) => ...

// Different function prototype in the end
Class Function({int? a}) callback = Class.new;
Class Function({int? _a}) callback = copyWith;

And if we decide to instead have:

Class Function({int? a}) callback = copyWith;

Then this is exactly what I do not want, because that copyWith causes private fields to be public.

---

Currently the only way to preserve the "privacy" of such named parameter is:

Class copyWith({@internal a})

Where the @internal essentially marks the parameter as private. But I wish that we could achieve the same without annotations.

The other alternative is to define a _copyWith alongside a `copyWith:

class Example {
  int public;
  int _private;

  Example _copyWith({int public, int private}); 
  Example copyWith({int public}); // "_private" isn't cloneable in the public API
}

But this is verbose.

[lrhn]

I don't think it's an issue, because I don't want to allow private named parameters at all.
The latter was always unreasonable.

If you want a parameter that others cannot pass, make the function be private.
Having an unmentionable parameter in the function type is a problem I don't want anyone to have to deal with.

[munificent]

For instance, IMO we should be able to write:

class Example {
  int _windows;

  Example copyWith({int? _windows}) => ...;

  void method() {
    copyWith(_windows: 42);
  }
}

Currently, we cannot "clone" private properties without having them leak in the public API. That's very inconvenient!

Why do you want a public method that is visible to users outside of the library that accepts a parameter they can't pass? You may as well just delete the parameter entirely at that point.

[rrousselGit]

Why do you want a public method that is visible to users outside of the library that accepts a parameter they can't pass? You may as well just delete the parameter entirely at that point.

The defining library can pass that parameter. It's just like any other private variable.

It's fairly common with constructors to have some private parameters. At the moment, if you want private parameters, you have to define all your methods/constructors twice.

For example, my codebases are littered with code similar to:

class PublicApi {
  PublicApi({
    this.publicField,
  });

  PublicApi._({
    this.publicField,
    this.privateField
  }): _privateField = privateField;

  final int? publicField, _privateField;
}

That _privateField is an implementation detail and should not leak under any circumstance.
But because we cannot define private named parameters, I suddenly have to duplicate my constructors (or methods using a similar pattern).

This could be simplified to:

class PublicApi {
  PublicApi({
    this.publicField,
    this._privateField,
  });

  final int? publicField, _privateField;
}

---

There are many similar use-cases. For example another common one is recursive functions with a "depth" parameter:

// The public API
void recur(Obj obj) =>  _recurs(obj);

// The implementation detail
// Has extra "private" parameters
void _recurs(Obj obj, {int depth = 0}) { /* TODO logic */ }

This could become:

void recur(Obj obj, {int _depth = 0}) { /* TODO logic */ }

[lrhn]

You do need two functions/constructors, if you want to have two different APIs.
The benefit is that the function type of the public function is expressible.
If you could write void recur(Obj obj, {int _depth = 0}) { ... }, then the function type of that is void Function(Obj, {int _depth}) which is itself inexpressible outside of the library.
From the outside, users should think it has type void Function(Obj). Documentation should hide the _depth parameter.
So maybe we should make the static type depend on who's asking, and from outside of the library, the interface type and static type is just void Function(Obj).

Otherwise, if someone does var recurFun = foo.recur;, they have a function with a type that they cannot express.

If you can extend the type, then you have a function that you cannot implement, because you can't write the signature needed to override the function. That is, if you can see the parameter at all.

Dart allows private members, but also has a bunch of special-case rules for dealing with subclasses.
For example an implementing subclass is allowed (and required) to not implement private members.

For a private parameter, they'd need to either be allowed to not implement recur itself, because they can't, or be allowed to omit the _depth parameter. The latter is consistent with not seeing the _depth parameter in the public interface member signatureat all.
The compiler would presumably add an implicit {int _depth = 0} parameter to make the code compile, which your override can't access anyway. (Even better if it automatically threw a NoSuchMethodError if anyone passed a _depth argument, since it clearly doesn't know what to do with it.)

But if the subclass author can't see the _depth parameter, they can't see that they can't override with void recur(Obj obj, [void Function(Obj)? callback]). They can't, because there is an implicit and invisible named parameter.
Not great.

Just write two functions.

void recur(Obj obj) { _recur(obj, 0); }
void _recur(Obj obj, int depth) {  
  // impl
}

Then the implementation detail doesn't leak into the public API, even if it's invisible.
Someone implementing this interface only has to implement recur.

[rrousselGit]

I don't get the argument. We can write:

class Public {
  int a;
  int _b;
}

We aren't told to write two classes like so:

class Public {
  int a;
}

class _Public implements Public {
  @override
  int a;
  int b;
}

The compiler would presumably add an implicit {int _depth = 0} parameter to make the code compile, which your override can't access anyway. (Even better if it automatically threw a NoSuchMethodError if anyone passed a _depth argument, since it clearly doesn't know what to do with it.)

I don't think it'd add such parameter.
We'd allow assigning void Function(a) to void Function(a, {_b}).

Ultimately this isn't too much different from when people implement classes with private members;

class A {
  int _private;
}

void foo(A a) {
  print(a._private);
}

class B implements A {}

foo(B()); // Throws

[munificent]

For example, my codebases are littered with code similar to:

class PublicApi {
  PublicApi({
    this.publicField,
  });

  PublicApi._({
    this.publicField,
    this.privateField
  }): _privateField = privateField;

  final int? publicField, _privateField;
}

That _privateField is an implementation detail and should not leak under any circumstance. But because we cannot define private named parameters, I suddenly have to duplicate my constructors (or methods using a similar pattern).

That's fair. I find myself doing that pattern every now and then too.

At the same time, I personally find the friction here to be less than the friction around having to do:

class PublicApi {
  PublicApi({
    this.publicField,
    int? privateField,
  }): _privateField = privateField;

  final int? publicField, _privateField;
}

The last time I looked into, 17% of all constructor initializers are exactly this pattern. If I had to choose between eliminating one of these sources of friction and not the other, I would definitely pick the latter.

[rrousselGit]

That's why I said: I agree that this is a problem worth solving, I just disagree on the proposed syntax.

It wouldn't cost much to slightly tweak the proposal to leave the door open for private named parameters in the future:

class PublicApi {
  PublicApi({
    this.publicField,
    int? :_privateField, // :_private implies a ":_private = private" initializer
  });

  final int? publicField, _privateField;
}

[munificent]

I'll create a PR on the primary constructor proposal to include this feature. I didn't want to bundle several orthogonal features because that would just create more points of friction as the proposal is debated. However, if it isn't a showstopper to include this feature then I'm all for it.

You know, thinking about it more, this feature is orthogonal to primary constructors. Maybe it makes sense for me to just write a separate small language proposal for it? That would reduce the churn on the primary constructor proposal some. It might also make it easier for implementers to wrap their head around and write tests for if it's carved off into it's own small well-defined thing.

I still think we should ship it around the same time as primary constructors. I don't want to have primary constructors without this feature because that would encourage users to make fields public that they would otherwise prefer to be private. But they don't have to be stuffed into the same proposal, especially since primary constructors already has a lot of other moving parts.

[munificent]

I agree that this is a problem worth solving, I just disagree on the proposed syntax.

It wouldn't cost much to slightly tweak the proposal to leave the door open for private named parameters in the future:

The challenge here is that the feature basically is syntax. Yes, it's always easy to use a different syntax, but it's also hard to come up with a syntax that's good. In this case, we know from feedback over the years that users do sometimes expect the proposed syntax here to actually work like this issue proposes. So I think there's a good argument that this is the optimal syntax.

By the same token, even if we use this syntax for this feature, the door is still open for some other syntax to allow you to have parameters that can only be passed from within the same library. Though I have to admit, I don't find that to be a very compelling feature and the way it interacts with function typing and tear-offs seems pretty spooky to me.

[lrhn]

The big difference between private members and private parameters is that the former can be invisible, and the latter cannot.

If an interface has a private member, then outside of that library, the member is invisible. (That's what you want, it avoids name clashes and cluttering the public API.)

You are allowed to implement the public API without implementing the private members, and it's the author of the class who must make sure to not assume that all implementations has the private API implemented. Either by using base, or by not trusting values that they haven't created themselves.

To get the same kind of invisibility for a private parameter of a public method, it should be invisible in the public API.
You should be able to call the method and tear it off without knowing about the private parameter. That definitely means that the parameter must be optional, so we already have an extra restriction.

If you implement the class, then you should be allowed to implement the method without the private parameter.
Presumably the compiler adds the private parameter to the implementation. Since it has a private name, that won't name-clash.
It may still clash if the other-library author tries adding an optional positional parameter. So the presence of a privately named optional named parameter will leak into a restriction on subclass methods, that it cannot add optional positional parameters, even though it cannot see that in the public signature.
(But if that's what it takes to get Dart to allow both optional positional parameters and named parameters on the same function, I'll accept that price!)

Similarly, you can get a conflict if you implement two different interfaces that happen to have the same private named parameter with different types.

class C {
   void foo({int _x = 0}) { ... }
}
class D {
  void foo({String _x = "a") { ... }
}

and then another library can try to do

class M implements C, D {
  void foo() { print("I'm good!"); }
}

and then the compiler has to ... introduce {Object _x = 0} as a hidden synthetic parameter?
(It can probably get away with not having a default value if the name is never referenced.)
Nothing new, you can get conflict between private members today.
It can always be implemented with a type of Object?.

It's possible, but I don't really think it's worth it. If we had better forwarding functionality, having two functions might not be so bad.

void foo({....some args ...}) = _foo;
void _foo({...some args, int moreArg = 0, String extraArg = ""}) { ... }