find a way to permit impls of CommonTypeWith where the LHS and RHS type overlap

[zygoloid]

Per the current design, CommonTypeWith has an impl of this form:

final impl [T:! Type] T as CommonTypeWith(T) where .Result = T {}

Given this final impl, it's unclear how to write a parameterized impl of CommonTypeWith for two parameterized types that overlap. For example:

// Error: would specialize the above `final impl`.
impl [U:! Type, T:! CommonTypeWith(U)] Vec(T) as CommonTypeWith(Vec(U)) where .Result = Vec(T.Result) {}

The error here is unnecessary: there's no actual coherence problem here because in the case where T == U, the computed Result is Vec(T).

It's not clear how to resolve this. Some options:

• Switch from final impl to a final associated constant.
• Provide some way for the author of this impl to say that it's prioritized below the final impl.
• Provide some way for the author of the final impl to say that it is considered more specialized than any other impl, rather than disallowing impls that overlap with it.
• Add support for type inequality constraints so that the new impl could exclude the T == U case.
• Allow a final impl to be specialized if the specialization is identical.

[josh11b]

• Switch from final impl to a final associated constant.

I don't think CommonTypeWith is a strong argument for this option, since the only reason final associated constants would help is that final associated constants would be likely to support "allow a final thing to be specialized if the specialization is identical."

• Provide some way for the author of this impl to say that it's prioritized below the final impl.
• Provide some way for the author of the final impl to say that it is considered more specialized than any other impl, rather than disallowing impls that overlap with it.

I think if we wanted to go in either of these two directions, I'd rather a final impl always be prioritized over other impls and give an error if that means some impl will never match. It seems like it would be better to have fewer options if we can get away with it, unless you have some use case when you would not want this behavior. The main counter argument is if you want to document in the source that an impl isn't going to apply in cases that you might otherwise expect it to.

• Add support for type inequality constraints so that the new impl could exclude the T == U case.

I'm not excited about this, since we currently don't have a way of proving that two types are not equal.

• Allow a final impl to be specialized if the specialization is identical.

I'd be fine with this option. It only resolves a relatively narrow set of cases similar to the CommonTypeWith situation, though, since we while we can compare associated constants to see if they are equal, I don't think we can expect to do that with functions.

[chandlerc]

• Allow a final impl to be specialized if the specialization is identical.

I'd be fine with this option. It only resolves a relatively narrow set of cases similar to the CommonTypeWith situation, though, since we while we can compare associated constants to see if they are equal, I don't think we can expect to do that with functions.

While I agree, this also specifically addresses the only downside to making the final impl be prioritized -- it restricts to the case where there is no need to document the exclusion.

What if we start here to see whether this ends up covering the cases where this is an issue? We can always revisit prioritizing the final in all cases if further use cases emerge.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time.
This issue is labeled inactive because the last activity was over 90 days ago.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time.
This issue is labeled inactive because the last activity was over 90 days ago.

[josh11b]

As far as I am aware, we would still like an answer to this question. An answer was proposed in #1077 (comment) but never accepted.

[chandlerc]

Yep, leads are happy with the resolution here: #1077 (comment)