Targets · Swift · Naming considerations

Naming considerations

A Program name nests to any depth — Ui.Button.Integer.Increment. This page is how that dotted name is carried into Swift, which nests just as deeply.

Contents

How a Program becomes Swift, in parts. Start with the introduction, then follow each part into the rendered output and the runtime it links against.

How it looks

Swift is one of the good cases: the dotted name is kept exactly as written, every segment a real type.

Ui.Button.Integer.Increment(count, { … })   // verbatim, four real dots

The natural idiom

Swift has genuine nested types — an enum, struct or class can contain another. A caseless enum is the idiomatic namespace: it holds only static members and cannot be instantiated, which is exactly what a Program module is.

Keeping the real dotted name

No faking is needed. Each namespace segment becomes a nested caseless enum, and the leaf is a public static func inside it — so the dotted path is a real, compiler resolved member chain.

enum Ui {
  enum Button {
    enum Integer {
      public static func Increment(_ count: ReactiveValue<Int>, _ body: () -> Void) { … }
    }
  }
}

// the call is the Program name, unchanged:
Ui.Button.Integer.Increment(count, { … })

A record TYPE is a struct in its namespace path, a union TYPE an enum with cases; a built-in value type folds to a native type (Maths.IntegerInt).

Recommendation

Use nested caseless enums. Swift keeps every dot real, at both the value and the type level, with no compromise — the same as Rust (::) and Zig (struct containers), and unlike Dart and Go, which must join with an underscore. The only identifiers ever rewritten are ordinary names that collide with a reserved word.