It is not infrequent that someone asks for generalized enum types in a mainstream language. To generalize the question, it is common to ask for generalized polymorphic values. This is not a niche feature. It is very prominent in Functional Languages but it is also a very heavy feature and can easily clobber your regression tests if implemented naively.

The question is usually posed as, why can't I just write "(A|B)" for a type signature. To draw the comparison, any kind of polymorphism is a subset of this feature request. For example, method overloading describes a type signature of "(A -> B|C -> D)". Method overloading is seen as much more tame and approachable because there has already been so much research in the way of its effect on the ecosystem of a widely used language. This is what I call the C++ syndrome, where people become very timid to attempt to implement something that is not already a feature in C++. That says a lot about the broad feature set that C++ has accumulated over the years. Anyone who has played a C++ compile-time game will probably agree that C++ has lots of strange features with bizarre interactions.

Unrestricted polymorphic variables are not implemented in any Functional Language that I know. FP just has a different feature set, not a superset. When talking about truly unrestricted polymorphic type constructions we maybe need some examples to describe how bizarre such a language would be. One such example that I can think of would be interactions with dependent-like types.

A dependent type describes a subset of values of a total type. For example, the prime numbers are a subset of real numbers that has the property of being prime. Similarly odd or even numbers are a subset dependent on the definition of a real number.

Let's imagine the definition of three functions. One operates only on odd numbers, the other on even numbers, and the other on prime numbers. If we were given unrestricted polymorphism, then we could define all of these function candidates with the same overloaded symbol and that would leave the compiler to determine which candidate to apply. If the number is even and is not 2, then we would apply the even-numbered function. If the number is odd and not prime, then we would apply the odd-numbered function. For numbers not falling into one of those two cases, we would generate a compiler error saying that the function call is ambiguous.

If that is too crazy, then we have to start to talk about constraints on what sort of polymorphism to allow. Ad-hoc and Parametric polymorphism are both mainstream concepts in statically compiled languages. Pushing beyond that we start to get into language specific considerations. The bar for adoption is usually set minimally at "not making the type system unsound". That is probably a good place to resume any discussion about anonymous enums after shaking the crazy-wacky-wild stuff off.

- Google Search
- DuckDuckGo Search
- Sogou Search
- Bing Search
- Baidu Search

- Perplexity 😵 Modelling Language
- A Categorical view of Typed Lambda Calculus with flexible Soundness Guarantees
- JLPT Flash Cards

- Static Site Generation with RDXL Web Templates
- An Attempt at Generative Programming in Rust
- Building Phonetic Autocorrection in Rust
- Finite State Transducers String-to-String Map in Rust
- Generating an RSS Feed for a site written in RDXL
- Using Into to Elegantly Coerce str and String types in Rust
- What is a cargo lockfile?
- Rust Sized, ?Sized, and unsized
- Duck Typing in Rust
- Run Rust on AWS Lambda
- Adding Support for CJK Characters
- Partial Differentiation Gradient Cheatsheet
- Rust, shared: by reference
- Rust, typed: associated types
- Rust, shared: by Sync
- Rust, abstracted: specialization
- Rust, asynchronized: threads