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 } >
