Moving the "can't catch Nil return, why is Nil also a failure?" question to
a Raku issue, https://github.com/Raku/doc/issues/3760
This got me going through Raku source code to see where Nil gets passed
through; this looks promising. rakudo/src/vm/moar/spesh-plugins.nqp line 308
# Allow through Nil/Failure
(nqp::istype($rv, Nil) || (nqp::istype($rv, $type) &&
...
Mostly for my own education, though if the discussion goes along the lines
of "let's make Nil not a failure" then I may look at a patch to make it so.
-y
On Wed, Dec 30, 2020 at 10:02 PM yary <not....@gmail.com> wrote:
> This commit shows where Nil expanded from being "Absence of a value" to,
> alternatively, "a benign failure". Unfortunately I haven't found discussion
> on "benign failure" β semantics, use case, prior art, example, that sort of
> thing β and the commit doesn't elaborate.
>
> https://github.com/Raku/doc/commit/2b3c920ae9c37d14f76ab1eab236df2ec4f513ec
>
> I added a comment to that commit, which is now nearly 5 years old. Would
> be good to get a follow up from the committer!
>
> -y
>
>
> On Tue, Dec 29, 2020 at 9:28 AM Ruud H.G. van Tol <rv...@isolution.nl>
> wrote:
>
>>
>> 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 }
>>
>
