То есть код с обобщением превратиться в
enum Foo<T> {
 A,
 T(T)
}
?

для
fn foo<T>(x: A) -> T | A {}

должно сгенерироваться

fn foo<T>(x: A) -> SomeUniqueEnum {}

enum SomeUniqueEnum<T> { T(T), A(A) }

что тут сломается?

Ну тогда не вижу применения этому варианту

Нельзя сделать генерик генерика

вопрос в то, имеет ли смысл запись A | A

Это уже предлагалось неоднократно. Всегда возникает два принципиальных вопроса (помимо синтаксиса, разумеется):
1) как матчиться по значению такого типа;
2) что делать, если у тебя обобщённый тип T | U и они при мономорфизации совпадают

не вижу проблем

1. матчишься по конструктору который совпадает с имеем типа
2. таскаешь тег чтобы различать варианты

хотя кому-то будет логично, что i32 | i32 == i32

Ну это не значит что это для того чтобы тебе никогда енамы не приходилось использовать.

Точно так-же как туплы не полная замена структурам.

Для создания c-like енумов сокращённым синтаксисом, пришлось бы добавлять что-то вроде тэгов (не помню где точно, но врде в closure такое видел)



Альтернативно можно усложнить синтаксис, чтобы с матчем чисел не конфликтовало. Но я не думаю что неименованные c-like енамы это так полезно.

1) А если два варианта с одним и тем же типом?

конструкторы все равно будут разные, T/U в твоем примере

2 ошибка компиляции

у тебя потом говно будет и никто этой фичей не будет пользоваться

потому что затащил серде в актикс, и там что-то в генериках поломалось

То есть имена конструкторов обязательно писать?

удобно

нет, они генерироваться будут

Да, ибо в дженериках иначе будет разное поведение при разных дженериках и

fn foo<A, B>(ab: A | B) {
   match ab {
       0(A) => ...,
       1(B) => ...,
   }
}

Будет везти себя по разному в зависимости от того, A == B, или нет