Allow extension types to declare abstract instance members.

[lrhn]

I have two use-cases for allowing an extension type to declare an abstract member.

I would encourage us to have at least the first feature in the initial feature release, even if only for documentation purposes.

Existing members

That is, an abstract member corresponding to a member that would still be in the interface of the extension type without that declaration, usually from an implements clause.

Attaching docs and other annotations

Those abstract declarations would not introduce a new member implementation, but can attach new doc-comments, maybe even annotations, to the member in the interface of the extension method.

Such "comment-declarations" should also be allowed for members that an extension type cannot otherwise declare (the "members of Object"), because it may be relevant to describe how == works on the extension type, in terms of the extension type, instead of inheriting the documentation, potentially from Object, or from a structural type with no documenteation.
Example:

extension type const Version._(({int major, int minor}) _) {
  const Version(int major, int minor) : this._((major: major, minor: minor));
  int get major => _.major;
  int get minor => _.minor;
  bool operator <(Version other) => major < other.major || major == other.major && minor < other.minor;
  /// Two versions are equal if they have equal [major] and [minor] version numbers.
  bool operator==(Object other);
}

This Doc-comment should show up in the generated docs for the class, and if hovering over version == in an IDE.

Restricting API

The above use only requires a declaration with the same signature.

An extension type can also, safely and soundly, define a more restricted member signature.
For example, the above could be:

  bool operator==(Version otherVersion);

This can be allowed if the actual method which will be called is a valid override of the signature of the abstract declaration.

Another, mostly hypothetical, use-case for that could be:

extension SaferFuture<T>(Future<T> _) implements Future<T> {
  Future<T> catchError(FutureOr<T> Function(Object, StackTrace) onError, {bool Function(Object)? test});
}

If I wrap the Futures I work with in that, my catchError is now more type-safe. (It has other issues, but that's the idea.)

It's likely hard to allow a declaration to carry comments, and not allow a declaration with a different signature, even if it's a mutual subtype.

The point of the abstract declaration is to only affect the interface signature and metadata of the member, not the implementation, the same way abstract member declarations can be used in classes.
As long as there is a valid implementation for the signature, that's fine.

Forwarding declarations

A use of an abstract member declaration which does not correspond to an existing implemented member of the extension type, could be to introduce a member which forwards to a member of the representation type.

That can be used to introduce individual members of a super-interface of the representation type, instead of implementing the entire interface.
Example:

extension type Sequence<T>(List<T> _) implements Iterable<T> {
  // Efficiently accesses the [index]th element of the sequence.
  T operator[](int index);
}

Here the extension type wants to expose an unmodifiable API, as an Iterabel, but also expose some non-modifying List members. Using this declaration, instead of an explicit forwarding member:

  @redeclare
  T operator[](int index) => _[index];

avoids some mostly unnecessary code, and ensures that the compiler can definitely perform invocations of the extension member directly as invocations on the underlying representation type.

Summary:

• Allow abstract instance member declarations in extension types.
• The abstract member must correspond to (have same name as):
  • The inherited member from a supertype (from an implements clause or directly from Object?),
    which the extension type would otherwise get as a member.
  • A member of the representation type, if there is no corresponding inherited member.
• In either case, the abstract member signature defines the static signature of that member in its extension type's interface.
  • The interface member signature can also carry comments and metadata.
  • Does not add any implementation. No forwarders or implict declarations.
  • The member is an extension type member if the corresponding method is, and an interface member
    if the corresponding member is.
• If invoked, the invocation happens directly on the corresponding supertype or representation-type member.
  • Tearing off the member also directly tears off the corresponding member.
  • The signature of the corresponding member must be a valid override of the abstract member's signature.
    (The implementation is a valid implementation of the signature it's accessed at, which ensures soundness.)
• We should consider whether modifying an inherited member should be marked as @redeclare or even @override.
  The latter is probably more correct, but could also be surprising or confusing when our story is that extension
  members do not override.

Extension types cannot have purely abstract members, since an extension type cannot be abstract itself.
An extension type interface's members are either extension types, which are statically resolved and therefore cannot be abstract, ot the members are class interface members, which delegate to the corresponding member of the representation object, which must exist for any concrete object.

That means that the abstract declaration syntax is free to use for overriding the signature and adding documentation (like we do for classes already), and for selectively forwarding to specific members of the representation type, instead of all of them using implements.

There is a risk combining both of these features, in that writing an abstract member that is only intended to document, will unintentionally still expose a member after its interface was removed from the implements clause.
If we encourage a @redeclare or @override on the first use, then switching between the two uses won't be silent.

[Zekfad]

This feature would be appreciated. Another use case is to make an extension type interface:

extension type Interface(Object _) {
  /// Some method
  void method();
}


extension type Wrapper(int a) implements Interface {
  // required to add [method] implementation
}

[lrhn]

@Zekfad that would not work. Extension types do not have interfaces or virtual methods. They cannot have an abstract method with no implementation.
That's why this proposal would require the representation type to have an implementation of the abstract declaration, so there is an implementation to fall back on.

[Zekfad]

That is unfortunate, is there already existing feature request for extension types and interfaces?

[lrhn]

Classes already allow interfaces and virtual methods. Replace extension type with class in your example, and it works today.

The value proposition for extension types is that they are zero runtime space overhead wrappers,
a feature which differ from classes in precisely the ways that makes virtual or interface-based member lookup impossible.
Adding that to extension types would make them no longer be extension types.

So, no.

[Zekfad]

I understand what you're talking about, but I don't mean virtual methods or inheritance chains. I'm talking about compile-time only interface, which would make it possible for 2 extensions to share some "interface", compiler will always know which methods where implemented, like it does with extension type now. Such a thing will only make it easer to group extension types by interface, and will report compile errors if some "implementer" missing any required members.

For example, I'm currently trying to make an Int abstraction (like fixnum, but with extension types and conditional import, so VM would use an actual integers and JS would use Record with internal data). To make conditional import work properly I must ensure same interface between 2 extension types. In a normal class that's easily done via interface in stub code and using that interface, with Extension types I must manually ensure that 2 entities are aligned.

[lrhn]

Ensuring that two independent types have "the same" API is not easy.

It's true that with classes and interfaces, they can implement the same interface, but that gets tricky if the type needs to refer to itself (will MyNum + MyNum return MyNum, and what does that really mean if there are two different MyNum classes).

For extension types, we can't add a super-interface, because that implies a supertype, which you can cast to, and then it doesn't have any member implementation.
Or I guess that's possible, it really will have no members to call, so the only use is to enforce some shared API on subtypes. Except that extension types can anyway completely ignore their superclass and redeclare names with no relation to what it shadows. So we'd have to introduce a new concept of a requirement on an extension type, which forces it to have specific signatures in its API.
I don't think that's going to be worth the effort, when you still can't abstract over the API implementations.

If you have two different implementations, just be sure to run your tests on both. It's the only way to be sure.

[clragon]

it feels like a somewhat missed opportunity to be unable to have extension types implement an interface.

Imagine I have a type A and a type B. they are not the same interface at all.
However, type A could with some effort act like type B.
Usually, this would be done via a Wrapper class that implements B and contains A.

If I recall correctly, extension types were essentially created to make Wrapper classes easier.
However, this type of Wrapper as a converter is not possible with the current way extension types work, since extension types have no concept of "implementing" interfaces (rather, implements just means forwarding from their representation type).

If extension types were allowed to implement interfaces in the same way classes can, we could realize the wrapper as converter type of usecase which I believe would be very handy.

e.g.

class A {
  A(this.value);

  int value;
}

abstract class B {
  String get value;
}

extension type X(A a) implements B {
  @override
  String get value => a.value.toString();
}

I suppose an argument can be made that we should instead just do a real conversion.

[jakemac53]

I suppose an argument can be made that we should instead just do a real conversion.

Exactly this. You have to pay the cost of a wrapper to get virtual dispatch. The extension type only gives static dispatch, which wouldn't work for passing it to another part of the program with just interface type. It would try to do virtual dispatch on that thing which wouldn't work (it would just be the representation object). So, a compiler would have to create a wrapper object or something to support this, which defeats the purpose :).