-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
augmented()
can't occur in an initializer list of an augmenting constructor declaration, right?
#4039
Comments
augmented()
can't occur in an initializer list?augmented()
can't occur in an initializer list of an augmenting constructor declaration?
augmented()
can't occur in an initializer list of an augmenting constructor declaration?augmented()
can't occur in an initializer list of an augmenting constructor declaration, right?
It isn't explicitly specified as an error, but it is also never specified as having any meaning, which should mean it resolves to a regular identifier. We only define a meaning for It certainly wouldn't hurt to make that explicit, but I am not sure where we draw the line there. Do we need to define for every single context in which an identifier can occur, what |
I would disallow it or give it a meaning, because there is a reasonable meaning: an initializer list entry could augment an existing initializer list entry for the same variable and refer to the existing initializer. We do need to define the meaning for each code context that can occur inside an augmenting member declaration what |
So we could have this: // `augmented` in an initializer list is is a regular identifier.
int augmented() => 1;
class A {
int i; // Initial value is 1.
A();
augment A(): i = augmented();
} Or this: // `augmented` in an initializer list expression refers to the augmented
// expression that was used to initialize the same instance variable.
class A {
int i; // Initial value is 4.
A(): i = 2;
augment A(): i = augmented * 2;
} Or this: // `augmented` stands for zero or more initializer list entries.
// Assume that `value` is 3 just before the constructor runs.
var value = 3; // After the constructor execution, `value` is 6.
class A {
int i; // Initial value is 5.
int j; // Initial value is 3.
A(): i = value++;
augment A(): j = value++, assert(++value > 0), augmented;
} Or various subsets of the above. Similar examples can be created for the redirection of a redirecting generative constructor ( In addition to these positive properties we'd also have some negative ones: rules about locations in initializer lists or redirections where I agree with @lrhn that there is a danger associated with the choice that With this in mind, we still have the option to say that |
SGTM, lets just do that |
Surely it would violate some invariants that we can otherwise rely on if
augmented()
is allowed to be executed in the initializer list of a non-redirecting, or in the redirection of a redirecting generative constructor. (In short: general code gets to see an object which is not initialized.)However, I can't find an explicit indication in the feature specification that there must be such an error. Here is an example. Currently (ac9b6d1672255d2233ed612eb9c94921dca3cd3a), the analyzer does not report any errors.
I think we must specify a compile-time error for both of these situations, because the initializer list / redirection does not have access to
this
, but the body of an augmented generative constructor can accessthis
.Of course, we could also allow both of them, and consider
augmented
to be a regular identifier in both situations, potentially resolving to a static, top-level, or imported declaration. We'd then have an error ifaugmented()
in that context resolves to an instance member of the enclosing class/enum/extension-type, because the initializer list / redirection does not have access tothis
.@dart-lang/language-team, WDYT?
The text was updated successfully, but these errors were encountered: