D, Go и Rust, взлетит ли что-нибудь?

Это у вас None будет информировать об ошибке-то?

Это у вас None будет информировать об ошибке-то?

а почему нет? если у вас operator| принимает сущность IPipe с функцией bool valid() const то что ему мешает проверять аргументы на валидность? если же он у вас всеяден, то да только эксепшены.

В плюсах вообще не обязательно иметь IPipe с функцией bool valid(). Это может быть объект типа L с R operator()(M&), где L — это анонимный тип, сгенерированный самим компилятором.

В плюсах вообще не обязательно иметь IPipe с функцией bool valid(). Это может быть объект типа L с R operator()(M&), где L — это анонимный тип, сгенерированный самим компилятором.

тем не менее суть моего предложения, надеюсь, понятна.

тем не менее суть моего предложения, надеюсь, понятна.

Понятна. Это ничем не отличается от того, что я сказал выше: «Это всего лишь будет означать перемещение всех if(r.error) из одного места конструирования конвейера в разные места.» Просто «разные места» вы объединили в один оператор|.

Однако, после того, как этот operator| отработает, его возвращаемое значение ведь все равно нужно будет обработать. Так что в случае, если ошибок не было, то проход по всем if-ам состоится в обязательном порядке.

И это не говоря уже о том, что если в месте конструирования pipeline мы не можем обработать ошибку, то нам нужно будет экземпляр Maybe/Either отдавать наверх. Т.е. писать что-то вроде:

either<ok, error> process_input(input_stream input)
{
  auto r = input.get_message_stream() | filter(...) | ...;
  match(r) {
    case pipeline :
      return pipeline.run();
  }
  return r;
}

void process_input(input_stream input)
{
  auto pipeline = input.get_message_stream() | filter(...) | ...;
  pipeline.run();
}

Это у вас None будет информировать об ошибке-то?

Кто мешает вместо None использовать объект (структуру) любой сложности?

Кто мешает вместо None использовать объект (структуру) любой сложности?

Ну так в исключениях именно это и происходит. И не нужно протаскивать эти структуры через сигнатуры функций.

Ну так в исключениях именно это и происходит. И не нужно протаскивать эти структуры через сигнатуры функций.

вот только в том же окамловском Async'e ловить исключения нужно специальным костылем. в других языках думаю ситуация похожая.

вот только в том же окамловском Async'e ловить исключения нужно специальным костылем. в других языках думаю ситуация похожая.

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

И не нужно протаскивать эти структуры через сигнатуры функций.

Дык это не просто протаскивание структур. Either, как и все монады, обладает семантикой «последовательных вычислений с контекстом». Т.е.:

- все вычисления, связанные друг с другом в «конвейер», гарантированно выполнятся, нет нарушений или прерываний control flow;

- если вместо тупого None / Left <error> чуть усложнить контекст, то появляется возможность неявно накапливать информацию с каждого шага «конвейера». Например, если ошибки возможны на каждом этапе некоторого вычисления, то есть возможность собрать их все в одну коллекцию без того, чтобы городить вложенные try/catch и т.д.

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

функции в Async'e шедулятся, а не напрямую вызываются. например:

g >>= f >>= h

запланирует g, когда результат ее вычисления будет доступен то будет запланирована f с аргументом равному возвращенному значению из g и т.д. так вот, try g >>= f >>= h with _ -> ... тут не отработает, т.к. экспешен бросится внутри шедулера. поэтому в async'e есть костыль в виде try_with который протащит эксепшн из шедулера.

все вычисления, связанные друг с другом в «конвейер», гарантированно выполнятся, нет нарушений или прерываний control flow;

Кем это гарантируется? Вот, например, фрагмент только что написанного кода:

while( m_active_requests.size() < requests )
{
	auto id = ++m_last_id;
	m_active_requests[ id ] = request_smart_ptr_t(
		new request( so_direct_mbox(), id, random( 10, 500 ) );
}

Так кто сможет гарантировать отсутствие хотя бы bad_alloc-а в run-time?

- если вместо тупого None / Left <error> чуть усложнить контекст, то появляется возможность неявно накапливать информацию с каждого шага «конвейера».

Какой-то хитрый конвейер. С предыдущего шага нормальное значение должно приходить, а не ошибка.

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

Пусть значение + что-то возвращается в виде тупла.

Вот у тебя и получилось полмонады :)

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

полмонады

Звучит как грязное ругательство.