[Rd] return (x+1) * 1000

[Ben Bolker]

  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?) (2) apply it to some
corpus of R code to see whether it actually happens much; (3) if so,
add the test you wrote in step 1 to the QA tools in the utils
package/CRAN checks.

On Fri, Nov 20, 2020 at 6:58 PM Henrik Bengtsson
<henrik.bengtsson using 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 using 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 using kogentum.hu
> > > <mailto:toth.denes using 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 using r-project.org <mailto:R-devel using r-project.org> mailing list
> > >      > https://stat.ethz.ch/mailman/listinfo/r-devel
> > >      >
> > >
> > >     ______________________________________________
> > >     R-devel using r-project.org <mailto:R-devel using r-project.org> mailing list
> > >     https://stat.ethz.ch/mailman/listinfo/r-devel
> > >
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel