Re: Checking for nil return

[Joseph Brenner]

yary  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.

I'm seeing the same behavior that Yary does, and it does seem pretty peculiar.

I would guess it has to do with this behavior:

# https://docs.raku.org/type/Nil#index-entry-Nil_assignment

# When assigned to a container, the Nil value (but not any subclass
# of Nil) will attempt to revert the container to its default
# value; if no such default is declared, Raku assumes Any.

Something like: the Nil is getting transformed into an empty (Any),
which passes the constraint, but then gets turned back into a Nil
later.

Re: Checking for nil return

[yary]

After writing that email, I remembered a bit of logic from a class long
ago, that any assertion made on the empty set is true. Since Nil is a
representation of no results, it would make sense to have assertions about
it return true. I think this example shows an optimization to skip return
type checking on Nil, more than a container reverting to its default value.

In particular the error message on using Nil for "in-check (non-Nil $in)"
says "expected non-Nil but got Nil (Nil)" which is preserving the Nil, it
isn't complaining about Any. And in fact "Any" passes the in-check, as I
expect it to.

I suspect that the return value assertion in the signature is a
work-in-progress– in fact part of the reason this test uses "subset
non-Nil" is that having a "where" clause in the returns signature is
explicitly a TODO:

> sub returns-prime (Int $ident --> Int where *.is-prime) { $ident }
===SORRY!=== Error while compiling:
Cannot do non-typename cases of type_constraint yet

Thus I think that handling "Nil" in the return type checking is similarly
something that is going to be fixed. Though I am still not completely sure
due to the nature of Nil being a defined type object.

-y


On Sun, Dec 20, 2020 at 2:35 PM Joseph Brenner  wrote:

> yary  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.
>
> I'm seeing the same behavior that Yary does, and it does seem pretty
> peculiar.
>
> I would guess it has to do with this behavior:
>
> # https://docs.raku.org/type/Nil#index-entry-Nil_assignment
>
> # When assigned to a container, the Nil value (but not any subclass
> # of Nil) will attempt to revert the container to its default
> # value; if no such default is declared, Raku assumes Any.
>
> Something like: the Nil is getting transformed into an empty (Any),
> which passes the constraint, but then gets turned back into a Nil
> later.
>

Re: Checking for nil return

[Brad Gilbert]

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  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  line 1
>   in block  at  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
>