On 26 Jun 2015 at 10:42, Andrzej Krzemienski wrote:
monad is now space optimal, consuming as little as two bytes depending on configuration. monad<void> is now working, plus these new specialisations were added:
* result<T>: empty/T/error_code (no exception_ptr).
To what run-time condition does an empty state correspond here? I used to thing that you either have a result (T) or a reason why you do not have one (error_code), but what does it mean that you have neither?
From a non-semantic perspective, avoiding exception_ptr has *BIG* benefits to runtime overhead because exception_ptr forces a memory barrier, which is why MSVC spews ~2000 opcodes every time you use it. Some of the time in promise-future you really don't require the ability to transport arbitrary exceptions because an error_code is enough, or maybe even no error transport is needed at all. Why
Semantically speaking, after feedback from this list, and having
attended Charley's C++ Now Presentation on ternary logic programming
"Your CPU is Binary", I realised that it's worthwhile to formally
specify future/monad/result as ternary logic primitives with ternary
logic operators. option<T> remains boolean. This gives the following
logic table:
Empty => False (future/monad/result/option)
Errored/Excepted => Indeterminate (future/monad/result)
Value => True (future/monad/result/option)
In other words, you never draw a distinction between errored and
excepted. They are semantically equivalent. Therefore not being
possible to be excepted in the case of result<T> means nothing, it's
simply a quality of implementation detail.
therefore pay for an exception transport when you don't need it? In
AFIO any time we go near OS APIs we currently convert the system
error code into an exception and throw it - this is total overkill.
Using result<T>, any time AFIO calls OS APIs it can exactly and
precisely wrap the outcome into a result<T> and not expend overhead
on unnecessary exception_ptr costs. Only if downstream code consumes
the result without checking for an error will a lazy conversion to an
exception throw occur.
This is why I hope these lightweight promise-futures will be
lightweight enough to promise-future a SHA256 round inside a budget
of 40 cycles because you can disable all error transport entirely,
and effectively just promise an async_optional