Allow extensions to satisfy interfaces for the extended type

[leslmosnk2]

Motivation

It would be useful if an extension could declare that it implements an interface for the type it extends.

For example:

abstract interface class Lerpable<T> {
  T lerp(T other, double t);
}

extension DoubleLerpable on double implements Lerpable<double> {
  @override
  double lerp(double other, double t) {
    return this + (other - this) * t;
  }
}

This would allow existing types, especially SDK types such as double, to participate in generic APIs that rely on interface constraints without requiring wrapper types.

For example:

class Animation<T extends Lerpable<T>> {
  // ...
}

Animation<double>(); // Would be valid

Today, this is impossible because built-in types cannot be modified to implement additional interfaces, and extensions do not contribute to a type's implemented interfaces.

Current workarounds

The available alternatives all have drawbacks:

• Wrapper types (LerpDouble) introduce additional types solely to satisfy an interface.
• Strategy objects (Lerper<T>) work well but require passing an additional object everywhere, even when the behavior naturally belongs to the type.
• Runtime type checks sacrifice static type safety.

Proposed feature

Allow an extension to declare that it implements one or more interfaces for the extended type.

For example:

extension DoubleLerpable on double implements Lerpable<double> {
  @override
  double lerp(double other, double t) => ...;
}

or another syntax with equivalent semantics.

The compiler would then consider double to satisfy Lerpable<double> wherever the extension is in scope.

Design considerations

A few questions would need to be addressed:

• How are conflicts handled if multiple extensions implement the same interface for the same type?
• Should interface implementation only apply when the extension is imported and in scope?
• Should there be restrictions similar to extension method resolution to ensure deterministic behavior?

One possible approach is to require that at most one applicable extension provides a given interface implementation in any library, producing a compile-time error otherwise.

Benefits

This would enable retroactive interface conformance for existing types, making generic APIs significantly more expressive while avoiding unnecessary wrapper types.

It would be particularly useful for:

• Numeric abstractions (double, int, etc.)
• SDK types that cannot be modified
• Third-party types
• Generic math, animation, interpolation, serialization, and formatting APIs

Other languages provide similar capabilities through mechanisms such as protocol conformances (Swift) or traits (Rust, with coherence rules). A Dart feature in this area would make it much easier to write generic libraries without requiring ownership of the participating types.

[lrhn]

This is Rust traits. If it's not, it won't work.

An object can't satisfy an interface only when an extension is in scope, because satisfying an interface means being a valid argument to a function expecting that interface, and that function will call interface methods and will almost certainly not have the extension in scope. (List.sort only works with real Comparables!)

It's very much not static extension methods, so using extension for the feature would be misleading. It's a completely different feature.

(Not saying it's a bad feature. It would be awesome. But it'd also have deep ramifications for the runtime representation of objects and pointers, whereas extensions is just a nice syntactic sugar for calling static functions.)

[leslmosnk2]

Thanks, that makes sense. I was thinking about the problem from the perspective of extensions because that's where the implementation would naturally live, but I see now that what I'm really asking for is retroactive interface implementation, not "better extensions."

My goal is to be able to express something like:

abstract interface class Lerpable<T> {
  T lerp(T other, double t);
}

class Animation<T extends Lerpable<T>> { ... }

Animation<double>(); // because `double` has a retroactive conformance

without introducing wrapper types or strategy objects.

I understand why this can't simply depend on an extension being in scope, since interface conformance has to be understood by both the caller and callee and affects dispatch and generic constraints.

So perhaps this issue is really a request for a Rust trait / Swift protocol conformance-style feature, regardless of what the eventual syntax would look like.

Thanks for the clarification!

[lrhn]

You really can't do this without wrapper types or strategy objects, you can just hide those in the language instead of having to write them yourself. Or at least not without having other problems.

The smallest thing that can maybe work, is to declare that some class implements an interface that its existing members already satisfy.
That could work globally, you have abstract interface class Vector<T> { int get length, T operator[](int index);} and you declare that String and List are both Vectors, and in that program they are.
It has problems with scaling (you can't do modular compilation), and conflicts (you say TypedDataList implements Vector<num>, I say Uint8List implements Vector<int>, together they conflict), but it doesn't rise to the level of two parties adding conflicting members to the same type.

After that, the jump is really to traits or something similar, where the language keeps objects and their implementation of an interface as separate aspects of the same value.
Or as Rust does it: Fat pointers. In Dart, every pointer is an interface pointer (unless the class is declared final, and then not implemented inside that library), so they'd all be fat pointers.

A fat pointer is really, depending on perspective,

• The object and a strategy object for the interface.
• A wrapper object with a V-table that has been inlined.

It's still there, it's just handled inside the language - at the cost of every pointer now being of that kind.