| RFC-0063: OrdinalRange | |
|---|---|
| Status | Rejected |
| Areas |
|
| Description | Add an optional [OrdinalRange] attribute to interfaces. If present, ordinals defined by the interface must fall within the declared range. |
| Authors | |
| Date submitted (year-month-day) | 2018-07-31 |
| Date reviewed (year-month-day) | 2018-10-04 |
Rejection rationale
We've had a number of discussions about how we want interfaces to evolve,
and be inheritable.
For instance, introducing ordinals on interfaces, which along with method
ordinals would uniquely determine a method being invoked.
As such, we're rejecting the [OrdinalRange] proposal.
However, we recognize the need to control inheritance, since the pattern we have today can be problematic: unbeknownst to a library author, defined interfaces could be inherited, such that introducing new methods would irreparably break inheritors.
As a result, we're going to introduce, on a temporary basis (until we have
a better solution), the requirement that any interface needing to be
inherited must be annotated with [FragileBase].
Relation to other RFCs
This RFC was superseded by:
Summary
Add an optional [OrdinalRange] attribute to interfaces.
If present, ordinals defined by the interface must fall within the
declared range.
An interface cannot be inherited from unless it declares an
[OrdinalRange] and the subinterface cannot use any of the ordinals
in the ranges claimed by its superinterfaces.
Motivation
In FIDL, an interface can inherit from another interface. The FIDL compiler prevents the two interfaces from assigning different semantics to the same ordinal, but there is no mechanism for the super interface to reserve ordinals for future use. As currently defined, adding an ordinal to any interface could potentially break other (unseen) interfaces that inherit from that interface and assign that ordinal.
The FIDL style rubric suggests working around this
issue by documented reserved ordinal ranges in comments (at least for
interfaces that expect to be inherited from).
This FTP proposes putting those reservations in an [OrdinalRange] attribute
on the interface instead.
Design
This change affects only the FIDL source language. It has no effect on the wire format or any of the generated bindings. The implementation can take place entirely in the FIDL frontend compiler.
- Introduce an optional
[OrdinalRange]attribute for interfaces. When present, the value of this attribute must match the following grammar:NUMERIC-LITERAL, "-",NUMERIC-LITERAL
- When present, all the ordinals defined by the interface must be in the specified range (inclusive).
- An interface cannot inherit from another interface unless the second
interface has the
[OrdinalRange]attribute. - All the super interfaces of an interface must have
[OrdinalRange]attributes that define disjoint ranges. - An interface cannot define an ordinal that belongs to the
[OrdinalRange]of any of its super interfaces.
If any of these invariants is violated, the FIDL frontend must generate an error.
Replace the passage in the FIDL style rubric that
recommends using comments for this purpose with a passage that requires
using the [OrdinalRange] attribute for this purpose.
Documentation and examples
This feature will be documented (and an example provided) in the FIDL style rubric.
Backwards compatibility
This feature is not backwards compatible because existing uses of
inheritance will fail to compile until we add [OrdinalRange] attributes
to the superinterfaces.
However, we use inheritance rarely and updating all the superinterfaces
will be easy.
Performance
This proposal has no impact on performance.
Security
This proposal has no impact on security.
Testing
The fuchsia.io library will provide a positive compilation test.
Drawbacks, alternatives, and unknowns
The main drawback of implementing this proposal is extra ceremony for creating inheritance relationships between interfaces. However, that ceremony already exists in the form of comments about reserved ordinal ranges.
An alternative is to continue to use comments to informally reserve ordinal ranges.
Prior art and references
We assume other similar systems do something similar, but haven't researched it.