Export masks for NSE-only constructs ., J, patterns and measure

NAMESPACE

@@ -27,7 +27,7 @@ export(tstrsplit)
 export(frank)
 export(frankv)
 export(address)
-export(.SD,.N,.I,.GRP,.NGRP,.BY,.EACHI)
+export(.SD,.N,.I,.GRP,.NGRP,.BY,.EACHI, ., J, measure, patterns)
 export(rleid)
 export(rleidv)
 export(rowid)

NEWS.md

@@ -98,6 +98,8 @@
 
 15. `dcast()` now issues a warning when `fun.aggregate` is used but not provided by the user. `fun.aggregate` defaults to `length` in this case. Previously, only a message was issued. However, relying on this default often signals unexpected duplicates in the data. Therefore, a stricter class of signal was deemed more appropriate, [#5386](https://github.com/Rdatatable/data.table/issues/5386). The warning is classed as `dt_missing_fun_aggregate_warning`, allowing for more targeted handling in user code. Thanks @MichaelChirico for the suggestion and @Nj221102 for the fix.
 
+16. `.`, `J`, `measure`, and `patterns` are now exported for use within `[` and `melt()` functions, for consistency with`.N`, `.I`, `.GRP`, `.GRPI`, `.SD`, and `:=` which were the only previous NSE exports. This change means that package developers will no longer see CRAN NOTEs about these being undefined variables, and no longer need to provide dummy/NULL definitions of these in order to avoid such NOTEs. See [#5604](https://github.com/Rdatatable/data.table/issues/5604) and [#5277](https://github.com/Rdatatable/data.table/issues/5277). Thanks to @tdhock for the suggestions and @Nj221102 for implementing this improvement.
+
 ## TRANSLATIONS
 
 1. Fix a typo in a Mandarin translation of an error message that was hiding the actual error message, [#6172](https://github.com/Rdatatable/data.table/issues/6172). Thanks @trafficfan for the report and @MichaelChirico for the fix.

R/data.table.R

@@ -12,9 +12,16 @@ methods::setPackageName("data.table",.global)
 #   (2) export() in NAMESPACE
 #   (3) add to vignettes/datatable-importing.Rmd#globals section
 .SD = .N = .I = .GRP = .NGRP = .BY = .EACHI = NULL
+J = function(...) {
+  stopf("The function 'J' should not be called here. 'J' is intended for use within the 'i' argument of data.table operations")
+}
+
+. = function(...) {
+  stopf("The function '.' should not be called here. '.' can be used as an alias for 'list' within the square brackets of a data.table, DT[.]")
+}
+
 # These are exported to prevent NOTEs from R CMD check, and checkUsage via compiler.
 # But also exporting them makes it clear (to users and other packages) that data.table uses these as symbols.
-# And NULL makes it clear (to the R's mask check on loading) that they're variables not functions.
 # utils::globalVariables(c(".SD",".N")) was tried as well, but exporting seems better.
 # So even though .BY doesn't appear in this file, it should still be NULL here and exported because it's
 # defined in SDenv and can be used by users.

inst/tests/tests.Rraw

@@ -2186,7 +2186,7 @@ if (ncol(DT)==2L) setnames(DT,c("A","B")) # else don't stop under torture with s
 test(714, DT[,z:=6:10], data.table(A=1:5,B=5,z=6:10))
 
 # Test J alias is now removed outside DT[...] from v1.8.7 (to resolve rJava::J conflict)
-test(715, J(a=1:3,b=4), error=base_messages$missing_function("J"))
+test(715, J(a=1:3,b=4), error="The function 'J' should not be called here.")
 
 # Test get in j
 DT = data.table(a=1:3,b=4:6)

vignettes/datatable-importing.Rmd

@@ -118,7 +118,7 @@ aggr = function (x) {
 }
 ```
 
-The case for `data.table`'s special symbols (`.SD`, `.BY`, `.N`, `.I`, `.GRP`, `.NGRP`, and `.EACHI`; see `?.N`) and assignment operator (`:=`) is slightly different. You should import whichever of these values you use from `data.table`'s namespace to protect against any issues arising from the unlikely scenario that we change the exported value of these in the future, e.g. if you want to use `.N`, `.I`, and `:=`, a minimal `NAMESPACE` would have:
+The case for `data.table`'s special symbols (`.SD`, `.BY`, `.N`, `.I`, `.GRP`, `.NGRP`, `.`, `J`, `patterns`, `measure` and `.EACHI`; see `?.N`) and assignment operator (`:=`) is slightly different. You should import whichever of these values you use from `data.table`'s namespace to protect against any issues arising from the unlikely scenario that we change the exported value of these in the future, e.g. if you want to use `.N`, `.I`, and `:=`, a minimal `NAMESPACE` would have:
 
 ```r
 importFrom(data.table, .N, .I, ':=')