a: A, b: B --> (a | b): variant<A, B>
a: A, b: Unused --> (a | b): optional<A>
a: A, b: B, c: Unused --> (a | b | c): optional<variant<A, B> >
a: Unused, b: B --> (a | b): optional<B>
a: Unused, b: Unused --> (a | b): Unused
a: A, b: A --> (a | b): A

a: A --> -a: optional<A>
a: Unused --> -a: Unused

Variant<Triangle, Rectangle> v = ...;
v.draw();

Variant<Triangle, Rectangle> v = ...;
use_concrete_type(v)
{
    v.draw();
};

Γ |- t1 : T1, T1 = Bool, Γ |- t2 : T2, Г |- t3 : T3, T2 V T3 = T
----------------------------------------------------------------
Γ |- if t1 then t2 else t3 : T

if(a(x)) 
  "a"
else
  if(b(x))
    1
  else
    if(c(x))
      0.1
    else
      Some(x)

        | Not(Not(rule))                => optimize(Rule.And(r.Location, rule)) 
        | And(Not(rule))                => optimize(Rule.Not(r.Location, rule)) 
        | Not(And(rule))                => optimize(Rule.Not(r.Location, rule)) 
        | And(And(rule))                => optimize(Rule.And(r.Location, rule)) 
        | Not(rule)                     => Rule.Not(r.Location, optimize(rule)) 
        | And(rule)                     => Rule.And(r.Location, optimize(rule)) 
        | Capture(kind, rule)           => Rule.Capture(r.Location, kind, optimize(rule)) 
        | Scope(name, rule)             => Rule.Scope(r.Location, name, optimize(rule)) 
        | Chars(chars)                  => Rule.Fsm(r.Location, FSMBuilder.Seq(chars)) 
        | Cut as rule                   => rule 
        | Fsm as rule                   => rule

typeof
(
    if(condition)
        return A{};
    else
        return B{};
)
==
Variant<A, B>

when (true)
  42;
0

if (true)
  return 42;
return 0;

G>Даже если "обернуть" все это в variant — это мало что изменит . Типы A и Some[A] — это таки разные типы.

G>Можно потытаться "стереть границы" введя функторы, например... и вот тогда про "два синтаксиса" вообще никто вспоминать уж точно не будет

G>Смотрите, я выше высказался за разрешение неоднозначности при вычислении if-без-else. Действительно её можно снять вычисляя его в maybe. Проблема только в том, что это никакого отношения к вычислению if-с-else не имеет

Variant<Widget, Gadget> x, y;
// ...
apply(x, y, [](auto &x, auto &y)
{
    draw(x);
    draw(y);
    collide(x, y);
});

G>>Нормально обработать его можно только через PM. Вы же, надеюсь, не собираетесь прогонять его через очередной if? Об этом и речь.

G>>Nemerle тут вообще не причем Недостаточно вычислить if в variant[A, B, C]. Нужно еще как-то "узнать", что конкретно этот variant сейчас в себе несет... A, B или C. И его нужно будет либо дополнительно проверять...

EP>Точно также как и в случае с виртуальным вызовом метода результата

match (if (x > 0) getA() else getB())
{
  | y is A => handleA(y.PropertyOfA)
  | y is B => handleB(y.MethodOfB())
}

auto foo()
{
    return (if(c) T{1} else T{2});
}

template<typename T, typename U>
void bar()
{
    auto res = if(c) T{} else U{};
    // use res as variant
}

G>конечно, если вы не предлагаете "нафантазировать" для этого случая еще один — специальный — "if". Ну, который не будет вычисляться в variant .

G>>>Nemerle тут вообще не причем Недостаточно вычислить if в variant[A, B, C]. Нужно еще как-то "узнать", что конкретно этот variant сейчас в себе несет... A, B или C. И его нужно будет либо дополнительно проверять...

EP>>Точно также как и в случае с виртуальным вызовом метода результата

Variant<Widget, Gadget> x, y;
// ...
apply(x, y, [](auto &x, auto &y)
{
    draw(x);
    draw(y);
    collide(x, y);
});

G>Не нужен. Яж вам говорю... чудес не бывает

G>match (if (x > 0) getA() else getB())
G>{
G>  | y is A => handleA(y.PropertyOfA)
G>  | y is B => handleB(y.MethodOfB())
G>}
G>

MATCH( IF(x>0) { return getA(); } ELSE { return getB(); } )
    CASE(y IS A) { handleA(y.PropertyOfA); }
    CASE(y IS B) { handleB(y.MethodOfB()); }
;

EP>Явно или автоматически: Variant<Variant<T, void>, void> -> Variant<T, void>

EP>auto foo()
EP>{
EP>    return (if(c) T{1} else T{2});
EP>}
EP>

EP>template<typename T, typename U>
EP>void bar()
EP>{
EP>    auto res = if(c) T{} else U{};
EP>    // use res as variant
EP>}
EP>

G>>конечно, если вы не предлагаете "нафантазировать" для этого случая еще один — специальный — "if". Ну, который не будет вычисляться в variant .

boost::variant< int, std::string > v;

...

class times_two_visitor
    : public boost::static_visitor<>
{
public:

    void operator()(int & i) const
    {
        i *= 2;
    }

    void operator()(std::string & str) const
    {
        str += str;
    }

};

...

boost::apply_visitor( times_two_visitor(), v );

EP>Variant<Widget, Gadget> x, y;
EP>// ...
EP>apply(x, y, [](auto &x, auto &y)
EP>{
EP>    draw(x);
EP>    draw(y);
EP>    collide(x, y);
EP>});
EP>

EP>Здесь нет общего предка у Widget и Gadget (да и вообще у них нет ни одного метода), а интерфейс использования в данном случае у них одинаковый

Если мы подразумеваем общий интерфейс, то зачем variant-то?!

G>>Не нужен. Яж вам говорю... чудес не бывает

G>>match (if (x > 0) getA() else getB())
G>>{
G>>  | y is A => handleA(y.PropertyOfA)
G>>  | y is B => handleB(y.MethodOfB())
G>>}
G>>

EP>MATCH( IF(x>0) { return getA(); } ELSE { return getB(); } )
EP>    CASE(y IS A) { handleA(y.PropertyOfA); }
EP>    CASE(y IS B) { handleB(y.MethodOfB()); }
EP>;
EP>

EP>

EP>>Явно или автоматически: Variant<Variant<T, void>, void> -> Variant<T, void>

G>А если автоматически, то получается тип Variant<Variant<T, void>, void> существовать не может? Я вас правильно понимаю?

EP>>auto foo()
EP>>{
EP>>    return (if(c) T{1} else T{2});
EP>>}
EP>>

G>>>Почему только при присвоении?! Везде, где "по смыслу" должно быть T.

G>Хотите работать с res как c variant'ом — ктож вам запретит Но если у вас есть, например, какая-нибудь ф-ция от X, то, согласитесь, удобней "уметь" в неё передавать variant[X] "as is", а не дергать какие-то unbox'ы.

G>?! Очевидно, потому что if вернет нам новый variant. С которым "нужно что-то делать"

G>>>конечно, если вы не предлагаете "нафантазировать" для этого случая еще один — специальный — "if". Ну, который не будет вычисляться в variant .

G>?! Вы серьезно не понимаете? ?! Очевидно, потому что "нормальный" if вернет нам новый variant. С которым "нужно что-то делать"

EP>>...
EP>>

EP>>Здесь нет общего предка у Widget и Gadget (да и вообще у них нет ни одного метода), а интерфейс использования в данном случае у них одинаковый

G>Возвращаемся к нашим баранам. Таки через visitor'ы предлагаете?

EP>>MATCH( IF(x>0) { return getA(); } ELSE { return getB(); } )
EP>>    CASE(y IS A) { handleA(y.PropertyOfA); }
EP>>    CASE(y IS B) { handleB(y.MethodOfB()); }
EP>>;
EP>>

EP>>

EP>Например simplify(v) или какой-нибудь унарный оператор ^^ v

if(x > 0) bar(x) else foo(x)

if(x > 0) bar(x)

if(x > 0)
  if(x > 10) x else foo(x)

G>>А если автоматически, то получается тип Variant<Variant<T, void>, void> существовать не может? Я вас правильно понимаю?

G>>?! Очевидно, потому что if вернет нам новый variant. С которым "нужно что-то делать"

EP>Когда из if возвращается указатель на какую-нибудь абстрактную базу, при работе с ней придётся точно также выяснять — что же там внутри, и какой именно метод вызывать. Выбор-то никуда не исчезает

def a = if(x > 0) "a" else 1; // "абстракная база" в виде какого-нибудь IConvertable  
def b = if(a is string) stringToX(a) else intToX(a); // Вполне конкретный X

EP>Там одинарная диспетчеризация, а не двойная

template <typename Visitor, typename Visitable>
inline
    BOOST_VARIANT_AUX_APPLY_VISITOR_NON_CONST_RESULT_TYPE(Visitor)
apply_visitor(Visitor& visitor, Visitable& visitable)
{
    return visitable.apply_visitor(visitor);
}

...

template <typename Visitor, typename VoidPtrCV, typename T>
inline
    BOOST_VARIANT_AUX_GENERIC_RESULT_TYPE(typename Visitor::result_type)
visitation_impl_invoke_impl(
      int, Visitor& visitor, VoidPtrCV storage, T*
    , mpl::true_// never_uses_backup
    )
{
    return visitor.internal_visit(
          cast_storage<T>(storage), 1L
        );
}

EP>Тем что такой синтаксис можно получить на базе boost::variant

EP>>Например simplify(v) или какой-нибудь унарный оператор ^^ v

G>if(x > 0) bar(x) else foo(x)
G>

G>if(x > 0) bar(x)
G>

G>if(x > 0)
G>  if(x > 10) x else foo(x)
G>

G>>>А если автоматически, то получается тип Variant<Variant<T, void>, void> существовать не может? Я вас правильно понимаю?

G>Вывод, нужен таки maybe, а не суррогаты

G>def a = if(x > 0) "a" else 1; // "абстракная база" в виде какого-нибудь IConvertable  
G>def b = if(a is string) stringToX(a) else intToX(a); // Вполне конкретный X
G>

G>Можно и по сложней примеры нарисовать — например, когда "база" таки нужна. Но, в вашем варианте получим очередной variant[T, U] .

Variant<Widget, Gadget> x, y;
// ...
apply(x, y, [](auto &x, auto &y)
{
    draw(x);
    draw(y);
    collide(x, y);
});

EP>>Тем что такой синтаксис можно получить на базе boost::variant

G>Синтаксис-то тут причем?! Скажите лучше во что это вычислится? В variant?

#include <iterator>
#include <vector>
#include "match.hpp"

struct widget {};
struct gadget {};

void draw(widget) { println("drawing widget"); }
void draw(gadget) { println("drawing gadget"); }

int main()
{
    using namespace std;
    bool flags[] = {true, false, true, true, false};
    vector<variant<widget, gadget>> xs;
    
    for(auto f : flags)
        if(f)
            xs.push_back(widget{});
        else
            xs.push_back(gadget{});

    for(auto x : xs)
        MATCH(x)
            CASE(x IS _) { draw(x); }
        ;
    println();

    vector<variant<int, double>> ys;
    for(auto x : xs)
        ys.push_back
        (
            MATCH(x)
                CASE(x IS widget) { println("x IS widget"); return 1; }
                CASE(x IS gadget) { println("x IS gadget"); return 0.1; }
        );
    println();

    for(auto y : ys)
        MATCH(y)
            CASE(y IS int)    { println("y IS int"); }
            CASE(y IS double) { println("y IS double"); }
        ;
}

drawing widget
drawing gadget
drawing widget
drawing widget
drawing gadget

x IS widget
x IS gadget
x IS widget
x IS widget
x IS gadget

y IS int
y IS double
y IS int
y IS int
y IS double

int Test()
{
  var a = 6; // int
  var b = 7; // int
  var c = a * b; // int(42);
  return c;
}

int Test(bool b)
{
  var a = if(b) 6; // int?
  var b = 7; // int
  var c = a * b; // int? - лифтинг!
  return c; // compile-time error
}

int Test(bool b)
{
  var a = if(b) 6 else 0; // int
  var b = 7; // int
  var c = a * b; // int 
  return c; // tadamm!
}

int? Test(bool b)
{
  var a = if(b) 6; // int?
  var b = 7; // int
  var c = a * b; // int? - лифтинг!
  return c; // tadamm!
}

int Test(bool b)
{
  var a = if(b) 6; // int?
  var b = 7; // int
  var c = a * b; // int? - лифтинг!
  return c ?? 0; // disambiguation
}

typeof(BooleanFunc() ? 5) => int?
typeof(BooleanFunc() ? 5 ?? 0) => int

G>Вы предлагаете интерпритировать _любой_ variant[T, void] как maybe чтоли?! А если T — внезапно — окажется void? if(x > 0) foo(x) — это тогда "go wrong" — без вариантов

G>>>if(x > 0) bar(x) else foo(x)
G>>>

auto first = bar(1);
// ...
auto v = if(x > 0) bar(2) else foo(x);
match(v) case(v is typeof(bar(1))) { first = v; } // ...

guard :: Alternative f => Bool -> f ()
when :: Applicative f => Bool -> f () -> f ()
unless :: Applicative f => Bool -> f () -> f ()