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

EP>И там и там Variant. В том что набор типов Variant'а будет отличаться при комментировании ветки else — не вижу проблемы

Еще раз. Variant — _не_ maybe. Даже близко не maybe. Даже не аналог. Конкретная реализация maybe вполне _может_ использовать variant в качестве "кишок" — это да. Но, только и всего.

EP>Variant — своего рода обобщение Maybe. Вычислять if-с-else в maybe — действительно не имеет смысла.

Уф. Сдается мне, у вас какое-то своеобразное представление о maybe. Давайте на пальцах...

Представим себе, что у нас есть у нас ф-ция f(int) -> maybe[int]. В какой, по вашему мнению, тип должен быть вычислен if(x > 0) f(x)?
Мне, вот, очевидно — в тот же самый maybe[int]. Надеюсь, что и вам тоже. И если это так, то объясните мне, как вы собираетесь провернуть такой "фокус" на "читых" variant'ах?

G>>А зачем вам какой-то явный unbox для variant? Вполне можно обойтись и неявным приведением к.
EP>А где именно оно будет происходить? if-else будет сразу иметь этот тип? Или при присвоении к значению типа T?

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

EP>А для него не будет unbox'а — unbox это только для variant[T], то есть для тех случаев, когда обе ветки if-else имеют одинаковый тип результата, и variant внутри имеет значение только одного определённого типа.

Вот уж в этом-то случае, явный unbox смысла не имеет вообще.

G>>Нормально обработать его можно только через PM. Вы же, надеюсь, не собираетесь прогонять его через очередной if? Об этом и речь.
EP>Можно и через if, а можно и спрятать этот if/условный переход в библиотеку, так как это сделано в boost::variant.
EP>Обычная работа с variant'ом. В чём проблема-то?

Уж вот я не знаю как для вас. А для меня то, что я увидел по вашей сслыке на boost — является всем чем угодно, но не "обычной работой с variant'ом".

В нашем случае использовать if не получится... конечно, если вы не предлагаете "нафантазировать" для этого случая еще один — специальный — "if". Ну, который не будет вычисляться в variant .
А вариант с двойной диспетчеризацией — еще хуже. Надеюсь, вы сами это понимаете.

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

?! Вы вообще о чем? Как определить этот "метод"? Смысл использования variant'а — по вашей же логике — "впихнуть невпихуемое". Если мы подразумеваем общий интерфейс, то зачем variant-то?!

G>>Но просто так (без PM) использовать не получится. Хоть в Nemerle, хоть еще где.
EP>Во-первых, в Nemerle же есть PM — в чём проблема?

Проблему можно выразить так: Если результат if можно обработать только через PM, то зачем нам использовать if? Почему сразу не использовать PM?!

Напоминаю, в сабже if — это "сахар" для PM.

EP>Во-вторых — я же приводил уже примеры использования variant'а в C++ — нужен конкретный код?

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

Одно дело, какой-нибудь условный:

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

А другое — предлагаемые вами "танцы на граблях" (с)

---
С уважением, Константин Сиваков