Open sgrekhov opened 9 months ago
I'd say that's at least an implementation bug.
The intended behavior is that you can wrote switch (e1) { case == e2: ...}
whenever you can write e1 == e2
, and we should make every case work like that.
You can add print(b == True);
and see that it works, so case == True:
should work too.
The context type of == e
with mached value type M
should be T?
, where T
is the parameter type of M.operator==
.
That's satisfied here.
The runtime behavior with matched value m
is evaluate e
to value v
. If v
is null
and m
is not null, fail.
If v
is null and m
is null, succeed.
Otherwise invoke m.==(v as T)
, where the as T
is definitely a no-op when v
has type T?
and is not null
.
That is, the == True
only needs True
to have type Object?
. It doesn't actually need NON_NULL(BoolET
) to be assignable to Object
. It does not need to promote the type of the ==
operand before passing it to b.operator==
.
Checked the spec. Type checking relational patterns include (C
is the type of the constant, A
is the type of the operator's parameter):
- If op is
==
or!=
then a compile-time error occurs ifC
is not assignable toA?
. Otherwise op is<
,<=
,>=
, or>
, and a compile-time error occurs ifC
is not assignable toA
.
so the spec is correct, and the implementations are wrong.
Does seem to only be visible related to extension types that are not non-nullable.
(I do notice it says assignable to, which is tricky, because it implies coercions, which may not be constant. We should probably say, somehow, that any implied coercions must be constant. At least implementations handle it correctly.)
We have the following:
There is no this issue if an extension type explicitly implements
Object
. Is the above expected?cc @eernstg @lrhn