We propose declaring a new attribute that allows code to build regardless of whether the method is implemented or not.
Since moving the Fuchsia tree to the flower model of global integration hard breaking changes have become ... hard. This derives from the fact that to implement a FIDL interface in a binding the developer must implement exactly the set of methods that were defined in the FIDL interface in their concrete implementation. This means if a method is added to or removed from an interface in one petal then global integration will fail.
We should declare a new attribute
[Transitional="description"] that instructs bindings to generate code that will successfully build whether the method is or is not implemented.
Calling a transitional method is implementation defined — it may work as documented, may never complete or even may cause the caller or callee to crash. It must not interfere with the functioning of other methods and it must be possible to implement the method. The FIDL frontend compiler wouldn't need to change at all, only the language bindings.
Once we have an approach to long-term evolution we will remove this functionality from FIDL.
See Drawbacks, below.
No performance impact when not used. Potential additional indirection by using dynamic dispatch for
[Transitional] methods, instead of a more direct calling strategy.
No impact, transitional methods fail fast.
Code generation on before/during/after libraries to simulate adding or removing methods and events using
[Transitional] attribute, and ensuring compilation succeeds.
This does not offer a way forward for long-term evolution of FIDL interfaces. It does not provide for renaming methods or changing their signature, though it could be used as part of a multi-stage process for that. It does not solve the problem of adding variants to unions.