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

AVK>В очередной раз тут понадобился упрощенный аналог tagged union, т.е. некий тип, представляющий собой объединение набора предопределенных типов по "или" (а не по "и", как в кортежах), и подумалось — может слегка обобщить Option до 7-8 type аргументов? Текущий тогда придется переобозвать как нибудь типа NullableOption. Ну и подумать на тему вариантов с неким общим для всех типов TCommonData и без такового.
AVK>Кто что думает?

А как оно с седьмым шарпом дружить-то будет?

operator is вроде в релиз не попадает, если ограничиться седьмым шарпом, то получается бессмысленный и беспощадный изврат в духе

    struct Is<T1, T2>
    {
        public static implicit operator T1(Is<T1,T2> t)
        {
            return t._1;
        }

        public static implicit operator T2(Is<T1, T2> t)
        {
            return t._2;
        }

        private T1 _1;
        private T2 _2;

        public Is(T1 t)
        {
            _1 = t;
            _2 = default(T2);
        }

        public Is(T2 t)
        {
            _1 = default(T1);
            _2 = t;
        }
    }
...
    var temp = new Is<int, string>("hello");
    // ...
    int intVal = temp;
    Console.WriteLine(intVal); // 0;

— эт раз.

Даже если бы попал — ADT тоже будут только в C#8, соответственно предупреждений о неполном match не будет — эт два.

Остаётся только одно решение: метод Match(Action<T1> case1, Action<T2> case2), который можно закопать не выпуская, как по мне.
Тип, который для каждого использования требует аллокации делегата с замыканием, на хороший код точно не тянет.

Я бы вообще убрал заигрывания с функциональщиной до нормальной поддержки в шарпе. Для реальных задач есть F#, для хипстеров — langext, чего ещё надо-то?