Bug 17344 - After x <- numeric(0); x[logical(0)] <- character(0) , x is not coerced
Summary: After x <- numeric(0); x[logical(0)] <- character(0) , x is not coerced
Status: CLOSED FIXED
Alias: None
Product: R
Classification: Unclassified
Component: Language (show other bugs)
Version: R 3.3.*
Hardware: All All
: P5 normal
Assignee: R-core
URL:
Depends on:
Blocks:
 
Reported: 2017-09-23 09:53 UTC by Suharto Anggono
Modified: 2017-11-21 09:59 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Suharto Anggono 2017-09-23 09:53:07 UTC
From "Details" section in Extract.Rd :
When an index expression appears on the left side of an assignment (known as subassignment) then that part of x is set to the value of the right hand side of the assignment.  In this case no partial matching of character indices is done, and the left-hand-side is coerced as needed to accept the values.  For vectors, the answer will be of the higher of the types of x and value in the hierarchy raw < logical < integer < double < complex < character < list < expression.


Example from Bug 17200 Comment 5:
mmm <- numeric(0)
mmm[logical(0)] <- character(0)
mmm

Output:
numeric(0)

Expected output:
character(0)

I expect that 'mmm' will be coerced to character.


Example from Bug 17200 Comment 6, that gives the result that I expect:
mmm <- numeric(0)
mmm[logical(0)] <- ""
mmm

Output:
character(0)


It seems that this part of function 'do_subassign_dflt' in subassign.c gives the effect.
    else if (xlength(x) == 0) {
	if (xlength(y) == 0) {
	    UNPROTECT(1);
	    return(x);
	}

It is still like that in R devel r73338.
Comment 1 Martin Maechler 2017-11-11 15:20:44 UTC
I tend to agree with your assessment.  .. and indeed it's the place in the C source code you mention.

I will run checks to see if the change has no unexpected side effects..
Comment 2 Martin Maechler 2017-11-11 17:15:45 UTC
(In reply to Martin Maechler from comment #1)
> I tend to agree with your assessment.  .. and indeed it's the place in the C
> source code you mention.
> 
> I will run checks to see if the change has no unexpected side effects..

I did not find any (only 'make check-all', i.e. checking base & recommended packages).

One thing, this code

x <- numeric(); x[1] <- character()

in current versions of R  leaves 'x' unchanged as well.

With the change, the above would / will give an error

> x <- numeric(); x[1] <- character()
Error in x[1] <- character() : replacement has length zero
> 

which of course *may* trigger problems in places where previous code had relied on the current no-op behavir in no-edge cases.

So, even if nobody comments, I'd wait a few days before committing such a change - and would not port the change to "R patched".
Comment 3 Luke Tierney 2017-11-12 12:44:27 UTC
Not sure exactly what change you are considering, but with just disabling the early return

x <- numeric(); x[1] <- numeric()

(i.e. no type change) would also produce an error. It does not now.
Maybe it should, but it would be better to think this through and test
against CRAN before proceeding. Or adjust the documentation, which may be the better use of time unless there is a really compelling argument for adjusting the code.
Comment 4 Martin Maechler 2017-11-21 09:59:48 UTC
(In reply to Luke Tierney from comment #3)
> Not sure exactly what change you are considering, but with just disabling
> the early return
> 
> x <- numeric(); x[1] <- numeric()
> 
> (i.e. no type change) would also produce an error. It does not now.

> Maybe it should,

I don't think it should, and my change did not change the above.
I've committed it now to R-devel only as svn rev 73758

>  but it would be better to think this through and test
> against CRAN before proceeding. Or adjust the documentation, which may be
> the better use of time unless there is a really compelling argument for
> adjusting the code.