can you adapt an abstract class?

[zygoloid]

Summary of issue:

Noticed while reviewing #4381: we are disallowing adapting an abstract class type. It's not clear whether this should be allowed or not; I don't think we've considered this question.

Details:

On the one hand, requiring the adapted type in an adapter to be non-abstract is a little simpler. On the other hand, it seems to be a restriction we don't need: we could allow this and the result would be that the adapter itself is also an abstract class.

Any other information that you want to share?

If we allow it, we open up a larger question: when deriving from an adapter, can you override virtual functions from the adapted class? Is some special syntax needed in order to do so, or does impl fn ... look through the adapter to the adapted type? Because an adapter cannot have virtual functions of its own, there's nowhere else that impl fn could look for the function to override, but looking through the adapter might be piercing an abstraction and we might not want to do that silently.

[josh11b]

My inclination here is to say yes: we have seen a lot of use cases for the adapter feature, and some of those use cases (for example, using adapters to implement member access) probably should not be restricted. While it made sense to start conservatively, I think it is more valuable to avoid unnecessary restrictions that would make the feature less orthogonal.

Regarding implementing a virtual function: agreed it can't be done in the adapter itself, but it should be allowed in classes derived from the adapter. I don't think special syntax should be required. However if it is not an extending adapter, we might want to require that qualifying the name of the virtual method, since otherwise it wouldn't be found by name lookup.