return (x+1) * 1000

Hi all,

I can confirm this occurs for me as well.

The one thing that comes to mind is that there are certain larger
expressions that contain calls to return which we absolutely don't want to
be an error, e.g

if(somestuff)
    return(TRUE)


That said, the actual expression Mateo pointed out certainly does look like
an error (it definitely isn't going to do what the developer intended).

I haven't looked at the parser much, to be honest. I assume there is
perhaps enough differentiation of if/else that return() could be allowed
within that but not inside a larger expression without it?

There would be things that are legal (though horrifying) now that would
stop working though, such as:

f = function(a) {

    ret = switch(a,

                 "1"= return("haha got 1!"),

                 "2" = "regular ole 2")

    ret

}


Whether it would be a problem or not that such insanity wouldn't work is
less clear. Are there valid non-if embedded return() cases that are
important to allow? If so (and if they're not differentiated by the parser,
which I somewhat doubt switch is, for example, though I'm not certain), I'm
skeptical we'd be able to do as he suggests.

It does seem worth considering though. If it can't be a hard parse error
but we agree many/most cases are problematic, perhaps adding detecting this
to the static checks that R CMD CHECK performs is another way forward.

Best,
~G

On Fri, Nov 20, 2020 at 1:34 PM Mateo Obreg?n <obregonmateo at gmail.com>

wrote:

Dear r-developers-

After many years of using and coding in R and other languages, I came
across
something that I think should be flagged by the parser:

bug <- function (x) {

     return (x + 1) * 1000

}

bug(1)

[1] 2

The return() call is not like any other function call that returns a value
to
the point where it was called from. I think this should straightforwardly
be
handled in the parser by flagging it as a syntactic error.

Thoughts?

Mateo.
--
Mateo Obreg?n.