[Rd] return (x+1) * 1000

Henrik Bengtsson henr|k@bengt@@on @end|ng |rom gm@||@com
Fri Nov 20 23:16:18 CET 2020


FWIW, 'R CMD check --as-cran' in R-devel checks for "bogus return"
statements but I think that's only for the case when one forgets the
parentheses, e.g. 'return' instead of 'return()'.

I don't think it catches this case but I'm also not sure. Though, I can
imagine it might be possible to enhance the current check to include also
this case.

It could be that setting _R_CHECK_BOGUS_RETURN_=true will enable this check
also in earlier versions in R; not sure when it was introduced.

/Henrik

On Fri, Nov 20, 2020, 13:58 Gabriel Becker <gabembecker using gmail.com> wrote:

> 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 using 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.
> >
> > ______________________________________________
> > R-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]



More information about the R-devel mailing list