Allow read-only access to initializing formals.

[eernstg]

For convenience, and because it is non-disruptive, we wish to support read-only access to initializing formal arguments, that is, the this.x style arguments that generative constructors may have. An example:

class C {
  final int x;
  final int y;
  C(this.x) : y = x + 1 {
    int z = x + 2;
    assert(z == y + 1);
  }
  const C.constant(this.x) : y = x + 1;
}

The details of this language change are as follows:

• The grammar is unchanged.
• An initializing formal this.x of a constructor C introduces the name x into a scope that covers C's initializers, but not the body; it is considered to be a final parameter.
• The semantics of such an initializing formal access is that it accesses the parameter, not the field. This matters because the initializing formal may be captured by a function expression, and the field may be updated.

The feature is currently available in dart2js under the flag --initializing-formal-access (which will be removed such that the feature is available in general), and some tests are available in the files tests/language/initializing_formal_*_test.dart.

Tracking bugs for the individual tasks:

• vm (VM: Allow read-only access to initializing formals. #26656)
• dart2js (dart2js: Allow read-only access to initializing formals. #26657)
• dev_compiler (dev_compiler: Allow read-only access to initializing formals. #27176)
• analyzer (analyzer: Allow read-only access to initializing formals. #26658)
• specification (specification: Allow read-only access to initializing formals. #26659)

There are no tasks for the formatter and style guide because this change does not affect the syntax.

Edit: Note that the scope rule was changed such that the initializing formal is not in scope in the body, which means that existing usages of the field in the body will preserve their current semantics.

[munificent]

such that x can be accessed in C's initializers and body; it is considered to be a final parameter.

I thought the plan was that the initializing formal is only visible in the initialization list. Putting it in scope in the body would shadow the field, which I think is a breaking change. Consider:

class C {
  String x;
  C(this.x) {
    x = "after";
  }
}

main() {
  var c = new C("before");
  print(c.x);
}

This prints "after" today but would be an error with the plan here, right?

[floitschG]

correct.

[mhausner]

@floitschG: can you clarify what you mean by "correct"?

Shadowing the field in the constructor body (as described by @eernstg above) is indeed a breaking change, but it's the only reasonable semantics. Magically hiding the initializing formal parameter in the body would go against all scoping rules in Dart.

We do have code in the dart library that breaks under the new semantics. For example:

class _FileStream ... {
 ...
  _FileStream(this._path, this._position, this._end) {
    if (_position == null) _position = 0;  // <<<< this will be a runtime error.
  }
  ...

[munificent]

it's the only reasonable semantics. Magically hiding the initializing formal parameter in the body would go against all scoping rules in Dart.

From the spec's perspective, an initializing formal creates a local variable whose scope is the initializer list and which disappears before the constructor body, because, I think, that's the easiest way to spec it.

From the user's perspective, though, what they will think they see is that the field is in scope during the initialization list (but can only be read from and not written to). Of course, that's not strictly true, because the "field" is accessible even before the super() call which allocates the instance, but that's a detail most users can ignore without noticing a difference.

What the user will see is what they expect to see, I think: a name that comes into scope at the constructor parameter list and stays in scope through the body. It's just that half-way through, it magically transforms from a read-only local variable to the actual field, in a way that's virtually invisible to them.

[eernstg]

I think magically switching x from being a denotation of a parameter in the initializer list into being a denotation of the field in the body would be a really nasty trap for people to fall into (in the rare cases where it matters they would fall right into it and spend a long time discovering what's going on). It's a very alien kind of scoping.

The main usage where it matters (which is already a bit weird) is probably receiving the value of a field directly by an initializing formal, then later fixing it up to be something else in the body. Why not just receive the value as an explicit parameter and then compute the right value for that field in an initializer or in the body? But that case would be caught, because it is modifying a final parameter.

A more tricky case is when the body contains a function literal that captures the field (now: the parameter), and the field gets modified later on. That's semantically breaking, and it is likely to go under the radar. Could we hint that this is a dangerous practice when we discover that the capture of an initializing formal parameter occurs? Is it ever likely to be exactly the right thing to do, or can we assume that "they should have captured the field, anyway" is always true?

In all cases the problem can be handled by changing occurrences of x in the body to this.x, which would correspond to the usage which is probably already common when a normal parameter has been declared with the same name as a field, and both the parameter and the field are accessed in the body.

To sum up, this is very much about detection of the breaking constructs, and we do have information about where they are at compile time.

[kmillikin]

On Thu, Jun 9, 2016 at 12:05 AM Bob Nystrom notifications@github.com
wrote:

it's the only reasonable semantics. Magically hiding the initializing
formal parameter in the body would go against all scoping rules in Dart.

What the user will see is what they expect to see, I think: a name that
comes into scope at the constructor parameter list and stays in scope
through the body. It's just that half-way through, it magically transforms
from a read-only local variable to the actual field, in a way that's
virtually invisible to them.

That's not what I'd expect to see. The simple model that I would expect is
that the parameter list binds parameters, that 'this.x' is shorthand for a
parameter with the name 'x' that is used to initialize a field named x
(left to right through the iniitializing formals and before any other
initializers), and that parameter x has the exact same scoping rule as all
the other parameters.

If I wanted to refer to the field x in the body where it's shadowed by the
parameter x, I'd expect to have to write this.x like everywhere else in
Dart. It seems like a wart that this won't be the case.

As Erik notes, you can observe the difference by capturing 'x' in an
expression in the initializer list.

[lrhn]

If I wanted to refer to the field x in the body where it's shadowed by the
parameter x, I'd expect to have to write this.x like everywhere else in
Dart. It seems like a wart that this won't be the case.

It is a wart. For Dart 2.0 we might consider removing the wart and make the parameter scope cover the body.

We can't do that right now since it would break existing constructors that take a this.x parameter and refer to the x field in the constructor body using just x.

[eernstg]

It's about breaking existing code versus having rules that make sense, i.e., rules that developers will "get" rather than constantly getting confused about them. I tend to think that "gettable" rules is a very important criterion---for instance, all parameters have the same scope rules.

Note that it's only a breaking change when the access is a capture or a modification (including x += 1), and we can give a hint about the capture.

[eernstg]

OK, turn around, the matter has been resolved IRL: We'll let the initializing formal be in scope in the initializer list and not in the body, judging that the breakage of the rule is too heavy a burden. I'll adjust the wording of the initial comment in this issue.