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. 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. On April 18, 2018 8:59:19 AM CDT, Dirk Eddelbuettel <e...@debian.org> wrote: > >Serguei, > >(Extra line breaks help readibility on text only mail readers) > >On 18 April 2018 at 14:51, Serguei Sokol wrote: >| Le 18/04/2018 à 12:26, Georgi Boshnakov a écrit : >| > I may be missing something here but >| > it doesn't seem right to introduce silent coercion of NULL to >vectors, etc., >| > especially if it would become imposed on everybody using >Rcpp/Armadillo. >| Nothing is imposed. Everyone will be free to use Nullable<T> >mechanism as before. >| 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. >| >| > Even the "convenience" of this is questionable. >| Right. It's a matter of taste. But with a quick glance on SO >| I have seen a discussion here >| >https://stackoverflow.com/questions/34718570/rcpp-pass-vector-of-length-0-null-to-cppfunction >| and on this list here (and follow-ups) >| >http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2014-February/007215.html >| where some people are surprised not having such coercion and even >| expressed a wish like "I would be super happy if in the future the >special value >| R_NilValue could be converted to an empty vector, it would make >things >| very easy and coherent with R's behaviour." >| It's also my thought but I am ready to hear the arguments of those >who >| think otherwise. > >I am not religious about it. Adding the one line is something we might >be >able to do. I did a partial rev.dep tests and it showed no issues. But >I >would like other Rcpp Core folks to weigh in too. > >On 18 April 2018 at 15:09, Serguei Sokol wrote: >| Le 18/04/2018 à 13:32, Dirk Eddelbuettel a écrit : >| > >| > On 18 April 2018 at 10:26, Georgi Boshnakov wrote: >| > | I may be missing something here but >| > | it doesn't seem right to introduce silent coercion of NULL to >vectors, etc., >| > | especially if it would become imposed on everybody using >Rcpp/Armadillo. >| > | Even the "convenience" of this is questionable. >| > >| > Agreed. I am also not yet convinced by Serguei's argument. It >seems a little >| > invasive for an unclear (to me) use case. >| I can describe my own case which made me search for a such solution. >| I have an Rcpp/Armadillo function accepting in an optional argument a >vector of uvec type. >| It can be called from R and I can call it from other C++ functions of >the same package too. >| Nullable<IntegerVector> mechanism was cumbersome but sufficient (note >that there is no possible Nullable<uvec>) > >It needs to be as<>()/wrap() convertible to/from SEXP, yes. > >| when only R calls were planned. But when it comes to calls from C++ >I'll have to juggle with wrap() too. >| Both of Nullable<T> (as well as special code for dealing with NULL >case) and wrap() >| become unnecessary with a neat declaration f(..., uvec v, ...). So >that >| an R call with 'c()' can pass as well as C++ calls with an empty uvec >without >| any additional hassle for treating NULL case. > >Could you use XPtr ? > >Dirk -- Sent from my phone. Please excuse my brevity. _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
