Been thinking about this, and checked out the Rakudo repository to peek into the source.
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 shows what I think is a less-than-awesome specification, and I am curious about the reasoning behind it being defined as valid sub a( --> Int:D ) { return Nil } -y On Sun, Dec 20, 2020 at 7:18 PM Brad Gilbert <b2gi...@gmail.com> wrote: > Nil is always a valid return value regardless of any check. > > This is because it is the base of all failures. > > On Sat, Dec 19, 2020, 8:17 PM yary <not....@gmail.com> wrote: > >> Is this a known issue, or my misunderstanding? >> >> > subset non-Nil where * !=== Nil; >> (non-Nil) >> > sub out-check($out) returns non-Nil { return $out } >> &out-check >> > out-check(44) >> 44 >> > out-check(Nil) >> Nil >> >> ^ Huh, I expected an exception on "out-check(Nil)" saying the return >> value failed the "returns" constraint. >> >> The subtype works as I expect as an the argument check >> >> > sub in-check (non-Nil $in) { $in } >> &in-check >> > in-check(33) >> 33 >> > in-check(Nil) >> Constraint type check failed in binding to parameter '$in'; expected >> non-Nil but got Nil (Nil) >> in sub in-check at <unknown file> line 1 >> in block <unit> at <unknown file> line 1 >> >> $ raku --version >> This is Rakudo version 2020.07 built on MoarVM version 2020.07 >> implementing Raku 6.d. >> >> Is this my understanding of return type checking that's off, or a known >> issue, or something I should add to an issue tracker? >> >> -y >> >
