FIDL language Tuning Proposals (FTP)

Note: Documents are sorted by date reviewed.

Accepted proposals

FTP-0012018-07-172018-08-01FTP process
FTP-0022018-07-172018-08-03Type aliases with “using” keyword
FTP-0092018-07-312018-08-20Documentation comments
FTP-0122018-08-302018-09-11Empty structs
FTP-0032018-07-172018-09-27Clarification: Default Values for Struct Members
FTP-0132018-09-072018-10-11Introduce a [Deprecated] Attribute
FTP-0152018-09-202018-10-11Extensible Unions
FTP-0212018-10-312018-11-01Soft Transitions for Methods Add / Remove
FTP-0202018-10-262018-11-29Interface Ordinal Hashing
FTP-0142018-09-182018-12-06Error Handling
FTP-0232018-12-102019-01-09Compositional Model for Protocols
FTP-0062018-07-202019-01-14Programmer Advisory Explicit Defaults
FTP-0252019-01-092019-01-24Bit Flags — Just a Little Bit
FTP-0302019-01-302019-01-30FIDL is little endian
FTP-0272019-01-192019-02-04You only pay for what you use
FTP-0322019-02-062019-02-21Efficient Envelopes: Turning Envelopes into Postcards
FTP-0292019-02-142019-02-28Increasing Method Ordinals
FTP-0332019-02-072019-03-07Handling of Unknown Fields & Strictness
FTP-0042018-07-192019-03-14Safer Structs for C++
FTP-0372019-03-072019-03-14Transactional Message Header v3
FTP-0242019-04-022019-04-11Mandatory Source Compatibility
FTP-0412019-04-082019-04-23Support for Unifying Services and Devices
FTP-0432019-05-062019-05-30Documentation Comment Format — Mark me up, mark me down
FTP-0482019-08-252019-09-26Explicit Union Ordinals
FTP-0282019-04-012019-12-12Handle Rights – The Right Stuff
FTP-0522020-01-072020-01-23Type Aliasing and New Types
FTP-0542019-11-212019-12-12Parameter Attributes — A Chance to Write Self Documenting APIs
FTP-0492019-11-202019-12-19FIDL Tuning Process Evolution
FTP-0572020-01-162020-01-23Default No Handles
FTP-0592020-03-162020-03-19Reserved Bits in Vector/String/Array Count Fields
FTP-0402019-04-072020-05-14Identifier Uniqueness — SnowFlake vs SNOW_FLAKE

Rejected proposals

FTP-0052018-07-192018-09-11Method Impossible
FTP-0102018-07-312018-10-04[OrdinalRange], where the deer and the antelope roam
FTP-0162018-09-272018-10-25No Optional Strings or Vectors
FTP-0262019-01-192019-02-04Envelopes Everywhere
FTP-0352019-02-28withdrawnAutomatic Flow Tracing
FTP-0362019-03-072019-03-14Update to Struct Declarations
FTP-0422019-04-012019-04-01Non Nullable Types — Poisson d'Avril
FTP-0452018-12-262019-05-29Zero-Size Empty Structs: ∞% more efficient


The FIDL Tuning Proposal (FTP) process is designed to provide a uniform and recorded path for making changes to the FIDL language, bindings, and tools.

Criteria for requiring an FTP

A change MUST go through the FTP process when either:

  1. The solution space is large, i.e. the change is one of many possibly good other solutions and there is a difficult design tradeoff to make;

  2. The change has a large impact, i.e. The change modifies the behavior of FIDL in a substantial way such that it may introduce risk to many-or-all users of FIDL;

  3. The change has a large scope, i.e. The change touches enough pieces of FIDL such that careful attention is required to determine whether it may or may not have a large impact.

For instance, changes to the following areas will likely require an FTP:

  • FIDL governance
  • Design principles
  • Language grammar
  • Type system
  • Protocol semantics
  • Wire format
  • Bindings specification

Additional details are provided in FTP-049: FIDL Tuning Process Evolution.


An FTP (FIDL Tuning Proposal) goes through several stages. These stages correspond to the Status: field of the heading of the template.

NB: The template is currently Google-internal.


One or more people get excited about a change! They make a copy of the tuning template, and start writing and designing. The proposal should address each of the section headings in the template, even if it is only to say “Not Applicable”.

At this stage they may start soliciting feedback on the draft from impacted parties.


At this stage, the FTP is formally circulated for commentary to the Fuchsia engineering organization. The authors of the proposal should solicit feedback from those especially likely to be impacted by the proposal.

For now, proposals should be left open for comment for at least one week, subject to reviewer discretion. It may be reasonable to be shorter for less controversial FTPs, and longer to wait for feedback from a particular person or group to come in.

Anyone may make a blocking comment on an FTP. Blocking comments do not prevent a particular accept-or-reject outcome from the review process, but reviewers are required to acknowledge the feedback given in the comment as part of the final FTP.


Withdrawn FTPs are valuable records of engineering ideation. When an author withdraws their FTP, the withdrawal rationale must be added to the FTP. The FTP will then be copied to the public record of all FTPs for posterity.

The withdrawal rationale is written by the FTP author, possibly in conjunction with members of the Fuchsia FIDL team.

The rationale should be actionable in the following two ways.

What did the author learn through the FTP process which would have led them to propose an alternative design?

What are alternatives to the withdrawn FTP which are promising?


At this point the FTP, along with all outstanding commentary, is reviewed.

The proposal is reviewed by members of the Fuchsia FIDL team (defined by an OWNERS file in the fuchsia.git repository [Location TBD], and unofficially known as luthiers), and anyone they see fit to include or to delegate to in the process. For example, they may include a particular language expert when making a decision about that language's bindings. If necessary, controversial decisions can be escalated like any other technical decision in Fuchsia.

Most commonly, the review is conducted during one or multiple in-person meetings ‘The FTP review meeting’. The review can also occur using asynchronous communication if appropriate).

The FTP review meeting starts by the author(s) presenting their design. The facilitator will then work through the comments in the FTP, asking people who left comments in the doc to present their feedback.

The facilitator and presenter are ideally different people. The goal of the facilitator is to ensure that all aspects of the design are addressed, and to keep the meeting flowing. Ideally, the facilitator does not have a particular stake in the outcome to avoid the perception of bias, and the presenter implicitly has a stake in the design they're presenting.

We don't necessarily need to come to closure on every piece of feedback during the meeting or discuss every last comment (e.g., if there are a large number of comments or several comments are getting at the same underlying issue). Instead, the facilitator should optimize for giving the presenter a broad range of feedback rather than driving each point of debate to a conclusion. Pending open questions may be resolved in further review sessions, or during Decision making.

Decision making

Within five (5) business days, members of the Fuchsia FIDL team (defined by //docs/concepts/fidl/ftp/OWNERS file), with the ultimate decision maker being the Fuchsia FIDL team lead, decide on the outcome of the review.

The decision can ultimately have three outcomes.

First, there may be outstanding questions or feedback required to make a decision. In this case the FTP is moved back to the Comment stage.

Second, the proposal may be Rejected, with reviewers providing a rationale as to why.

Third, it may be Accepted.

Typically, the venue for decision making will take the form of a meeting. It may also be an email thread, or happen during a review meeting.


Rejected FTPs are valuable records of engineering decisions. When rejected, the rationale for rejected should be added to the FTP. The FTP will then be copied to the public record of all FTPs for posterity.

The given rationale should be actionable in the following two senses.

First, what would have to change about the world to have accepted this proposal?

Second, the rationale should address any blocking comments raised during the Comment period.


Accepted FTPs will also have a rationale section appended to them after review, and will receive a tracking bug.

The same constraints apply to the acceptance rationale as the rejection rationale. In particular, any blocking comments need to be addressed.

Then it's off to the races to implement the change.


At this stage, the proposal is landed. All the code has been changed. The tutorial has been updated. The bug is marked done. FIDL is in a more perfect tuning.

The final step of the process is landing a markdown-ified version of the FTP into the Fuchsia tree. This applies whether or not the proposal was accepted, as being able to point at already considered but rejected proposal is a substantial part of the value of this process.