[Rd] No error when assigning values to an "empty" vector/matrix/array

[Hervé Pagès]

Hi,

On 10/24/2014 06:58 AM, S Ellison wrote:
>>> Also note that these warnings or errors are complaining that the
>>> number of items to replace (left length) is not a multiple of
>>> replacement length (right length). This suggests that when the left
>>> length is a multiple of the right length, everything is fine.
>>> And this is actually the case when the left length is 0. Because
>>> 0 is a multiple of anything. So in that case, the right value is
>>> truncated to length 0 and no warning is issued. Makes sense to me.
>>
>> Thanks Hervé, you gave the perfect explanation/rationale for this being
>> consistent.
>
> This explains why a check for exact multiple of replacement length does not trigger a warning, but surely that is not sensible in the length 0 case. In all other cases, this check warns when there will be truncation of the replacement, and that seems to me the sensible intent of the check. A silent truncation to nothing is surely not the intended behaviour.

Yes truncation should not be silent. But truncation to length zero
should not be seen as a special case either. What would be more
sensible is that [<- recognizes the 2 distinct situations that
deserve a warning:
   1. Truncation (i.e. when left length is < right length).
   2. Left length is > right length AND left length is not a multiple
      of right length.
Then the warning we get should be clear about which situation was
detected. So we would get a sensible warning all the time, even
when left length is 0.

H.

> I can't help feeling that the 'check for multiple of length' was a neat portmanteau check for several possible problems when recycling is allowed, but that the possibility of assigning to a length 0 object was not considered.
>
> I'd suggest logging it as an issue to for R-core to at least look at and either to fix or to at least warn of in documentation.
>
> S Ellison
>
>
>
>
> *******************************************************************
> This email and any attachments are confidential. Any u...{{dropped:26}}