потому и N/A

это просто комбинаторы операций, которые когда-то выполнятся, когда фича, над которой они оперирует, закончит работу. Фичи не могут быть pull-based потому, что это pure fabrication над уже выполняемой работой. Если ты хочешь pull-based — комбинируй свой pull-based через CompletableStage интерфейс

Тоесть, ты форкнул поток исполнения — у тебя есть хендл на форк — фьюча, если ты только планируешь форкнуть и хочешь накомбинировать — юзай таски

> Фичи не могут быть pull-based потому, что они не pull-based

Это как-то отменяет то, что делать фьючи не ленивыми это, как минимум, очень спорное решение?

нет, не спорное, фьючи по определению это уже то, что исполняется

если что-то ещё не исполняется, это таска, а не фьюча

А где можно такое определение найти? Это выходит, что фьючи в расте — не фьючи?

не знаю, как там в расте фьючи работают и кто их так называл. Смотри, если у тебя есть задача, которую надо выполнить — она так и называется — Task, задача ещё не выполняется, или уже выполняется, или она уже выполнена, но это само определение задачи — ЧТО надо сделать. Future — это результат отправки задачи на исполнение. Тоесть, когда у тебя есть задача и ты отправляешь её исполняться — с помощью этого хендла в момент 0+T от получения фьючи ты можешь получить результат. Имея только задачу — ты не получишь результат, пока не выполнишь её. Имея фьючу ты получишь результат тогда, когда он тебе нужен будет, не парясь, когда именно он исполнялся и исполнялся ли, мб его просто сразу тебе уже готовым отдали. Если тебе нжуно что-то ленивое — есть Callable. Просто вызываешь его, когда тебе нужно посчитать.

Надеюсь, расскажешь мне, зачем нужны ленивые фьючи и чем они отличаются от () -> T

> The evaluation strategy of futures, which may be termed call by future, is non-deterministic: the value of a future will be evaluated at some time between when the future is created and when its value is used, but the precise time is not determined beforehand and can change from run to run. The computation can start as soon as the future is created (eager evaluation) or only when the value is actually needed (lazy evaluation), and may be suspended part-way through, or executed in one run. Once the value of a future is assigned, it is not recomputed on future accesses; this is like the memoization used in call by need.

> A lazy future is a future that deterministically has lazy evaluation semantics: the computation of the future's value starts when the value is first needed, as in call by need. Lazy futures are of use in languages which evaluation strategy is by default not lazy. For example, in C++11 such lazy futures can be created by passing the std::launch::deferred launch policy to std::async, along with the function to compute the value.

Как зачем, чтобы апликэйшны на асинхронном IO строить.

ну это самое простое

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

ну простейший пример это бэкпрэшур

А корутины тогда что?

а вообще для eager фьюч слишком много мозгов надо, чтобы программировать

а тор тогда кто?

наоборот же

Ну я без иронии спрашивал

а так скомпозил фьючи между собой, засунул в экзекьютор и расслабился