Assertion updated in constructor tear-off ambiguities tests
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t01.dart
index 86d5802..07d54e3 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t01.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '(' token. Test that f(a<b, c>(d)) is
/// parsed as f((a<b, c>)(d))
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t02.dart
index 07683ea..063c353 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t02.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '(' token. Test that f(a<b, c>(d)) is
/// parsed as f((a<b, c>)(d))
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t03.dart
index 479641b..72de464 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A01_t03.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '(' token. Test that f(a<b, c>(d)) is
/// parsed as f((a<b, c>)(d))
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t01.dart
index 9cd2465..8b615c1 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t01.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ')' token. Test that f(a<b, c>) is
/// parsed as f((a<b, c>))
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t02.dart
index 75098a9..b553cdb 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t02.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ')' token. Test that f(a<b, c>) is
/// parsed as f((a<b, c>)). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t03.dart
index 79c2669..a04a18c 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A02_t03.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ')' token. Test that f(a<b, c>) is
/// parsed as f((a<b, c>)). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t01.dart
index 6e4527a..ac260ea 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ']' token. Test that [a<b, c>] is
/// parsed as [(a<b, c>)]
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t02.dart
index b32a5da..3cfdca8 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ']' token. Test that [a<b, c>] is
/// parsed as [(a<b, c>)]. Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t03.dart
index 46f22d7..c0f86e3 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A03_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ']' token. Test that [a<b, c>] is
/// parsed as [(a<b, c>)]. Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t01.dart
index 6c515f3..6925b39 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '}' token. Test that {a<b, c>} is
/// parsed as {(a<b, c>)}
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t02.dart
index 5d9f80c..3d32072 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t02.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '}' token. Test that {a<b, c>} is
/// parsed as {(a<b, c>)}. Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t03.dart
index 1af7301..a335785 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A04_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '}' token. Test that {a<b, c>} is
/// parsed as {(a<b, c>)}. Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t01.dart
index 43bbd40..d7bc504 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ':' token. Test that a<b, c>: is
/// parsed as (a<b, c>):
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t02.dart
index 9f562fa..fadf6e3 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ':' token. Test that a<b, c>: is
/// parsed as (a<b, c>):. Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t03.dart
index 94ebe06..2ba6a79 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A05_t03.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ':' token. Test that a<b, c>: is
/// parsed as (a<b, c>):. Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t01.dart
index d8600b0..4d5bbcd 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t01.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ';' token. Test that a<b, c>; is
/// parsed as (a<b, c>);
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t02.dart
index 99bdd82..8072536 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t02.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ';' token. Test that a<b, c>; is
/// parsed as (a<b, c>);. Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t03.dart
index df9bcd9..f2810b8 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A06_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ';' token. Test that a<b, c>; is
/// parsed as (a<b, c>);. Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t01.dart
index bdfb126..6024f9b 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ',' token. Test that a<b, c>, is
/// parsed as (a<b, c>),
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t02.dart
index 6fd1736..5b1966c 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ',' token. Test that a<b, c>, is
/// parsed as (a<b, c>),. Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t03.dart
index d0300da..0bbaee3 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A07_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by ',' token. Test that a<b, c>, is
/// parsed as (a<b, c>),. Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t01.dart
index f2d9fd6..0314dbc 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '.' token. Test that a<b, c>. is
/// parsed as (a<b, c>).
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t02.dart
index f49a0f1..044bae5 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '.' token. Test that a<b, c>. is
/// parsed as (a<b, c>). . Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t03.dart
index 303f3b7..ec0117a 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A08_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '.' token. Test that a<b, c>. is
/// parsed as (a<b, c>). . Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A09_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A09_t01.dart
index 26bef13..4610eeb 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A09_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A09_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '?' token. Test that a<b, c>? is
/// parsed as (a<b), (c>?)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A10_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A10_t02.dart
index 4a0ea72..7a46164 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A10_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A10_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '==' token. Test that a<b, c>== is
/// parsed as (a<b, c>)==. Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A10_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A10_t03.dart
index aba1fe4..b9e2b47 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A10_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A10_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '==' token. Test that a<b, c>== is
/// parsed as (a<b, c>==. Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t01.dart
index d3b9260..3d126e9 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '!=' token. Test that a<b, c>!= is
/// parsed as (a<b, c>)!=.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t02.dart
index fb550ad..920cad5 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t02.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '!=' token. Test that a<b, c>!= is
/// parsed as (a<b, c>)!=. Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t03.dart
index 30bc3cd..dcd091d 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A11_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '!=' token. Test that a<b, c>!= is
/// parsed as (a<b, c>!=. Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t01.dart
index a1a01c8..8ec28ba 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '..' token. Test that a<b, c>.. is
/// parsed as (a<b), (c>..)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t02.dart
index 812e76f..c1f3f87 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t02.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '..' token. Test that a<b, c>.. is
/// parsed as (a<b), (c>..). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t03.dart
index 940e89f..85ac092 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A12_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '..' token. Test that a<b, c>.. is
/// parsed as (a<b), (c>..). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t01.dart
index 8340368..a587fa9 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '?.' token. Test that a<b, c>?. is
/// parsed as (a<b), (c>?.)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t02.dart
index 506b77d..444e84b 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '?.' token. Test that a<b, c>?. is
/// parsed as (a<b), (c>?.). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t03.dart
index ebd1a91..545dbe8 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A13_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '?.' token. Test that a<b, c>?. is
/// parsed as (a<b), (c>?.). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t01.dart
index b5a6942..7084a35 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t01.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '??' token. Test that a<b, c>?? is
/// parsed as (a<b), (c>??)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t02.dart
index 867ccf3..664dbad 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '??' token. Test that a<b, c>?? is
/// parsed as (a<b), (c>??). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t03.dart
index 0ca0061..07f87fd 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A14_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '??' token. Test that a<b, c>?? is
/// parsed as (a<b), (c>??). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t01.dart
index 6a1bbd5..c2dee25 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '?..' token. Test that a<b, c>?.. is
/// parsed as (a<b), (c>?..)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t02.dart
index ec35f46..4d99af9 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '?..' token. Test that a<b, c>?.. is
/// parsed as (a<b), (c>?..). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t03.dart
index 207458c..c10cc23 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A15_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '?..' token. Test that a<b, c>?.. is
/// parsed as (a<b), (c>?..). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t01.dart
index 229b689..4b725dd 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t01.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '&' token. Test that a<b, c>& is
/// parsed as (a<b), (c>&)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t02.dart
index e486605..6a2bbe5 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '&' token. Test that a<b, c>& is
/// parsed as (a<b), (c>&). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t03.dart
index f754dbe..73a4d7d 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A16_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '&' token. Test that a<b, c>& is
/// parsed as (a<b), (c>&). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t01.dart
index f21a0a9..423cabb 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '|' token. Test that a<b, c>| is
/// parsed as (a<b), (c>|)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t02.dart
index b2bbb56..a0606f9 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '|' token. Test that a<b, c>| is
/// parsed as (a<b), (c>|). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t03.dart
index d61b035..79dba3e 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A17_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '|' token. Test that a<b, c>| is
/// parsed as (a<b), (c>|). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t01.dart
index fbfcc29..3746fbb 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '^' token. Test that a<b, c>^ is
/// parsed as (a<b), (c>^)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t02.dart
index fdd961e..bfbf333 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t02.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '^' token. Test that a<b, c>^ is
/// parsed as (a<b), (c>^). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t03.dart
index 4afdf6f..99131a0 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A18_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '^' token. Test that a<b, c>^ is
/// parsed as (a<b), (c>^). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t01.dart
index 3326274..f61bf30 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '+' token. Test that a<b, c>+ is
/// parsed as (a<b), (c>+)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t02.dart
index 27b8ad0..3462967 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '+' token. Test that a<b, c>+ is
/// parsed as (a<b), (c>+). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t03.dart
index 0543a4b..b8d978b 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t03.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '+' token. Test that a<b, c>+ is
/// parsed as (a<b), (c>+). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t05.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t05.dart
index 3a4860f..896cd4d 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t05.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t05.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '++' token. Test that a<b, c>++ is
/// parsed as (a<b), (c>++). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t06.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t06.dart
index d339fea..8ad920d 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t06.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A19_t06.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '++' token. Test that a<b, c>++ is
/// parsed as (a<b), (c>++). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t01.dart
index e3f469b..f503b6a 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '*' token. Test that a<b, c>* is
/// parsed as (a<b), (c>*)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t02.dart
index f77bb1e..13cbbe2 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '*' token. Test that a<b, c>* is
/// parsed as (a<b), (c>*). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t03.dart
index 2029032..bcbc62f 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A20_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '*' token. Test that a<b, c>* is
/// parsed as (a<b), (c>*). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t01.dart
index 533a132..ec3c35d 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '%' token. Test that a<b, c>% is
/// parsed as (a<b), (c>%)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t02.dart
index 02983ec..84da85b 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '%' token. Test that a<b, c>% is
/// parsed as (a<b), (c>%). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t03.dart
index 93c3cf8..6d4388c 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A21_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '%' token. Test that a<b, c>% is
/// parsed as (a<b), (c>%). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t01.dart
index 631b6bb..e1fc433 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '/' token. Test that a<b, c>/ is
/// parsed as (a<b), (c>/)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t02.dart
index 57b8265..d151d42 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '/' token. Test that a<b, c>/ is
/// parsed as (a<b), (c>/). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t03.dart
index 7527db6..6315aa7 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A22_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '/' token. Test that a<b, c>/ is
/// parsed as (a<b), (c>/). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t01.dart
index 4a825f5..dd8ea64 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '~/' token. Test that a<b, c>~/ is
/// parsed as (a<b), (c>~/)
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t02.dart
index 9aef487..0096a96 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '~/' token. Test that a<b, c>~/ is
/// parsed as (a<b), (c>~/). Test generic function tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t03.dart
index 28e2485..81db4a0 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A23_t03.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks disambiguate by '~/' token. Test that a<b, c>~/ is
/// parsed as (a<b), (c>~/). Test constructor tear-off
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t01.dart
index 46dabb0..51db820 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t02.dart
index 2f70538..b9d86c9 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t03.dart
index 3a3f607..4e39d9d 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t04.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t04.dart
index 0584182..2192377 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t04.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t04.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t05.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t05.dart
index 9b8cc29..bae8e3c 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t05.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A24_t05.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t01.dart
index ba635a5..fb2455d 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t02.dart
index 3ecb300..98fb55e 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t03.dart
index 95861ea..e8243f5 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t04.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t04.dart
index 8de60db..f69e34e 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t04.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t04.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t05.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t05.dart
index 5ae4dfc..87b2b4a 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t05.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A25_t05.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t01.dart
index 45566fa..dd23879 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t02.dart
index a767b6e..3a44a8d 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t03.dart
index 2d37c59..4f9b5a0 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t04.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t04.dart
index 18f58f9..84c8399 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t04.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t04.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t05.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t05.dart
index 73fbc3a..95c7d91 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t05.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t05.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t06.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t06.dart
index 3d0bd3b..7ed21a6 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t06.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t06.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t07.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t07.dart
index 8590ca6..c977efb 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t07.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t07.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t08.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t08.dart
index d91c54f..ade8b98 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t08.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t08.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t09.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t09.dart
index 2b11c50..4a1d915 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t09.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t09.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t10.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t10.dart
index 6068229..ff8fd08 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t10.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A26_t10.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t01.dart
index cf13379..4e69cfc 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t01.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t02.dart
index 41c572e..a7a2e2f 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t02.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t03.dart
index 4413ddf..e01a08c 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A27_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t01.dart
index b8965e9..e3f53d9 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t02.dart
index 2f22c02..9bbe433 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t03.dart
index 7244cd6..7d82acd 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t04.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t04.dart
index 6540f64..6bcb374 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t04.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t04.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t05.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t05.dart
index 6214de9..ebbe78e 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t05.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A28_t05.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t01.dart
index faf911f..b758abd 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t02.dart
index e71d71b..396a0fb 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t03.dart
index 812b231..9365931 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A29_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t01.dart
index 2cd87ae..83fd002 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t02.dart
index 2ab0f46..1dc75b4 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t03.dart
index adc100b..6dc8fd8 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t04.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t04.dart
index e166c03..2cc9c23 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t04.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t04.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t05.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t05.dart
index fa80dbe..ccbaf0a 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t05.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t05.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t06.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t06.dart
index 9792fe4..866e279 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t06.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A30_t06.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t01.dart
index c103546..044f258 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t02.dart
index 6f17afd..cd16041 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t03.dart
index 42ef58a..5845caa 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A31_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t01.dart
index d66983e..bdceec4 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t02.dart
index 941f64f..c8e0b49 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t03.dart
index 8ff95cf..5204e1d 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A32_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t01.dart
index 7496658..cbb8285 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t02.dart
index 8ff76a5..5e3d3b9 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t03.dart
index a2f1f45..3481067 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A33_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t01.dart
index 7f0d24f..65561bd 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t02.dart
index 2c86a27..191900e 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t02.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t03.dart
index 2fb6264..ec3607c 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A34_t03.dart
@@ -14,21 +14,35 @@
/// such could be added using extension methods.
///
/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
+/// ), }, ], ;, :, ,
///
-/// & | ^ + * % / ~/
+/// Then we include tokens which we predict will continue a generic instantiation:
///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t01.dart
index 531faa9..7dab1d3 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t02.dart
index 5aa25a3..49ccf06 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t03.dart
index 7fe927c..c327265 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A35_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t01.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t01.dart
index 50bc517..0fc100b 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t01.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t01.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t02.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t02.dart
index 2ee00e9..1bb2c40 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t02.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t02.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
diff --git a/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t03.dart b/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t03.dart
index 650946e..1eb30b8 100644
--- a/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t03.dart
+++ b/LanguageFeatures/Constructor-tear-offs/ambiguities_A36_t03.dart
@@ -2,33 +2,47 @@
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.
-/// @assertion This new syntax also introduces new ambiguities in the grammar,
+/// @assertion This new syntax also introduces new ambiguities in the grammar,
/// similar to the one we introduced with generic functions. Examples include:
-///
+///
/// f(a<b,c>(d)); // Existing ambiguity, resolved to a generic method call.
/// f(x.a<b,c>[d]); // f((x.a<b, c>)[d]) or f((x.a < b), (c > [d]))
/// f(x.a<b,c>-d); // f((x.a<b, c>)-d) or f((x.a < b), (c > -d]))
-/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
-/// an explicitly instantiated type literal named using a prefix, which is new.
-/// While neither type objects nor functions declare operator- or operator[],
+/// The x.a<b,c> can be an explicitly instantiated generic function tear-off or
+/// an explicitly instantiated type literal named using a prefix, which is new.
+/// While neither type objects nor functions declare operator- or operator[],
/// such could be added using extension methods.
-///
-/// We will disambiguate such situations heuristically based on the token
-/// following the >. In the existing ambiguity we treat ( as a sign that it's a
-/// generic invocation. If the next character is one which cannot start a new
-/// expression (and thereby be the second operand of a > operator), the prior
-/// tokens is parsed as an explicit instantiation. If the token can start a new
-/// expression, then we make a choice depending on what we consider the most
-/// likely intention (that's specifically - and [ in the examples above).
-///
-/// The look-ahead tokens which force the prior tokens to be type arguments are:
-///
-/// ( ) ] } : ; , . ? == != .. ?. ?? ?..
-///
-/// & | ^ + * % / ~/
-///
-// Any other token following the ambiguous > will make the prior tokens be
-// parsed as comma separated < and > operator invocations.
+///
+/// We will disambiguate such situations heuristically based on the token
+/// following the > that matches the < we are ambiguous about. In the existing
+/// ambiguity we treat ( as a sign that the < starts a generic invocation. We
+/// extend the number of tokens which, when following a potential type argument
+/// list, makes us choose to parse the previous tokens as that type argument
+/// list.
+///
+/// There is a number of tokens which very consistently end an expression, and
+/// we include all those:
+///
+/// ), }, ], ;, :, ,
+///
+/// Then we include tokens which we predict will continue a generic instantiation:
+///
+/// ( . == !=
+///
+/// The first six are tokens which cannot possibly start an expression, and
+/// therefore cannot occur after a greater-than infix operator. The last four
+/// tokens can continue an expression, and of those only ( can also start an
+/// expression, and we already decided how to disambiguate that).
+///
+/// There are many other tokens which currently cannot continue an expression
+/// (and therefore cannot validly follow a type argument list) or which cannot
+/// start an expression (and therefore cannot validly follow a greater-than
+/// operator), but in the service of keeping our future options open, we choose
+/// a design that does not rely on those restrictions. For example we omit most
+/// infix operators from being "continuation tokens", even though they currently
+/// cannot start a new expression, and therefore cannot follow a > infix
+/// operator. This leaves us open to allowing some of those operators as prefix
+/// operators in the future, like we currently allow the - operator.
///
/// @description Checks that any other token following the ambiguous > will make
/// the prior tokens be parsed as comma separated < and > operator invocations.
