blob: aa2b04e7e13f5bf20d186b4e77fd1472c9d0b7ef [file] [log] [blame] [view]
> This [FTP](../ is rejected
# Rejection rationale
[Poisson d'avril][april-fools]!
However, the underlying idea of enforcing presence in contexts where
nullability is supported by the layout (e.g. table fields, nullable type
alias) is one that will likely be incorporated in another FTP.
# [FTP](../ Non Nullable Types
_Poisson d'Avril_
Field | Value
Status | Rejected
Authors |
Submitted | 2019-04-01
Reviewed | 2019-04-01
## Summary
FIDL library authors can mark some types and members as nullable with `?`.
This proposes a way to mark types and members as not nullable.
## Motivation
With type aliasing, a library author can make declarations incorporate
nullability into a type, for example:
using MiddleName = string:255?;
It can be valuable to explicitly mark a nullable type as non nullable,
for example:
struct FullName {
GivenName given_name;
vector<MiddleName> middle_names; // names shouldn't be null
FamilyName family_name;
Another example is for "boxed" types placed out-of-line:
// An "out-of-line" full name
struct InappropriateFullName {
option<FullName> full_name; // full_name shouldn't be null
## Design
This proposal introduces the non-nullable specifier for types that will mark
a nullable type as non-nullable.
It's a change to the source language but not the wire format, IR or bindings.
In the cases described above, we would use:
struct FullName {
GivenName given_name;
vector<MiddleName¿> middle_names;
FamilyName family_name;
struct InappropriateFullName {
option<FullName¿> full_name;
For symmetry with the syntax of type nullability the inverted question mark
symbol is used.
This is Unicode code-point `\u00BF`, [easily typed] on any keyboard.
Possible other use cases are adding non-nullable `table` members:
table FullName {
GivenName¿ given_name;
MiddleName middle-name;
FamilyName¿ family_name;
Or specifying that a particular `xunion` member must always be present:
xunion PreferredOperatingSystemVersion {
float32 Windows;
float32 MacOS;
float32 Linux;
float32¿ Fuchsia;
## Implementation strategy
This is not a breaking change but the need for it has recently increased with
the new support for generalized type aliases in FIDL.
## Ergonomics
Non-nullable types are a popular feature of languages like Kotlin, C#, Swift
and Typescript.
It's a [heavily requested feature](
for Dart.
## Documentation and examples
The grammar and language documentation will have to be updated.
## Backwards compatibility
This feature is backwards compatible.
## Performance
Some non-nullable types (such has structs) have a more compact representation
than their nullable variant so this will allow for more efficient transport.
## Security
Null references have been described by Tony Hoare as a
"[billion dollar mistake]" and can be responsible for security
## Testing
As a compiler change with no impact on IR or bindings we will need to add
tests for the fidl frontend compiler.
## Drawbacks, alternatives, and unknowns
Some concerns have been raised about the ISO 8859-1 taking the place of
US-ASCII characters in FIDL syntax but this character
[gets the job done].
## Prior art and references
As mentioned above Kotlin, C#, Swift and Typescript all allow types to be
declared as non-nullable.
<!-- xrefs -->
[easily typed]:
[heavily requested feature]:
[billion dollar mistake]:
[gets the job done]: