> Is cheap (space) because it uses int instead of struct?
It uses a single byte, but yes.
> Is cheap (time) because it is passed by register requiring less cpu
> hops/cycles?
That too, yes.
> Translation is cheap because of time, space or verbosity?
Because translation is avoided.
> We will lose the exception effect tracking?
Well the document is not yet a proposal and the old-school exception system
remains. But yes, the new ErrorCode does not use effect tracking.
> What is the cost of an out even for integral types?
You lose a hardware register for the result which means larger code size and
more memory accesses. Since the proposed implementation is not hard to do for
us compiler writers, don't worry about it.
> How to avoid Future manual handling strategy?
By using `p(): Future {.raises: ErrorCode.}`? I don't understand the question.
> If Future was a ErrorCode with RetryError (ie getrandom with GRND_NONBLOCK),
> and ErrorCode was mutable (Atomic?), could we "wait" it become something
> different to read result? ...
What you describe is beyond the scope of a language mechanism but a
template/proc to `retry` an operation automatically based on the value of
ErrorCode is possible.
> Random thought, it sounds like Java Checked/Unchecked exceptions, I'm not
> sure if they are good or bad design. But are common source of confusion for
> sure.
The design is close to Java's indeed but ErrorCode does not support "unchecked"
exceptions.
