R version compatibility linter

[renkun-ken]

For package developers, it would be quite helpful to know if the code is compatible with the declared R version.

For example, if one uses trimws(whitespace=), then it is only compatible with R >= 3.6.0. However, developers using R >= 3.6.0 might not be aware of this until some user or CI using R < 3.6.0 complains.

I don't know a simple way to find how compatible the functions I use in package development are unless I carefully go through the R News, R News 3.x, etc.

I'm wondering if there's a way to make this process work in a more automatic manner, e.g. create a linter that checks the usage of functions are compatible with declared version requirement? Or suggest the use of backport instead?

[MichaelChirico]

Would you extend this to new arguments as well? That would make it a lot harder but could have helped e.g. in #546 (I had tried sQuote(x, '"') but learned the second argument is a 3.6 feature), but would be a fair amount harder to implement.

[renkun-ken]

Certainly we could extend this to arguments as well.

There are different levels of incompatibility across versions.

1. Using a new argument definition: The definition of an argument is changed so that the same input no longer produces the same output as the old version.
2. Using a new argument type: An argument of a function accepts new types of input. Using such input does not work with older versions.
3. Breaking in argument order: The order of arguments of a function is changed so that using positional arguments could be broken.
4. Using a new argument: A new argument is added to a function so the using this argument is not compatible with older versions.
5. Using a new function: A new function is added so using this function is not compatible with older versions.
6. Using a new syntax: A new syntax (e.g. raw strings) is introduced so using this syntax is not compatible with older versions.
7. Using other new stuff: new environment variables, etc.

I think there are certainly some limitations we could not handle well (e.g. case 1, 2, 3).