Should impl lookup distinguish and/or fallback on `const` and/or `MaybeUnformed`?

[jonmeow]

Regarding generic type structure here, it gives several rules, particularly:

• Pointer types T* are replaced with Ptr(T).

Right now, MaybeUnformed is implemented as a class, so is part of the type structure. Although the design doesn't current specify, I'm going to assume here that const and partial should be part of the type structure.

Should there be any impl lookup fallbacks in this space? In particular:

1. Can impl const MyType as Comparable be used for a non-const MyType?
2. Can impl MaybeUnformed(MyType) as Comparable be used for a formed MyType?
3. If the answer is yes to both of the above, does that extend to MaybeUnformed(const MyType) and/or const MaybeUnformed(MyType)?

[jonmeow]

My rough expectation is that the answer here is probably "yes" to each of these questions, but am interested in getting that confirmed/rebutted.

[jonmeow]

Thinking further, should there be a MyType -> partial MyType as well? I was initially thinking maybe not (thus its absence from the original question), but actually it's probably always a more limited form of MyType in a similar way as to const.

For some added context, zygoloid and I had discussed having destruction of T would work, and that might be to call fn destroy[addr self: Self*]() then fn destroy[addr self: partial Self]() (in sequence, if present). So that's comparable but not the same. Class destruction wouldn't be affected much by an impl fallback because it could easily generate two separate impls for precision.

One possible choice here is that if someone writes impl MaybeUnformed(const partial MyType) as Comparable, that should provide a fallback for less-restricted combinations of each of those (with errors for ambiguous fallback).