We believe in the expressive power of sum types. Sum types are an easy way to express polymorphism that is easy to statically verify and therefore very resilient to errors and mistakes. Languages like Rust and Swift get this right. OpenAPI has a polymorphism concept using the oneOf field, but it’s quite cumbersome. We can do better.

In a similar vein, we believe in the rigor of monadic optionals. Tony Hoare, recognized as the originator of the concept of null references, has since decried them as “the billion dollar mistake”. Unfortunately, JSON only supports the concept of null (and similarly an “undefined” state for something omitted entirely). We believe that this state of affairs can be improved, and that can’t be done in the context of OpenAPI.

Sum Types

How do we specify these in the schema?

This is relevant to Alternative serialization medium

Value Unions

This also encompasses Typescript-style value unions or “enum literals”, like "foo" | "bar". Do we want to allow these to span across types?

Monadic Optionals

Discourse

Some people would have to be sold on this. The main draws are

• Some data is inherently shaped like this
• Moreover, this is especially useful for patches / lax structs. Users need to know if the client sent in an explicit null or just didn’t include it in the request body. Diesel handles this by expecting an Option<Option<T>>

Questions

How do we handle nested optionals in languages / media that do not have monadic optionals? It’s important to consider this in the context of the Partial (Lax) Operator

This question exists on both the medium side and implementation side

For media, we have these options

• “Coalesce” everything into a single null - idiomatic but misses the point of nested optionals

• Homebrew a sum type.

  ❓ I would like to keep $ for tagged unions, so what do we call it?

  Maybe something like

  type Option<T> = null | { $: T } 
  

  This is going to be hard sell for many users, but maybe we can make it coexist with the current concept of Veneto optionals which is a single-level nullable

  For implementations, we would have to homebrew a sum type for languages that don’t have them, since other languages (like JS) would expect null.

  This gets janky real fast; we would have to have an .unwrap() method or similar probably

  Even for serde, we would need to write an adapter that would handle that. Easy, but unexpected

• Keep Typescript-like semantics, except a single ? is undefined while a ?? is explicitly null. Gotta do a lot of looking into pros and cons for this ❓

At the project level, we would want a preference for this. It should probably be coalesce by default, since that’s what everyone will expect, but maybe we allow users to opt into sum types. This would also ease the transition