Support sum types in the type system

[alecthomas]

• feat: go-runtime schema parsing for type enums #1375
• Write a completely custom JSON decoder/encoder #1262
• Disallow json.(Un)Marshaler/encoding.Text(Un)Marshaler on user-defined types #1247
• Implement a type registry for retrieving reflect types at runtime #1386
• Handle sum types in backend encoder #1387
• Handle sum types in ingress encoder #1388
• ensure main.go is updated with schema changes during ftl dev #1451
• fix transitive export visibility in go schema parser #1449

Design

There are a few reasons to support sum types in FTL, but one of the primary motivations is mapping FTL types to JSON. JSON very frequently supports multiple types for a single key. eg. both of these might be valid keys:

{
  "depends": "foo"
}

and

{
  "depends": ["foo", "bar"]
}

We'll need to ensure that however we implement this, it's relatively simple to express sum types in each language, even languages like Go and Kotlin that don't provide first-class support for sum types.

eg. in Go this might look like:

//ftl:sumtype
type ScalarOrList interface { scalarOrList() }

type Scalar string
func (Scalar) scalarOrList() {}

type List []string
func (Scalar) scalarOrList() {}

type Response struct {
  Depends ScalarOrList `json:"depends"`
}

[alecthomas]

How are sum types represented in ingress JSON? {"kind": "Scalar", "value": "foo"}? In the example above this is probably redundant because we can tell from the type, but for data structures we wouldn't be able to. Though it might still be ambiguous in the case of eg. Bytes | String because Bytes is represented as a string, so probably better to be explicit.

[worstell]

How are sum types represented in ingress JSON? {"kind": "Scalar", "value": "foo"}? In the example above this is probably redundant because we can tell from the type, but for data structures we wouldn't be able to. Though it might still be ambiguous in the case of eg. Bytes | String because Bytes is represented as a string, so probably better to be explicit.

yeah a lot to unpack here, updated the design with discussion around encoding/a proposed strategy

[alecthomas]

Yay!