• amluto a day ago

    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.
    • shoo a day ago

      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.
      • DeathArrow a day ago

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

        type Suit =

        | Heart

        | Diamond

        | Spade

        | Club

        • mike_ivanov a day ago

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