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
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 cert
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
I'm not thinking of complicated cases.
This happened to me in a function that returns 10 minute slots
slot <- function (seconds) {
return (seconds %/% 600) * 600
}
Obviously I found the issue while debugging and corrected my code with
surrounding parenthesis, but I was surprised that the R
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. Tho
On 20/11/2020 5:36 p.m., Mateo Obregón wrote:
I'm not thinking of complicated cases.
This happened to me in a function that returns 10 minute slots
slot <- function (seconds) {
return (seconds %/% 600) * 600
}
Obviously I found the issue while debugging and corrected my code with
surround
Perhaps the parser should warn if you use return() at all. It is rarely
needed and is akin to the evil 'GOTO' statement in that it makes the flow
of control less obvious to the reader.
-Bill
On Fri, Nov 20, 2020 at 2:37 PM Mateo Obregón
wrote:
> I'm not thinking of complicated cases.
>
> This
I don't see how anything operating on the "result" of a return() call could be
legal. The special semantics of the return() call is that it does **not**
return control to the place it was called from, but rather to the location
where its surrounding function(){} was called from.
Mateo.
--
Mat
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 thi
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 ne
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"))
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 s
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) wri
On 20/11/2020 5:58 p.m., Mateo Obregón wrote:
I don't see how anything operating on the "result" of a return() call could be
legal. The special semantics of the return() call is that it does **not**
return control to the place it was called from, but rather to the location
where its surrounding f
On Fri, Nov 20, 2020 at 02:48:11PM -0800, Bill Dunlap wrote:
> Perhaps the parser should warn if you use return() at all. It is rarely
> needed and is akin to the evil 'GOTO' statement in that it makes the flow
> of control less obvious to the reader.
My experience is contrary to this, using retu
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 wo
OK, you're way ahead of me. If this is in the QA tools, I guess I
don't really see the need to change the parser and/or the language to
flag it immediately?
On Fri, Nov 20, 2020 at 7:43 PM Duncan Murdoch wrote:
>
> On 20/11/2020 7:01 p.m., Ben Bolker wrote:
> >I may be unusual but I don't
17 matches
Mail list logo
