While it's clear why an arbitrary class implementing operator == cannot be used as a compilation-time constant key, could TypeImpl be a special case? It uses a string _typeName which seems to be unique for each class (even when actual class names collide).

With -dev.59, the Dart Analyzer produces these errors:

Analyzing /usr/local/google/home/dgrove/tmp/dart2stable/32557.dart...
error • The constant map entry key expression type 'A' can't override the == operator at tmp/dart2stable/32557.dart:10:20 • const_map_key_expression_type_implements_equals
error • The constant map entry key expression type 'A' can't override the == operator at tmp/dart2stable/32557.dart:10:28 • const_map_key_expression_type_implements_equals
2 errors found.

@askeksa-google - I believe this issue doesn't require constant evaluation, but only requires checking the type of the keys in a const map literal context.

The Dart VM does not produce any error on the above test.

after some discussion at our dart2js meeting - I recognize that some const evaluation is needed, as a ternary expression yielding an Object as a LUB type would hide the issue.

Also if the switch case expression is a reference to a constant of static type dynamic, like const dynamic t = Object, do we need to evaluate the constant to catch all cases.

Since the requirement is for the class to not override Object.operator==, it should be sufficient to know the exact type of the constant value, without needing to know have the actual instance.

Conditions in constant expressions need to be completely evaluated to true or false in order to know which branch is used, so knowing the exact type may need some complete evaluation to happen.
Example:

const x = Bool.fromEnvironment("yadda") ? 1 : [1];
const m = {x: 42};

This program compiles and runs with -Dyadda=true, and it fails to compile without it.

There is code in the wild that 'overrides' Object.operator == with an abstract method.

This is used as a mechanism for suppressing warnings when hashCode has an override but it is desired to inherit Object.operator ==.
It it intended to break this code? I don't see the code is harmful.

We we don't want to break this kind of code, care needs to be taken to allow constants that implement operator == via Object.operator== with a shadowing abstract method.

One example of this pattern is Protobuf enums: https://github.com/dart-lang/protobuf/blob/master/lib/src/protobuf/protobuf_enum.dart#L51

Abstract method declarations are not relevant to this - the requirement is that the class does not have an implementation of operator== different from the one inherited from Object. Abstract methods do not add an implementation, so we do precisely want to allow any class that implements operator== via Object.operator==.

The spec for switch says:

It is a compile-time error if the class C has an implementation of
the operator == other than the one inherited from Object,
unless the expression evaluates to a string or an integer,
or the expression is a literal symbol or
an invocation of a constant constructor of class Symbol.

For constant map literals, the key expressions must be

constant expressions evaluating to values that are either int or String instances, created using a symbol literal or a const invocation of the Symbol constructor, or instances of classes that that do not override the == operator inherited from Object,

(The switch one needs to be tweaked to match the map one, so that any expression evaluating to a constant symbol created by a symbol literal or a constant invocation of Symbol works, not only literal expression - which basically just means to allow const variables bound to such values).

The spec is woefully silent on the classes used to implement literals (values not created by calling a constructor). For the record, the intended semantics wrt. this for constant literal values are:

• Null and bool do not override operator ==, neither do values created by list and map literals.
• double and Type do override operator ==.
• String, int and Symbol literals also override operator ==, but are allowed specially.
• constant functions ... probably do not override operator ==. They are canonicalized as constants.

(We make no guarantees that map and list literals are all instances of the same class, though, which matters for switch. It's an annoying restriction).

Circling back to the original bug:

• dart2js now has a workaround implemented that will check for operator== in switch cases.
• we intend to delete it once the CFE implements the same feature, but we'll need a hook to add an exception to the rule.

In dart2js types are not canonicalized, so our TypeImpl implements operator==. However, type literals are constants and we do canonicalize them correctly, so most users will not encounter issues using type literals in switch cases.

Because all other tools do allow Type in switch cases, the dart2js-team is inclined to omit the error in the case of TypeImpl. Instead we'll treat this as a bug: types should be canonicalized in dart2js. We have plans to fix that, but until we do, we will need a way to suppress the error when the CFE implements it.

The issue with using type literals in switch cases is that you cannot use identical for comparison.
Example:

main() {
  var type = (<T>() => (<X>() => X)<List<T>>())<dynamic>();  // generates List<dynamic> dynamically.
  print(type == List ? "List<dynamic>" : "Not List<dynamic>");
  switch (type) {
    case List: print("List<dynamic>"); break;
    default: print("Not List<dynamic>");
  }
  print(const {List: "List<dynamic>"}[type] ?? "Not List<dynamic>");
}

If you run this code in dartpad (some version of dart2js), it runs and prints:

List<dynamic>
Not List<dynamic>
List<dynamic>

That's unlikely to be what the user intends.
(The same issue applies to symbols, a new Symbol("foo") does not match case #foo, but it is equal to it).

We explicitly did not want types to be canonicalized since there can be arbitrarily many different type objects in a program's life-time. Canonicalization would require you to remember those, which is a memory leak waiting to happen.

@lrhn are you suggesting that switches on Type should always be a compile-time error? Or that switch statements should use ==?

Discussions are ongoing, it might be allowed. But the current specification prevents case clauses from using objects with a concrete == operator that overrides the one in Object, so it is currently an error (even for an identifier/typeName which is a constant expression of type Type). It seems to be an unenforced one, so we have usages out there.

PS: Switch statements are already specified to use == (search 'Matching of a case clause' in the spec), and this has been true at least since 59611b2, 2013-10-07.

This should be fixed by constant-update-2018, but I still see some test status file entries with this issue number so it needs verification. (Perhaps we do not catch the switch cases?)

Yeah, the switch checks are not implemented. These fall in the category of "subsequent checks" which will likely require some Kernel format changes to support fully.

This depends on CFE constant evaluation and doesn't block it (constant evaluation).

Some updates:

• dart2js has a new Type implementation for which == is Object.==.
• CFE seems to implement the error

@johnniwinther can you confirm that the CFE checks are complete?

These checks have all been implemented.