Здравствуйте, gbear, Вы писали:

G>Скорее всего, я как-то Вас не так понял... но, имхо, не получится в этом случие "достаточно симметрично". Начиная с того, что variant[A] — будет вызывать только раздражение, а variant[A, void] — не является (хоть по сути, хоть еще как) Maybe.
G>void — в сабже — вполне себе нормальный тип. Вводя вычисление if-без-else в option[T] (так, как я понял, выглядит Maybe а сабже) — а это, "по сути", variant[Some[T], Nothing], а не variant[Some[T], void] — мы получаем возможность явно различать — было ли произведено вычисление выражения в if, или нет.
G>Вычисляя же его же в variant[T, void] вы такую возможность теряете (ведь T, вполне, может быть и void). И мне не понятно, чего полезного — по вашему — дает такое вычисление?

ИМХО, variant[Some[T], Nothing], или variant[T, void] это всё детали.
Основной поинт в том, что и для if-без-else, и для if+else, и даже для if+else+if+else+... в качестве результата можно использовать один тип результата Variant<...>

G>Так же будут "проблемы" восприятия всяческих variant[A, A]. Даже если "упрощать" их до variant[A] — ничего, кроме дополнительного раздражения вывод таких типов вызвать не может.

Для обобщённого кода это удобно.
Для обычного — возможно да, автоматическое упрощение до A было бы удобней. Но это упрощение можно получить явным вызовом одного унарного оператора или функции, причём если считать что variant<A> всегда содержит значение типа A (то есть не Nothing), то такой вызов не будет давать никаких накладных расходов.
Я думаю намного более неудобно, если в ветках получаются слабосвязанные A и B, и выводится какой-то крайне слабый общий тип вроде IPrintable (как это делается сейчас) — по сути много полезной информации о типах бесследно теряется.