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.bengts...@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.de...@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.de...@kogentum.hu
<mailto:toth.de...@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@r-project.org <mailto:R-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
______________________________________________
R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
