Basically, never mix error-state and return-value.
Rather use a different channel/dimension for each.
And any value itself can have special state too, like "absence" and (via
its type) "has-default".
On that docs-page, my stomach protested against the Nil/default pairing.
Now I need to think through why it (grumbled that it) is wrong.
(or not wrong: for performance reasons, it is good to support values
that can never be undefined)
-- Ruud
On 2020-12-28 22:35, yary wrote:
[...]
Allowing Failure as a return always makes sense to me– every block needs
to be capable of passing along a failure, that's how the language is
designed.
On the other hand, Nil is not a Failure. Conceptually it is a lack of an
answer, similar to SQL's null concept.
What's the usefulness of having Nil skip return type checking-
specifically Nil and not its Failure descendents?
This example under https://docs.raku.org/type/Nil
<https://docs.raku.org/type/Nil> shows what I think is a
less-than-awesome specification, and I am curious about the reasoning
behind it being defined as valid
suba( -->Int:D ) { return Nil }
