Мы: есть пример/задача
Вы: вот частичное решение
Мы: А что если изменится условие или вызов будет вот таким?
Вы: тонна текста про то, как все будет круто
Мы: ну на примере хотя бы
Вы: там очевидно
Мы: ээээ. а пример решения?
Вы: поставишь в другом месте проверку
Мы: пример?
Вы: тебе не ясно, что стат. типизация круто это отловит?
Мы: эээ. ну ты не показал. нам не «все очевидно»
Вы: вот пример (ссылка на частичное решение, вызвавшее вопросы), что там непонятно
Мы: ну вот же вопрос, что будет, если A, B, C
Вы: я все разжевал, что тебе непонятно
ad infinitum

ARK>>ААААА

  Order o = load_order();  // загружен произвольный заказ

  //increase_amount(o, 2.71);  - напрямую вызвали increase_amount - ошибка компиляции, условие HasRisk не равно false

  PROP_IF(o, not_has_risk(o), HasRisk) {
    increase_amount(o, 2.71);   // компилируется, условие HasRisk проверено и строго равно false
  }

void try_to_change_amount(Order& o)
{
  // если HasRisk равно true или неизвестно - то ошибка компиляции (не runtime!)
  PROP_IF(o, possibly_has_risk(o), HasRisk) {
    BOOST_MPL_ASSERT_MSG(false, YOU_CANT_INCREASE_AMOUNT_FOR_SUCH_ORDER, (O));
  };

  increase_amount(o, 2.71);  // в этой точке у нас заказ точно не HasRisk
}

...

  Order o = load_order();  // загружен произвольный заказ

  //try_increase_amount(o);   - ошибка компиляции, свойства заказа не проверены

  PROP_IF(o, not_has_risk(o), HasRisk) {
    try_increase_amount(o);   // работает, не будет ни ошибки времени компиляции, ни ошибки времени выполнения
  }
  PROP_ELSE(o) {
    // здесь, если есть такое требование, можем показать сообщение пользователю, что с заказом что-то не то
  }

struct OtherProp;

template<class O> using can_increase_amount = bm::and<
  CheckExact<O, HasRisk, bm::false_>,
  CheckExact<O, OtherProp, bm::false_>>;


...

  Order o = load_order();  // загружен произвольный заказ


  PROP_IF(o, not_has_risk(o), HasRisk) {
    //increase_amount(o, 2.71);   // уже НЕ компилируется! перестало!

    PROP_IF(o, is_other_prop_valid(o), OtherProp)
    {
      increase_amount(o, 2.71);   // а вот тут компилируется и гарантированно не вылетает в рантайме - все свойства проверены
    }
    PROP_ELSE(o) {
      // если надо, можем тут показать сообщение "у заказа нет OtherProp"
    }
  }
  PROP_ELSE(o) {
    // если надо, можем тут показать сообщение "заказ рисковый"
  }

EP>Вообще, всё зависит от пред/пост-условий требуемой функции, и соответственно мест в которых она используется.
EP>Если в её предусловия входит выполнение всех этих ограничений/условий, то без предварительных проверок её запускать нельзя. И соответственно все эти проверки надо городить в месте каждого вызова (либо удостовериться в их выполнении другими способами) — то в этом случае форсирование этих условий системой типов имеет смысл.
EP>Если же для запуска функции нет необходимости делать проверки, change_amount сама всё что нужно проверяет внутри, и более того её запуск с невыполненными условиями не является ошибкой, а вполне штатным режимом — то пытаться переписать все эти внутренние проверки на типы, не вижу смысла, это никак не отразится на местах вызова этой функции.

M>

Если ты когда-нибудь собирал мозаичные пазлы, то должен был заметить, что различная форма фрагментов рисунка позволяет избежать большинства ошибок и резко ускорить выполнение задачи. Типы в любой логике выполняют примерно туже самую роль.

M>Пока что все упирается в «это бессмысленно» и «если предусловий нет, то бессмысленно» и прочая и прочая и прочая

ARK>>ААААА

Order order = getOrder // неважно откуда

if (! order.property.valid) // а если тут программист забыл проверку
throw Something

process(order) // то тут случилось страшное.

EP>А потом нецелесообразность логики на типах в твоём конкретном опердне, ты экстраполируешь на все возможные примеры

function use(SortedArray s){
}

Array a = new Array(1, 5, 7);
SortedArray sa = new SortedArray(sa);

//use a выдаст ошибку компиляции
use(sa);

%% вводим приватный тип, недоступный снаружи
-redord(sorted, {s}).

use(L) when is_list(L) ->
  use(sorted(L));
use(#sorted{s = Sorted}) ->
  ...

sorted(L) ->
  #sorted{s = lists:sort(L)}.

M>>Пока что все упирается в «это бессмысленно» и «если предусловий нет, то бессмысленно» и прочая и прочая и прочая

M>

M>При том, что рядом же другие пропоненты заявляют, что логику на типах, банить неправильные вызовы и т.п.

EP>>А потом нецелесообразность логики на типах в твоём конкретном опердне, ты экстраполируешь на все возможные примеры

M>Я не предлагаю до бесконечности. Я предлагаю хотя бы как-то. Но даже как-то у вас или не рожается или рожается со скрипом и пинками

Считай перед вызовом каждой функции расставляются виртуальные assert'ы, которые отрабатывают на этапе компиляции.
В динамических же языках эти assert'ы подразумеваются, но никак не энфорсятся. И соответственно чем больше программа, тем больше вероятность что какая-то из ошибок подобного рода будет пропущена. Если вероятность пропуска/фейла одного такого assert'а 0.01, то уже для 230 мест вероятность пропуска хотя бы одного будет 0.9.
И даже 100% покрытие строчек кода тестами не даёт гарантии что все ошибки этого класса найдены.

M>function use(SortedArray s){
M>}

M>Array a = new Array(1, 5, 7);
M>SortedArray sa = new SortedArray(sa);

M>//use a выдаст ошибку компиляции
M>use(sa);
M>

M>%% вводим приватный тип, недоступный снаружи
M>-redord(sorted, {s}).

M>use(L) when is_list(L) ->
M>  use(sorted(L));
M>use(#sorted{s = Sorted}) ->
M>  ...

M>sorted(L) ->
M>  #sorted{s = lists:sort(L)}.
M>

M>такие пробелмы вылезают — ну, два раза в год

M>>>Пока что все упирается в «это бессмысленно» и «если предусловий нет, то бессмысленно» и прочая и прочая и прочая

EP>Если вызов твоей функции с невыполненными условия не является ошибкой, а вполне штатным состоянием с чётким контрактом — то эти условия не являются предусловиями. Ещё раз, прочитай наконец что означают термины пред/пост-условия — http://en.wikipedia.org/wiki/Precondition

----> точка входа в функцию X

     if
     if
     if
     if
     if

     ----> точка входа в функцию Y

M>>Я не предлагаю до бесконечности. Я предлагаю хотя бы как-то. Но даже как-то у вас или не рожается или рожается со скрипом и пинками

EP>Как-то: вместо безликих amount'ов введи тип MoneyUSD или что там у вас

M>>такие пробелмы вылезают — ну, два раза в год

EP>А Mars Climate Oribter из-за такой вот проблемы рассыпался в атмосфере Марса, только и всего

M>Но да, но да. Именно я виноват в том, что я не прошу разных примеров, ага. А не вы, которые предпочитаете словоблудствовать на сотню страниц

M>>>Я не предлагаю до бесконечности. Я предлагаю хотя бы как-то. Но даже как-то у вас или не рожается или рожается со скрипом и пинками

EP>>Как-то: вместо безликих amount'ов введи тип MoneyUSD или что там у вас

EP>>Я не говорил что обогащать типами можно любую задачу до бесконечности.
M>Я не предлагаю до бесконечности. Я предлагаю хотя бы как-то. Но даже как-то у вас или не рожается или рожается со скрипом и пинками

Как ты собираешься проверять, что все эти ифы и предикаты расставлены правильно? То есть каким образом ты будешь проверять, что все проверки сделаны правильно и в нужном порядке?

Чем дальше, тем любопытсвеннее © Чем дальше, тем более идиотские странные условия должны выполниться, чтобы мы наконец-то увидели всю мощь и красоту типов

EP>Если протокол не типизированный, либо реализации генерируются не из одной схемы — то типизация не поможет. Но это ошибка рода ODR-violation — в разных модулях один и тот же тип определён по разному

EP>>>Как-то: вместо безликих amount'ов введи тип MoneyUSD или что там у вас

EP>Например предотвратит передачу MoneyAUD в MoneyUSD, или например радикально сократит количество перестановок аргументов валидных с точки зрения типов

EP>Найденным?

EP>И что? На динамическом языке можно написать корректную и надёжную программу, и наоборот — на статическом некорректную и ненадёжную

EP>Это сводится, как минимум, к автоматическим assert'ам на каждый аргумент каждой функции, проверяемым в compile-time