Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
F
Fuchsia OS
Manage
Activity
Members
Labels
Plan
Issues
0
Issue boards
Milestones
Wiki
Code
Merge requests
0
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Hacrwang
Fuchsia OS
Commits
710c1934
Commit
710c1934
authored
6 years ago
by
Rob Krten
Committed by
CQ bot account: commit-bot@chromium.org
6 years ago
Browse files
Options
Downloads
Patches
Plain Diff
[fidl][ftp] Import of FTP-006 Programmer Advisory into markdown
Change-Id: I98d3403a8e1b0d1e9ae7b8a23d927838dba5f51b
parent
7a719f17
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
docs/development/languages/fidl/reference/ftp/ftp-006.md
+124
-0
124 additions, 0 deletions
docs/development/languages/fidl/reference/ftp/ftp-006.md
with
124 additions
and
0 deletions
docs/development/languages/fidl/reference/ftp/ftp-006.md
0 → 100644
+
124
−
0
View file @
710c1934
# FIDL Tuning Proposal 006
Programmer Advisory Explicit Defaults
Field | Value
----------|--------------------------
Status | Accepted
Authors | ianloic@google.com
Submitted | 2018-07-20
Reviewed | 2019-01-14
[TOC]
# Summary
The FIDL specification doesn't state whether primitive and enum struct
fields have default values.
This tuning proposes that we document explicitly that they do not.
# Motivation
Requiring initialization is challenging in some languages and impossible
in others.
This proposal leaves the door open to the lowest common denominator but
provides a policy for higher-level languages to follow.
The lack of clarity about default values in structs for some types results
in some disagreement.
Language bindings are inconsistent in their handling of implicit and explicit
defaults.
It's clear that nullable types default to null and arrays and vectors default
to empty but not others.
The C++ bindings default primitive types to false, 0 or 0.0 but the Dart
bindings require values to be specified when a struct is constructed if no
default is supplied in the FIDL definition.
Often zero values are great defaults but they should be explicitly declared.
For example, if a
`uint32_t`
is representing an FTP number then 0
isn't a valid value but FIDL has no way to express that a caller should
specify a number.
# Design
This is primarily a documentation clarification.
It merely clarifies the semantics expressed in FIDL interfaces.
It opens up opportunities for bindings improvements but does not mandate them.
The
[
FIDL language specification
][
fidl-language
]
should include the following
information, possibly in a different form:
> Primitive and enum fields in structs that don't have defaults values
> declared in the FIDL file SHOULD be specified when instantiated in
> bindings.
> Bindings authors MAY respect default values, if the host language makes
> that possible, and if that behavior is common and expected by programmers.
> For instance, in Dart or C++ it is common to have default values.
> In Go however, structs are initialized by default, and the idiomatic pattern
> to provide standard initialization is to offer a NewMyStruct() function.
> In C, no initialization is expected, instead programmers must explicitly
> define all fields. Resorting to a MACRO may be appropriate.
> If bindings respect default values, then they: MUST respect all default values
> provided, and MUST report an error if a programmer fails to initialize
> non-defaulted fields.
# Documentation and Examples
The language specification and tutorial should be updated to reflect this
change.
# Backwards Compatibility
Existing behavior varies between different language bindings.
This change allows all existing behavior and encourages better future behavior.
# Performance
No impact.
# Security
This clarifies the specification and makes accidental misuse of interfaces
more difficult.
These are good for security.
# Testing
No testing is required.
# Drawbacks, Alternatives, and Unknowns
An alternative would be to formally define that:
```
fidl
struct Foo {
int32 bar;
bool baz;
float32 wux;
};
```
is semantically equivalent to:
```
struct Foo {
int32 bar = 0;
bool baz = false;
float32 wux = 0.0;
};
```
but as outlined
[
above
](
#motivation
)
this may fail to capture important semantics.
A previous iteration of this proposal included strings but at the time of
writing they're still nullable so have a way of indicating that they're
required or optional.
# Prior Art and References
n/a
<!-- xrefs -->
[
fidl-language
]:
https://fuchsia.googlesource.com/fuchsia/+/master/docs/development/languages/fidl/reference/language.md
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment