Experimental: Newtypes are an unstable feature gated behind the --experimental allow_new_types fidlc flag.
Newtypes from RFC-0052: Type aliasing and new types are not allowed to be constrained. For example, a newtype of string cannot be constrained with :optional:
{% include “docs/reference/fidl/language/error-catalog/label/_bad.md” %}
{% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="tools/fidl/fidlc/tests/fidl/bad/fi-0179.test.fidl" exclude_regexp="\/\/ (Copyright 20|Use of|found in).*" %}
In this situation, we can make make the name field optional by putting it in a table rather than a struct:
{% include “docs/reference/fidl/language/error-catalog/label/_good.md” %}
{% includecode gerrit_repo="fuchsia/fuchsia" gerrit_path="tools/fidl/fidlc/tests/fidl/good/fi-0179.test.fidl" exclude_regexp="\/\/ (Copyright 20|Use of|found in).*" %}
This restriction simplifies the design of newtypes. It's not clear what the API and ABI should look like for a constrained newtype in general (e.g., should the constraints apply to the newtype itself, or flow through to the underlying type?).
