You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of commit f11f2ed, the language specification has been modified to slightly relax the constraints on the usage of operator == in constant expressions. The updated spec language occurs in one of the items about what it takes to be a constant expression:
\item An expression of one of the forms \code{$e_1$ == $e_2$} or \code{$e_1$ != $e_2$}
where $e_1$ and $e_2$ are constant expressions, and either both evaluate to a numeric,
string or boolean value, or at least one of $e_1$ or $e_2$ evaluates to \NULL{}.
The previous wording allowed only numeric, string, or boolean values and the null object, but the new wording allows arbitrary objects on one side, as long as the other side evaluates to the null object (which could be because it is the expression null, or because it is some other expression, possibly including formal parameters from the enclosing constructor declaration, that evaluates to the null object for each constant object expression that denotes said constructor).
This means that it is now possible to use constructs like the following also for constant expressions like const C(e1, e2) where e1 and/or e2 evaluate to instances which are not numeric, not strings, and not booleans:
classC {
finalObject opt1;
finalObject opt2;
// Ensure that at most one of opt1/2 is non-null.constC({this.opt1, this.opt2}) :assert(opt1 ==null|| opt2 ==null);
// Indirectly ensure that exactly one of opt1/2 is null. For instance, it// is a compile-time error to use `const C.tricky(...)` with two different lists:// the arguments are not equal (so the assert "looks OK"), but they are// both non-null, and that causes the use of `!=` to be an error.constC.tricky({Listthis.opt1, Listthis.opt2}):assert(opt1 != opt2);
}
main() {
var c;
c =constC(); //# 01: ok
c =constC(opt1:4); //# 02: ok
c =constC(opt2:2); //# 03: ok// Make the `assert` fail.
c =constC(opt1:4, opt2:2); //# 04: compile-time error
c =constC.tricky(opt1: [], opt2:null); //# 05: ok
c =constC.tricky(opt1:null, opt2: []); //# 06: ok// Make the `assert` fail.
c =constC.tricky(); //# 07: compile-time error// Make the evaluation attempt to use `!=` on two non-null objects, hence fail.
c =constC.tricky(opt1: [1], opt2: [2]); //# 08: compile-time errorprint(c); // Avoid 'unused' hint.
}
Note that some discussions in the same topic area occurred in #26980 and #30288. The example is a variant of an example given in this comment on #30288.
leafpetersen
added
the
area-language
Dart language related items (some items might be better tracked at github.com/dart-lang/language).
label
Jun 11, 2018
lrhn
added
the
area-meta
Cross-cutting, high-level issues (for tracking many other implementation issues, ...).
label
Jun 22, 2018
munificent
removed
the
area-language
Dart language related items (some items might be better tracked at github.com/dart-lang/language).
label
Jul 11, 2018
As of commit f11f2ed, the language specification has been modified to slightly relax the constraints on the usage of operator
==
in constant expressions. The updated spec language occurs in one of the items about what it takes to be a constant expression:The previous wording allowed only numeric, string, or boolean values and the null object, but the new wording allows arbitrary objects on one side, as long as the other side evaluates to the null object (which could be because it is the expression
null
, or because it is some other expression, possibly including formal parameters from the enclosing constructor declaration, that evaluates to the null object for each constant object expression that denotes said constructor).This means that it is now possible to use constructs like the following also for constant expressions like
const C(e1, e2)
wheree1
and/ore2
evaluate to instances which are not numeric, not strings, and not booleans:Note that some discussions in the same topic area occurred in #26980 and #30288. The example is a variant of an example given in this comment on #30288.
Subtasks
The text was updated successfully, but these errors were encountered: