Great. You can always wrap with suppressWarnings() to indicate to readers of your code that you anticipated the warning.
Please add as a bug report to change to warning. I think of the bug list as things that need to be cleared before next release, or v easy fixes. >> In this case, it should be a warning not error, I'm thinking. > > I think that is a fine middle ground. It would still make me code > extra for it because warnings are almost as annoying as errors, but > that seems like the right balance, saying "hey you sure about that?" > while still not terminating the running code. > > >>> and I don't know >>> if it is a compelling enough reason to deviate. >>> >>>> >>>>> Pretty simple. I think assigning NULL to a column that doesn't exist >>>>> should just work as a no-op instead of failing with an error. No-op >>>>> is >>>>> consistent with data.frame: >>>>> >>>>>> dt=data.table(x=1:10) >>>>>> dt$y=NULL >>>>> Error in `[<-.data.table`(x, j = name, value = value) : >>>>> RHS is NULL, meaning delete column(s). But, at least one column is >>>>> not present. >>>>>> dt[,y:=NULL] >>>>> Error in `[.data.table`(dt, , `:=`(y, NULL)) : >>>>> RHS is NULL, meaning delete column(s). But, at least one column is >>>>> not present. >>>>>> df=data.frame(x=1:10) >>>>>> df$y=NULL >>>>> >>>>> If agreed I will file a bug report. >>>>> >>>>> -Chris >>>>> _______________________________________________ >>>>> datatable-help mailing list >>>>> [email protected] >>>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help >>>>> >>>> >>>> >>>> >>> >> >> >> > _______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
