[Rd] return (x+1) * 1000

[Duncan Murdoch]

On 20/11/2020 5:16 p.m., Henrik Bengtsson wrote:
> 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.

It's quite recent (August of this year):  see 
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17180.

Duncan Murdoch
> 
> /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]]
> 
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>