return (x+1) * 1000

On 20/11/2020 7:01 p.m., Ben Bolker wrote:

   I may be unusual but I don't find these examples surprising at all/
I don't think I would make these mistakes (maybe it's easier to make
that mistake if you're used to a language where 'return' is a keyword
rather than a function?

    My two cents would be that it would make more sense to (1) write
code to detect these constructions in existing R code (I'm not good at
this, but presumably "return() as anything other than the head of an
element of the body of a function" would work?)

No, it's commonly nested within an if() expression, and could appear
anywhere else.

  (2) apply it to some

corpus of R code to see whether it actually happens much;

I did that, in the bug report #17180 I cited.  In 2016 it appeared to be
misused in about 100 packages.

(3) if so,

add the test you wrote in step 1 to the QA tools in the utils
package/CRAN checks.

That was done this year.

Duncan Murdoch

On Fri, Nov 20, 2020 at 6:58 PM Henrik Bengtsson
<henrik.bengtsson at gmail.com> wrote:

Without having dug into the details, it could be that one could update
the parser by making a 'return' a keyword and require it to be
followed by a parenthesis that optionally contains an expression
followed by end of statement (newline or semicolon).  Such a
"promotion" of the 'return' statement seems backward compatible and
would end up throwing syntax errors on:

function() return
function() return 2*x
function() return (2*x) + 1

while still accepting:

function() return()
function() return(2*x)
function() return((2*x) + 1)

Just my two Friday cents

/Henrik

On Fri, Nov 20, 2020 at 3:37 PM D?nes T?th <toth.denes at kogentum.hu> wrote:

Yes, the behaviour of return() is absolutely consistent. I am wondering
though how many experienced R developers would predict the correct
return value just by looking at those code snippets.

On 11/21/20 12:33 AM, Gabriel Becker wrote:

And the related:

     > f = function() stop(return("lol"))

     > f()

     [1] "lol"


I have a feeling all of this is just return() performing correctly
though. If there are already R CMD CHECK checks for this kind of thing
(I wasnt sure but I'm hearing from others there may be/are) that may be
(and/or may need to be) sufficient.

~G

On Fri, Nov 20, 2020 at 3:27 PM D?nes T?th <toth.denes at kogentum.hu
<mailto:toth.denes at kogentum.hu>> wrote:

     Or even more illustratively:

     uneval_after_return <- function(x) {
         return(x) * stop("Not evaluated")
     }
     uneval_after_return(1)
     # [1] 1

     On 11/20/20 10:12 PM, Mateo Obreg?n 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.
      >
      > ______________________________________________
      > R-devel at r-project.org <mailto:R-devel at r-project.org> mailing list
      > https://stat.ethz.ch/mailman/listinfo/r-devel
      >