{% set rfcid = “RFC-0038” %} {% include “docs/contribute/governance/rfcs/_common/_rfc_header.md” %}
Note: Formerly known as FTP-038.
When this proposal was drafted, and socialized, there was a strong consensus to consider syntax changes all at once, rather than one at a time (see also RFC-0039). We also wanted one person to be the syntax arbiter, rather than risk designing by committee.
Eventually, this proposal was obsoleted by RFC-0050 which met both conditions sought.
We propose a syntax change to convey differences between layout from constraints.
Quickly:
Types which have different layout, and types which have the same layout (but different constraints) look alike.
Same layout:
vector<T>:6
, or vector<T>:10
T?
where T
is a union
, vector
, or string
handle
, handle<vmo>
, or handle<channel>
Different layout:
array<T>:6
vs array<T>:10
S?
where S
is a struct
Align on the syntax
layout:constraint
For types, i.e. anything that controls layout is before the colon, anything that controls constraint is after the colon.
Suggested changes:
array<T>:N becomes array<T, N> S? becomes box<S>:nullable (S is a struct) T? becomes T:nullable (T is a vector, or union) string is an alias for vector<uint8>:utf8 handle<K> becomes handle:K
Notes:
struct
nullable.This proposal improves ergonomics by conveying ABI implications to developers through syntax.
At least:
This is not source level backwards compatible.
Note: This RFC was rejected early during its socialization phase, which explains the multiple missing sections (e.g. “Implementation strategy”, or “Drawbacks, alternatives, and unknowns”).