[Rcpp-devel] coercion NULL to vector

Jeff Newmiller jdnewmil at dcn.davis.ca.us
Wed Apr 18 17:31:58 CEST 2018


as.numeric( NULL ) is not silent, it is very explicit. 

Re this not being a C++ NULL, I don't object to R NULL being used that way (in fact it may be more sensible to do this than not, but it is not clear that R core thinks this way).

On April 18, 2018 9:53:12 AM CDT, Serguei Sokol <serguei.sokol at gmail.com> wrote:
>Le 18/04/2018 à 16:15, Jeff Newmiller a écrit :
>> Regarding:
>> 
>> "Actually, when NULL is provided to where a vector or a matrix is
>expected just an error is thrown. So we can hardly imagine that someone
>would have his program broken or will be misled if such coercion is
>introduced."
>> 
>> If all programs were perfect this would be true, but the ability to
>identify incorrect pointer initialization is an important feature for
>testing.
>> 
>> In the late '90s, some Internet Service Providers tried to "assist"
>users who typed bad site names into browsers by making failed DNS
>lookups redirect to a server prepared to supply an informative "were
>you looking for X?" web page. This caused significant disruption in
>non-user-interactive network protocols that relied on getting a failure
>notice for bad DNS lookups, and that idea had to go to the trash heap
>eventually.
>Interesting example but not really "parallel" to our situation.
>In R, we already have as.numeric(NULL) without such kind of
>catastrophe.
>I just propose an equivalent functioning in Rcpp.
>
>> 
>> I don't have failed code tests to offer for this, but the idea of
>silently replacing a C++ NULL with a valid value is anathema.
>It's not C++ NULL which is coerced (not "replaced") to a vector but R's
>one. And only where a vector of a given type is expected, not
>everywhere.
>
>I think there is a possible compromise.
>We can introduce an automatic coercion in #ifdef'ed blocks with e.g.
>RCPP_COERCE_NULL_TO_VECTOR and RCPP_COERCE_VECTOR_TO_MARIX optional
>macros.
>In such a way, those who want this feature can have it by defining
>these macros before including Rcpp.h and those who consider it as
>anathema can go a 
>traditional way of doing.
>
>Serguei.

-- 
Sent from my phone. Please excuse my brevity.


More information about the Rcpp-devel mailing list