Inherent extensions

[ds84182]

When designing an API that includes usage of private fields that are exposed publicly in some form, it is generally undesirable to allow polymorphism on some members. Take the following example:

// Assume we're using some new nifty features for brevity purposes.
abstract base class Node<
  N extends Self,
  P extends Node<_, _, N>,
  C extends Node<N, _, _>
> {
  P? _parent;
  C? _firstChild;
  C? _lastChild;
  N? _previous;
  N? _next;

  Node.detached();

  void reparent(N parent) {
    // ... this implementation is VERY important
  }
}

A subtype can override reparent! That's not good, something like this should be statically dispatched.

The workaround today is to place it in a separate extension, but that doesn't play well with import '...' show Node;.

I propose that extension methods and bodies be allowed within classes:

abstract base class Node<...> {
  extension void reparent(N parent); // Like an extension on Node<...> but is always visible.
  extension on Node<Some, Specific, Types> {
    // Bodies are supported, with refinement typing. Just no extensions with names.
  }
}

For extension disambiguation, extension members require a cast: (node as Node).reparent(parent)

[eernstg]

Note similarity to #2510.

[ds84182]

When I originally read that bug I thought it was for default impls that were overridable. The only difference there is the extension bodies for refinement.

[lrhn]

I think what you really want here is a final member which cannot be overridden in subclasses extending the type.
(Something like #3141, but simpler.)
If you then also use base to ensure that all subclasses must extend the type, not implement, then the method should be safe from any fiddling.

Using extension members means using the type parameters of the extension, based on the static type the extension is invoked on, not the type variables of the class itself. A non-overridable instance member would not have that problem.