Make 'return;' *actually* return

[hoelzro]

No description provided.

[jnthn]

This way ends up with us having different code paths for return with an argument and return without. Furthermore, it means that the places you can use one or the other are different (anywhere a term is valid for the existing prefix, vs. top level statement for the other case).

I think the righter answer is to unify both, as a term:sym that optionally takes an argument (parsed with ? or so).

[pmichaud]

I agree, I prefer a single path and not separate ones.
Also, are there (m)any cases where NQP really needs a bare return?

Pm

On Wed, Sep 18, 2013 at 07:24:35AM -0700, Jonathan Worthington wrote:

This way ends up with us having different code paths for return with an argument and return without. Furthermore, it means that the places you can use one or the other are different (anywhere a term is valid for the existing prefix, vs. top level statement for the other case).

I think the righter answer is to unify both, as a term:sym that optionally takes an argument (parsed with ? or so).

---

Reply to this email directly or view it on GitHub:
#127 (comment)

[hoelzro]

I would also prefer a single return path, but I didn't have the know-how to do it. NQP doesn't really need a bare return, but the problem I encountered that motivated me to do this was something like this:

sub my-sub() {
  say('here');
  return;
  say('there');
}

When I tried this over the weekend (for debugging reasons), the return was simply skipped over, leading to much confusion on my part. It took me a while to figure out what was going on, and I wanted to spare future NQP developers that confusion.

[pmichaud]

Then perhaps

NQP 'return' requires an argument at line ...

That can be done in the existing grammar rule without too much
difficulty. :-)

Pm

[jnthn]

@pmichaud the "return needs an argument" thing does catch people out. Even me. :-) So we should fix it, really. We can't so easily detect it with the exist grammar rule 'cus it parses as a prefix operator. I mean, we could do a lookahead like <!before <.ws> <[;}]>> or so...but that feels a little icky..

[pmichaud]

@jnthn then yes, switching return to be a term with an optional argument can work also, I suppose.

At any rate, I prefer only one code path for parsing 'return', however it ends up.

[arnsholt]

@jnthn Wouldn't something like term:sym<return> { <sym> <EXPR>? } allow a construct like foo(return 1)?

[pmichaud]

@arnsholt Yes, foo(return 1) is valid Perl 6.

[arnsholt]

Oh, in that case it's perfectly okay of course. Are the semantics of foo(return 1) different from those of return 1, or are they identical?

[jnthn]

Identical. Note that while that's not the most useful example, useful is like $alright || return 'åhnejs'; or so.