p0990.md

Generics details 8: interface default and final members

Pull request

Table of contents

• Problem
• Background
• Proposal
• Rationale based on Carbon's goals
• Alternatives considered
  • Defaulting to less specialized impls
  • Allow default implementations of required interfaces
  • Don't support final

Problem

Rust has found that allowing interfaces to define default values for its associated entities is valuable:

• Helps with evolution by reducing the changes needed to add new members to an interface.
• Reduces boilerplate when some value is more common than others.
• Addresses the gap between the minimum necessary for a type to provide the desired functionality of an interface and the breadth of API that user's desire.

Carbon would benefit in the same ways.

Background

Rust supports specifying defaults for methods, interface parameters, and associated constants.

Proposal

This proposal defines both how defaults for interface members are specified in Carbon code as well as final interface members in the generics details design doc.

Rationale based on Carbon's goals

This proposal advances these goals of Carbon:

• Performance-critical software: Final members of interfaces can avoid some dynamic dispatch overhead.
• Software and language evolution: Defaults simplify adding new members to an interface without having to simultaneously update all impls of that interface.
• Code that is easy to read, understand, and write: Defaults both reduce boilerplate, making code easier to read and write. Marking interface members as final makes the code more predictable to users of that member.

Alternatives considered

Defaulting to less specialized impls

Rust has observed (1, 2) that interface defaults could be generalized into a feature for reusing definitions between impls. This would involve allowing more specific implementations to be incomplete and reuse more general implementations for anything unspecified.

However, they also observed:

[To be sound,] if an impl A wants to reuse some items from impl B, then impl A must apply to a subset of impl B's types. ... This implies we will have to separate the concept of "when you can reuse" (which requires subset of types) from "when you can override" (which can be more general).

This is a source of complexity that we don't want in Carbon. If we do eventually support inheritance of implementation between impls in Carbon, it will do this by explicitly identifying the impl being reused instead of having it be determined by their specialization relationship.

Allow default implementations of required interfaces

Here are the reasons we considered for not allowing interfaces to provide default implementations of interfaces they require:

• This feature would lead to incoherence unless types implementing TotalOrder also must explicitly implement PartialOrder, possibly with an empty definition. The problem arises since querying whether PartialOrder is implemented for a type does not require that an implementation of TotalOrder be visible.
• It would be unclear how to resolve the ambiguity of which default to use when two different interfaces provide different defaults for a common interface requirement.
• It would be ambiguous whether the required interface should be external or internal unless PartialOrder is implemented explicitly.
• There would be a lot of overlap between default impls and blanket impls. Eliminating default impls keeps the language smaller and simpler.

The rules for blanket impls already provide resolution of the questions about coherence and priority and make it clear that the provided definition of the required interface will be external.

Don't support final

There are a few reasons to support final on associated entities in the interface:

• Clarity of intent when default methods are just to provide an expanded API for the convenience of callers, reducing the uncertainty about what code is called.
• Matches the functionality available to base classes in C++, namely non-virtual functions.
• Could reduce the amount of dynamic dispatch needed when using an interface in a DynPtr.

The main counter-argument is that you could achieve something similar using a final impl:

interface I {
  fn F();
  final fn CallF() { F(); }
}

could be replaced by:

interface IImpl {
  fn F();
}
interface I {
  extends IImpl;
  fn CallF();
}
final impl (T:! IImpl) as I {
  fn CallF() { F(); }
}

This is both verbose and a bit awkward to use since you would need to impl as IImpl but use I in constraints.