Open and closed universes (2021)

ISTM the author made an unnecessarily restrictive choice:

> A downside is that traits make each choice in an open universe a type, not a value, so operations like equality become harder to define. It isn’t impossible, though: the trait could require a key method which returns a many-strings type.

    #[derive(Eq, PartialEq)]
    struct ArchitectureKey(pub Cow<'static, str>);
    
    pub trait Architecture {
        // ...
        fn key(&self) -> ArchitectureKey;
    }

So an architecture is a type that is expected to only have a single value, and a dynamic architecture (from, say, a description in a file) can’t be done in a dignified manner.

But ISTM this can be generalized very easily:

    pub trait Architecture {
        // ...
        fn key(&’a self) -> ArchitectureKey<‘a>;
    }

Now an architecture is a value of a type that implements Architecture, and those types can be single- or multiple-valued. And single-valued architectures can be implemented without needing to awkwardly allocate and maybe even leak memory. (The cow::Borrowed in the OP could be used to avoid leaking at the cost of potentially large amounts of useless allocation.). But this variant doesn’t use 'static and avoids this issue.

another step, that nobody asked for, could be to add multiple systems whispering dialects of enums to each other over the wire

https://protobuf.dev/programming-guides/enum/

  > Enums have two distinct flavors (open and closed). They behave identically except in their handling of unknown values.

  > The distinction between open and closed can be encapsulated in a single question:

  > > What happens when a program parses binary data that contains field 1 [defined in the proto used by that program] with the value 2 [where 2 is a value not defined for the enum for field 1 used by that program]?

  > Open enums will parse the value 2 and store it directly in the field. Accessor will report the field as being set and will return something that represents 2

  > Closed enums will parse the value 2 and store it in the message’s unknown field set. Accessors will report the field as being unset and will return the enum’s default value

  > The following specifies the behavior of conformant implementations for protobuf

  > When a proto2 file imports an enum defined in a proto2 file, that enum should be treated as closed.
  > When a proto3 file imports an enum defined in a proto3 file, that enum should be treated as open.
  > When a proto3 file imports an enum defined in a proto2 file, the protoc compiler will produce an error.
  > When a proto2 file imports an enum defined in a proto3 file, that enum should be treated as open

  > Known Issues

  > All known [C++, C#, Java, Kotlin, Go, JSPB, Ruby, Dart] releases are out of conformance

  > [PHP, Python >= 4.22.0, Objective C >= 22.0, Swift] is conformant.

Speaking about sum types, I like the elegance of defining them in F#.

type Suit =

| Heart

| Diamond

| Spade

| Club

TL;DR - it's NOT about topology nor cosmology