Re: Checking for nil return

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 }