struct bar{ void f1(){}; void f2(){};}
struct zoo{void f1(){};}

void foo(bar data);

Вот это все настолько красиво звучит, что было бы здорово увидеть пример, как запросто отразить это в определении типа.

M>Предложи задачу, для которой имеет

template<typename State>
enable_if_t
<
    State::prepared && State::risk_checked || State::approved_by_boss
> change_amount_unconditionally(Order<State> x, Money amount)
{
    // ...
}

M>Но при этом «для этой задачи не имеет смысла»

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

M>>>Мне не нравится, что высокопафосные заявления про, например, "на типах можно задать какие угодно условия, главное чтобы аргументы условий были доступны compile-time." скатываются в банальное «ну, главное чтобы килограммы с метрами не складывались»

M>Определи понятие «сложные условия» и почему условия в моей задачи, видимо, недостаточно сложные

M>Или — о ужас — данные о заказе не compile-time, из-за этого ничего поделать нельзя? Ну извини, реальный мир он такой — подавляющее большинство данных получаются не в compile-time

M>Отлавливается первым же залетным тестом

M>То есть четвертый пункт — это
M>

M>if is_activated(Order) and is_auth_only(Order):
M>  do_capture(Order)
M>

M>Еще раз: как именно типы мне помогут?

M>У меня есть простейшая задача, мне просто интересно, как она будет решаться типами, и/или как типы могут помочь ее решить. Самое главное, если вся логика упаковывается в типы, каким образом проверяется правильность реализации этой логики на типах? Свое решение «в лоб» я тоже напишу, естественно Языки программирования — любые Но желательно приближенные к реальному миру (то есть те, что хоть в какой-то мере используются в природе).

[ ЗаказМодель
    (
      Структура = ((Отправлен | Неотправлен) / ( Непредоплачен | Предоплачен ) ) / Риск,
      Операции  = 
      [ 
         Неотправлен(   СуммуУвеличить,СуммуУменьшить ),
         Непредоплачен (   СуммуУвеличить,СуммуУменьшить ),
         Отправлен ( СуммуУменьшить ),
      ]
      
      
    ) ]
  module Модель
  {
    
    
    шаблон_СуммуУвеличить_sum(sum:decimal,val:decimal):decimal
    {
      if (sum + val > 2000 ) sum else sum + val 
    }
    
    шаблон_СуммуУменьшить_sum(sum:decimal,val:decimal):decimal
    {
      sum - val
    }
  }

  module Модель
  {
    [Record]
    public variant Заказ
    {
      | Отправлен
      {
        public ЗаказНепредоплачен():Заказ.ОтправленНепредоплачен
        {
          Заказ.ОтправленНепредоплачен(sum)
        }
        public ЗаказРиск():Заказ.ОтправленРиск
        {
          Заказ.ОтправленРиск(sum);
        }
        public СуммуУменьшить(val:decimal):Отправлен
        {
          def funct( sum:decimal,val:decimal):decimal
          {
            sum - val
          } 
          Отправлен(funct( sum, val ))
        }
      }
      | ОтправленНепредоплачен {  .... }
      | ОтправленРиск {  ... }

      .....    
      
      public Сумма:decimal {  get { sum } }
      
      private mutable sum:decimal;
      

      public static УменьшитьСумму( zlist : list[Заказ] , val:decimal ) : list[Заказ]
      {
        zlist.Map(z=> 
        {
          match(z)
          {
            | e is Отправлен =>  e.СуммуУменьшить(val);
        .....

            | _ => z;
          }
        })
      }
    }
  }

change_amount(Order, NewAmount) ->
  case is_forbidden(Order, NewAmount) of
    {error, Reason} ->
      {error, Reason};
    ok ->
      case risk_check(Order, NewAmount) of
        {error, Reason} -> {error, Reason};
        ok -> {ok, Order#order{amount = NewAmount}
      end
  end.

is_forbidden(Order, NewAmount) ->
  if
    is_risk(Order) ->
      {error, risk};
    not is_shipped(Order) andalso not is_prepaid(Order) ->
      ok;
    is_shipped(Order) andalso NewAmount > amount(Order) ->
      {error, amount}
    true ->
      ok
  end.

risk_check(Order, NewAmount) ->
  case amount(Order) < Amount of
    true -> risk:risk_check(Order, Amount);
    ok
  end.

change_amount(Order, NewAmount) ->
  case is_forbidden(Order, NewAmount) of
    ...
    ok ->
      case risk_check(Order, NewAmount) of
        ...
        ok -> 
          update_amount(Order, NewAmount)
      end
  end.

...

update_amount(Order, NewAmount) when amount(Order) > NewAmount ->
   Estore = get_estore(Order)
   Max = config:read(Estore, max_decrease),
   MaxPct = config:read(Estore, max_increase_pct),
   AmountDiff = abs(amount(Order) - NewAmount),

   case AmountDiff > Max andalso AmountDiff/amount(Order) > MaxPct of
     true -> {error, amount};
     false -> {ok, Order#order{amount = NewAmount}}
   end;
update_amount(Order, NewAmount) ->
   %% то же самое, только для max_increase и max_increase_pct
   end.

change_amount(Order, NewAmount) ->
  case is_forbidden(Order, NewAmount) of
    {error, Reason} ->
      {error, Reason};
    ok ->
      case risk_check(Order, NewAmount) of
        {error, Reason} -> {error, Reason};
        ok -> update_amount(Order, NewAmount)
      end
  end.

is_forbidden(Order, NewAmount) ->
  if
    is_risk(Order) ->
      {error, risk};
    is_prepaid(Order) andalso NewAmount > amount(Order) ->
      can_raise_prepaid_order(Order, NewAmount);
    is_shipped(Order) andalso NewAmount > amount(Order) ->
      {error, amount}
    true ->
      ok
  end.

can_raise_prepaid_order(Order, NewAmount) ->
  Estore = get_estore(Order),
  case config:get_config(Estore, can_raise_prepaid) of
    false -> {error, amount};
    true -> ok
  end.  

risk_check(Order, NewAmount) ->
  case amount(Order) < Amount of
    true -> risk:risk_check(Order, Amount);
    ok
  end.

update_amount(Order, NewAmount) ->
   Estore = get_estore(Order)
   Max = config:read(Estore, case amount(Order) > NewAmount of true -> max_decrease; false -> max_increase end),
   MaxPct = config:read(Estore, case amount(Order) > NewAmount of true -> max_decrease_pct; false -> max_increase_pct end),
   AmountDiff = abs(amount(Order) - NewAmount),

   case AmountDiff > Max andalso AmountDiff/amount(Order) > MaxPct of
     true -> {error, amount};
     false -> 
        auth_and_capture(Order, NewAmount)
   end.

auth_and_capture(Order, NewAmount) ->
  case is_prepaid(Order) of
    false ->
      {ok, Order#order{amount = NewAmount};
    true ->
      case NewAmount > amount(Order) of
        true ->
          case payments:auth(Order, NewAmount - amount(Order)) of
            {error, Reason} -> {error, Reason};
            ok -> capture(Order, NewAmount)
          end;
        false ->
           capture(Order, NewAmount)
      end
  end.

capture(Order, NewAmount) ->
  case is_shipped(Order) of
    false -> {ok, Order#order{amount = NewAmount};
    true ->
      case payment:capture(Order, NewAmount) of
        {error, Reason} -> {error, Reason};
        ok -> {ok, Order#order{amount = NewAmount}
      end
  end.

A -> B -> C  -> D -> E -> F
     \              /
      -(if X) - - -

S>>Я видно не понимаю контекста, но зачем тут именно типы?

    static void Example()
    {
        // Warning: CodeContracts: requires is false: !string.IsNullOrEmpty(s).
        // This sequence of invocations will bring to an error Example -> TestWithContract -> TestWithContract2 -> TestWithContract3 -> TestWithContract4, condition !string.IsNullOrEmpty(s)
        TestWithContract(""); 
    }
    
    private static void TestWithContract(string s)
    {
        TestWithContract2(s);
    }
    private static void TestWithContract2(string s)
    {
        TestWithContract3(s);
    }
    private static void TestWithContract3(string s)
    {
        TestWithContract4(s);
    }
    private static void TestWithContract4(string s)
    {
        TestWithContractCore(s);
    }
    private static void TestWithContractCore(string s)
    {
        Contract.Requires(!string.IsNullOrEmpty(s));
        Console.WriteLine(s);
    }

M>Ну, в целом я на самом деле согласен. У нас, правда, данный конкретный случай решено, по сути, if'ами В change_sum там три функции is_fobidden_1, is_fobidden_2 и is_fobidden_3 где-то на сто строчек После чего происходит собственно увеличение суммы (которое тоже может происходить по-разному из-за всякого разного).

DebugCode.AssertBusiness(order.State == State.Processed, "бла-бла-бла");

M>Ой. А мне утверждали, что придется меняться не во всем коде, а только в одном месте

t.FirstName++;

public void PushDataToStream(StreamWriter w)
{
   var r = File.OpenRead("EULA.txt");
   try
   {
      foreach(var line in r.RealAllLines)
         w.WriteLine(r)
   }
   finally
   {
     r.Close(); // критический код, который мы хотим обязательно выполнить.
   }
}

template<class Netto, class Phantom> struct phantom_type
{
  typedef Phantom phantom;
  Netto value;
  phantom_type(Netto v) : value(v) {}
};

// нетто
typedef int Good; // товар (в штуках)

// операции
unspecified1<Good> start(Good value);
unspecified1<Good> increase(unspecified0<Good> good);
unspecified1<Good> decrease(unspecified0<Good> good);
unspecified1<Good> increase(unspecified0<Good> good);
unspecified1<Good> riskcheck(unspecified0<Good> good); // здесь мы влезаем в полиморфизм времени исполнения
                                                       // так что - или делаем на продолжениях, или на полиморфных значениях
unspecified1<Good> pay(unspecified0<Good> good);
unspecified1<Good> send(unspecified0<Good> good);

M>Но пока что никто не рискнул Даже у Кодта наметки

Автор: Кодт
Дата: 06.02.15

, но без продолжения (но он объяснил, почему).

template<class PT> struct match_phantom;
template<class N, class P> struct match_phantom<phantom_type<N,P>> { typedef N n_type; typedef P p_type; };

template<class PT> using phantom<PT> = match_phantom<PT>::p_type;
template<class PT> using net<PT> = match_phantom<PT>::n_type;
template<class PT, class P1> using update_phantom = phantom_type<net<PT>, P1>;


template<class Final> struct applicator
{
  template<class PT> using asserted_and_transformed = 
    enabled_if<
      Final::precondition<phantom<PT>>::value, // выковыриваем признаки и проверяем предусловие
      update_phantom<PT, Final::transform<PT>> // получаем новые признаки и пришиваем к типу
    >;

  static template<class PT> auto action(PT pt) -> asserted_and_transformed<PT>
  { return Final::work(pt.value); }
};

struct IdentityFunctor : application<SomeFunctor>
{
  template<class Phantom> using precondition = mpl_bool<true>;
  template<class Phantom> using transform    = Phantom;
  static Good work(Good value) { return value; }
};



// признаки, которые нам нужны на первом шаге - пока что свалю в кучу
struct just_started
{
  static bool is_paid = false;
  static bool is_sent = false;
  static bool is_increased = false;
  static bool is_checked = true;
};


struct Start : applicator<Start> // прикрутим сюда функтор через CRTP
{
  // внутренние
  template<class P> using precondition = is_same<P,void>; // для затравки
  template<class P> using transform = just_started; // начинаем с вот таких признаков - создаём вот такой фантом
  static Good work(Good value) { return value; } // функция, которую будем лифтить; по умолчанию, id-функцию можно взять из коробки, из applicator.
};

struct Send : applicator<Send>
{
  template<class P> using precondition = mpl_bool<P::is_paid && P::is_checked>; // тупой предикат: взять булеву константу из признаков
  template<class P> struct transform : P { static bool is_sent = true; }; // по-простому, сокрытием имён ввели новое значение
};

struct Increase : application<Increase>
{
  template<class P> using precondition = mpl_bool<!P::is_sent>;
  template<class P> struct transform : P
  {
    is_checked = !P::is_sent;
    is_increased = true;
  };
  static Good work(Good value) { return value+1; }
};

data CanUpdateAmountOrder = CanUpdateAmountOrder Order NewAmount

can_update_amount :: (Order, NewAmount) => Either (CanUpdateAmountOrder Order NewAmount) (Error, Reason)
can_update_amount = ...

order_is(Tuple, Element) -> 
  lists:member(Element, tuple_to_list(Tuple)).

approve({order, {data, D}, {flags, F}}) when order_is(F, checked) -> 
  % 
  % До этого места дойдём только если в кортеже {order, {data, ...}, {flags, ...}} 
  % есть кортеж {flags, ...} и в нём есть элемент checked, то есть если он выглядит 
  % как {flags, ..., checked, ..., ..., ...} 
  % 

.

case approve(Order) of
  {ok, ...} ->
       ...
  _ ->
      exit(badOrderstState)
end.

M>Ээээ, что? Я, конечно, дааавненько на C++ не смотрел, но разобраться во всех этих шаблонах и зависимостях для меня проблема. Скажем, я тут вообще не понимаю: и что же дальше

auto good_1 = Start::action( phantom_type<Good,void>(1) ); // положили товар в корзину; тип - phantom_type<Good,just_started>
auto good_2 = Pay::action( good_1 ); // оплатили: phantom_type<Good, {just_started, is_checked=true, is_paid=true} >
auto good_3 = Increase::action( good_2 ); // добавили: phantom_type<Good, {just_started, is_checked=false, is_paid=true} >
auto good_4 = Pay::action( good_3 ); // оплатили добавку
auto good_5 = Send::action( good_4 ); // отправили

M>По-моему, чтобы такое написать, надо быть семи пядей во лбу

M>Я за 10 минут растащил все это без шаблонов

К>>Возможно, что в бусте уже всё придумано за нас. А если не придумано, допилю и выложу в продакшен

M>Да, хотел бы посмотреть на результат Надо не забывать, из всего этого еще внятные ошибки хотелось бы возвращать

M>>>Предложи задачу, для которой имеет

M>В первом же сообщении этой темы есть задача, где эти предусловия есть. То есть до того, как мы собственно меняем amount, у нас идет толпа предусловий

EP>>template<typename State>
EP>>enable_if_t
EP>><
EP>>    State::prepared && State::risk_checked || State::approved_by_boss
>>> change_amount_unconditionally(Order<State> x, Money amount)
EP>>{
EP>>    // ...
EP>>}
EP>>

template<typename F>
void read_order(F f)
{
    bool is_prepared = read_bool();
    if(is_prepared)
        f(Order<true>{});
    else
        f(Order<false>{});
}
// Example of usage:
{
    read_order([](auto order)
    {
        use(order)
    });
}

variant<Order<true>, Order<false>> read_order()
{
    bool is_prepared = read_bool();
    if(is_prepared)
        return Order<true>{};
    else
        return Order<false>{};
}
// Example of usage:
{
    auto x= read_order();
    // ...
    apply(x, [](auto order)
    {
        use(order)
    });
}

M>>>Отлавливается первым же залетным тестом

M>В зависимости от реализации, типы тоже могут нифига не спасти

M>Ну, с нашей стороны приходит валидный объект, генерируется валидный JSON, но в какой-то момент все ломается Принимающая сторона решила, что теперь поле X должно быть не числом, а строкой

M>100% покрытие типами вообще не дает никакой гарантии, что код вообще правильный

M>Могу только повторить. У нас самые главные проблемы — это бизнес-логика, а не несоответсвие килограммов с километрами

M>В общем, этот рассказ не столько против типов, сколько про то, что типы наверняка помогут сделать правильный DSL. Но потом в этот DSL начинает приходить все, что угодно, и вылетать оно будет, как назло, в рантайме

#include <stdexcept>
#include <iostream>
using namespace std;

enum class OrderType {Unknown, OnlyDecrease, Constant};
template<OrderType Type>
struct Order{
    const int amount;
    const bool sent;
    const bool risk;
};

template<OrderType Type> auto RiskOrder(const Order<Type>& o) {return Order<OrderType::Constant>{o.amount, o.sent, true};}
template<OrderType Type> auto SendOrder(const Order<Type>& o) {return Order<Type==OrderType::Unknown?OrderType::OnlyDecrease:Type>{o.amount, true, o.risk};}
template<OrderType Type> auto Increase(const Order<Type>& o, int v)
{
    static_assert(Type==OrderType::Unknown, "You can not increase this order");
    if(o.sent||o.risk) throw invalid_argument("You can not increase this order");
    else return Order<Type>{o.amount+v, o.sent, o.risk};
}
template<OrderType Type> auto Decrease(const Order<Type>& o, int v)
{
    static_assert(Type!=OrderType::Constant, "You can not decrease this order");
    if(Type==OrderType::Unknown&&o.risk) throw invalid_argument("You can not decrease this order");
    else return Order<Type>{o.amount-v, o.sent, o.risk};
}
template<OrderType Type, typename F> void ProcessOrder(const Order<Type>& o, F f)
{
    cout<<"Process order:\t"<<o.amount<<'\t'<<o.sent<<'\t'<<o.risk<<endl;
    try{
        auto r=f(o);
        cout<<"Result order:\t"<<r.amount<<'\t'<<r.sent<<'\t'<<r.risk<<endl;
    }catch(const exception& e) {cout<<e.what()<<endl;}
}

int main()
{
    ProcessOrder(Order<OrderType::Unknown>{100, false, false}, [](auto o){//нормально отрабатывает
        auto o1=Increase(o, 10);
        auto o2=SendOrder(o1);
        return Decrease(o2, 20);
    });
    ProcessOrder(Order<OrderType::Unknown>{100, true, false}, [](auto o){//вылетает с исключением в рантайме - плохой входящий ордер для такого алгоритма
        auto o1=Increase(o, 10);
        auto o2=SendOrder(o1);
        return Decrease(o2, 20);
    });
    ProcessOrder(Order<OrderType::Unknown>{100, false, false}, [](auto o){//некомпилируется - компилятор видит ошибку в бизнес логике алгоритма
        auto o1=Decrease(o, 20);
        auto o2=SendOrder(o1);
        return Increase(o2, 10);
    });
}

Так ведь дело-то в том, что проверку-то ты вставишь, а дальше-то что делать будешь с результатом этой проверки? что в check должно происходить? исключение? ведь надо же как-то наверх сообщить, что облом?

http://rsdn.ru/forum/philosophy/5942238.1

Автор: D. Mon
Дата: 03.02.15

M>>Ну и потому что проблемы типов обычно — мизерная часть собственно проблем в коде. У нас в команде вот за год появился первый тикет, который напрямую связан с ошибкой типов. Все остальные проблемы — это логика.
DM>Ну вот сторонники продвинутых (или хотя бы приличных) систем типов как раз и ратуют за смещение этой границы, чтобы как можно больше логики кодировать в типах и проверять компилятором.

http://rsdn.ru/forum/philosophy/5942554.1

Автор: D. Mon
Дата: 03.02.15

M>>Действительно, ведь раз логика закодирована типами, она перестает быть логикой, ага, и никогда не может быть неверной.
DM>Зачем клоуна строишь? Ничего подобного я не говорил и не имел в виду.

http://rsdn.ru/forum/philosophy/5942643.1

Автор: Klapaucius
Дата: 03.02.15

K>>>Проверки типов.
M>>Которая поможет мне с логическими ошибками... как?
K>Так, что некоторые классы ваших логических ошибок будут приводить к ошибкам компиляции.

http://rsdn.ru/forum/philosophy/5942697.1

Автор: D. Mon
Дата: 03.02.15

DM>Я не говорю, что абсолютно все проблемы выявляются любой системой статических типов. Лишь некоторые. И чем выразительней эта система и чем удачнее применяется, тем больше проблем выявляется при компиляции.

http://rsdn.ru/forum/philosophy/5943020.1

Автор: Evgeny.Panasyuk
Дата: 03.02.15

EP>Пытаться же запихнуть всю-всю логику в типы — контрпродуктивно, само собой нужен баланс. Как уже неоднократно отмечали выше — типы помогают обнаруживать только некоторые классы ошибок.
EP>Неплохим примером является кодирование единиц измерения и размерности в тип. Например Mars Climate Orbiter распался в атмосфере Марса из-за того, что разные модули по ошибке использовали разные единицы измерения.

Вот тут как раз и поможет компилятор — как раз с ad-hoc изменениями требований.

типы вводятся не для легкости, а для корректности.

state_allows_increment(state) &&
risk_check_allows_increment() &&
config_allows_increment(config, amount, delta) &&
(!shop_policy_applies(state) || shop_policy_allows_increment()) &&
(!bank_nonshipped_policy_applies(state) || bank_allows_nonshipped_increment() &&
(!bank_shipped_policy_applies(state) || bank_allows_shipped_increment(delta) && bank_capture(amount + delta))

to_json :: Object -> string

если заказ помечен как кредит

если заказ помечен как удаленный

если заказ помечен как пассивный

если заказ помечен как замороженный

если заказ помечен как предоплата

если заказ помечен как оплаченный по предоплате

если в заказе нет товаров, которые можно вернуть

если это аггрегированный заказ с прошедшим сроком оплаты

если это архивный заказ при условии, что он оплачивается через account

если сумма увеличивается, а это запрещено настройками заказа

если сумма увеличивается, а мы уже отослали запрос на оплату в банк клиента

если сумма увеличивается на сумму большую, чем указано в настройках (относительно оригинальной суммы заказа)

если сумма увеличивается, а заказ проведен через новую систему

если мы возвращаем деньги клиенту, заказ находится в одном из трех статусов, не является кредитом, и возвращаемая сумма меньше, чем максимальная разрешенная к возврату сумма

J>Не очень понятно, что должно было продемонстрировать твое решение в лоб, кроме того, что задачу можно решить в лоб

Для спортивности: не смотрите в следующий шаг, пока не реализован первый шаг.

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

EP>В таких случаях пытаться встроить контракт/предусловие в систему типов вполне имеет смысл

Не очень понятно, что должно было продемонстрировать твое решение в лоб, кроме того, что задачу можно решить в лоб
В этом никто и не сомневался, вообще-то.

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

Они решают задачу бана неправильного кода, где правильность закодирована в определении. У тебя такого бана нету. Можно проверить is_forbidden и тут же дернуть update_amount, и компилятор и не почешется на эту тему, и останется только уповать на тесты.

как можно больше логики кодировать в типах и проверять компилятором. Чем меньше твой язык позволяет выразить типами, тем меньше у тебя ошибок с типами и тем больше ошибок "в логике", это естественно.

Для типов есть легковесная верификация, в случае их отсутствия не все так радужно. Она не перестает быть логикой, она представляется в форме, которая хорошо подходит для автоматической проверки.

Поможет тем, что вы можете делать описание чего-то корректным по построению, например. Т.е. сделать нежелательное состояние непредставимым в виде значения.

Мой пример тривиален, но можно ведь придумать типы и поинтереснее

Вот тут как раз и поможет компилятор — как раз с ad-hoc изменениями требований.

А если ты новое требование закодируешь в типе, то за тем, что ты посетил все 1024 места, проследит компилятор, и он просто не скомпилирует твою программу, пока ты не разберешься со всеми 1024 местами, причем пока не разберешься так, что компилятор будет удовлетворен.
Собственно, в этом весь смысл.
Типы не делают программирование легче и короче, они делают его надежнее и безопаснее.

M>Ты придумал себе какие-то внутренние и внешние проверки В общем, то, о чем я говорил:

M>

http://rsdn.ru/forum/philosophy/5943418.1

Автор: Mamut
Дата: 04.02.15

M>

M>- Есть заказ.
M>- Пока заказ не помечен, как отправленный, можно уменьшать и увеличивать сумму заказа
M> ...
M>

http://rsdn.ru/forum/philosophy/5943812.1

Автор: AlexRK
Дата: 04.02.15

ARK>

ARK>  function SendOrder(order: UnsentOrder): SentOrder is
ARK>    ...
ARK>  end;
ARK>  function ChangeOrderSum(order: UnsentOrder, newSum: Money): UnsentOrder is 
ARK>  // эту функцию нельзя вызвать для заказа, у которого Sent равно true!
ARK>    ...
ARK>  end;
ARK>

EP>>В таких случаях пытаться встроить контракт/предусловие в систему типов вполне имеет смысл

template<typename Order>
enable_if_t<Order::is_activated && Order::is_auth_only> foo(Order order)
{
    do_capture(order);
}

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

EP>В предыдущей теме, в некоторых местах

Автор: Mamut
Дата: 03.02.15

разговор шёл именно о предварительных проверках, а не внутренних:

But I discovered that in the presence of SelfTestingCode, most bugs that static types would have were found just as easily by the tests. Since the tests found much more than type errors, you needed them in either a static or dynamically typed language, so having the static typing gave you little gain.

J> Особенно виртуозно тебе удаются подмена тезиса и ингорирование аргументов, аплодисменты.

Вот тут как раз и поможет компилятор — как раз с ad-hoc изменениями требований.

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

как можно больше логики кодировать в типах и проверять компилятором.

Для типов есть легковесная верификация, в случае их отсутствия не все так радужно. Она [логика] не перестает быть логикой, она представляется в форме, которая хорошо подходит для автоматической проверки.

Вот я не понимаю. Спрашиваешь вопрос про любой язык программирования — тебе и ответят, и примеры покажут, и ссылки подкинут — все, что угодно. Как только дело доходит до апологетов «типы везде, они рулят», все, тишина, одна демагогия на пять страниц ответов

IT>Типы — это дополнительный уровень верификации кода на самых ранних этапах возникновения проблемы. Те же юнит-тесты ловят последствия, типы позволяют устранить причину. Мне вообще странно слышать подобные разговоры от людей с опытом. То, что вы у себя в конторе научились есть кактус и при этом не сильно колоться, говорит лишь о вашем упёрстве и пониженном болевом пороге. Это очень круто. Примерно так же круто, как в цирке глотать шпаги или совать голову в пасть хищнику. И если бы вы со своим кактусом выступали в цирке, то я бы аплодировал стоя. Но в жизни то это нафига нужно?

Тебе в каждом сообщении мерещатся только тонны текста

EP>А так получится явно более громоздко чем твой вариант

HTTP 400 Bad Request
Content-Type  application/vnd.klarna.com.error-v2+json

{
  "message": "An error has occured. Please try again later",
  "developer_message": "Field order.billing_address.zip must be a string",
  "error_location": "/order/0/billing_address/zip"
}

M>>Могу только повторить. У нас самые главные проблемы — это бизнес-логика, а не несоответсвие килограммов с километрами

M>>В общем, этот рассказ не столько против типов, сколько про то, что типы наверняка помогут сделать правильный DSL. Но потом в этот DSL начинает приходить все, что угодно, и вылетать оно будет, как назло, в рантайме

В итоге доходит до смешного. Абсолютно все пользователи нашего API имеют такую же JSON Schema, как и мы (все получают их из одного центрального места). Но потом приходит письмо типа «пацаны, мы вам все присылаем правильно, а оно не работает, посмотрите, в чем ошибка». А ошибка, которую они получают, выглядит типа так:

HTTP 400 Bad Request
Content-Type  application/vnd.klarna.com.error-v2+json

{
  "message": "An error has occured. Please try again later",
  "developer_message": "Field order.billing_address.zip must be a string",
  "error_location": "/order/0/billing_address/zip"
}

to_json :: Object -> string
to_json(Object) ->
   "выплевываем правильно сформированный JSON."