Problem: your function is recognised as an unwanted S3 method

[aitap]

Problem: for historical reasons, your package already exports a function named <existing generic>.<a potential class name>. You cannot get rid of it right away for backwards compatibility reasons (it's part of your the API of your package), but

Sys.setenv(`_R_CHECK_S3_METHODS_SHOW_POSSIBLE_ISSUES_` = 'TRUE')
tools::checkS3methods(dir = '.')

(and therefore the CRAN checks) are telling you that you have an "apparent method for exported generic not registered".

Solution: suggested by Jan van der Laan

You can keep exporting your original function named generic.class without it becoming an S3 method if you explicitly register a different S3 method for that generic and class.

In your NAMESPACE:

S3method(generic, class, throwawayfunction)

In your R code:

throwawayfunction <- function(...) { # should have the same formal arguments as the generic
 stop("Sorry, objects of this class are not actually supported.")
}

[bettinagruen]

I am wondering why defining a stopList and relying on tools::nonS3methods() is not an option to solve this issue.

[aitap]

It doesn't scale very well to submit a patch to tools:::nonS3methods and wait for it to propagate to R-released every time a CRAN package has this problem. If a package could define its own stopList or mark its functions as exempt from S3 dispatch, it would be much nicer. Jan van der Laan has suggested a way to effectively mark a function as exempt from S3 dispatch by name by registering a different function instead.

Edit: If you think this is a bad approach because it precludes someone else from registering a real S3 method for the same generic+class, I can try to develop a patch that uses function attributes for S3 method dispatch exemption, but that might incur a performance penalty for all S3 dispatch.

[hturner]

Certainly R Core do not intend for the list in tools::nonS3methods to be extended, see Martin Maechler's comment in a related discussion.

I don't think the solution is to provide a workaround, either by defining a dummy S3 method as suggested in @aitap's first comment or by enabling packages to define their own stop list as suggested in @aitap's comment above, since this would give no incentive for authors to fix their package and may even encourage more widespread use of misleading names.

Instead it could be good if tools::checkS3methods() could ignore functions that were marked as Deprecated or Defunct. Then new packages could solve this issue by renaming the offending functions, while existing packages would be encouraged to deprecate them.

There is this comment from Kurt in the source code for tools::checkS3methods() that the check may not be needed at all. This lead to the default for _R_CHECK_S3_METHODS_SHOW_POSSIBLE_ISSUES_ being changed to false last year, but it is still set to true for CRAN submissions (with --as-cran). So it would make sense to ask Kurt what he thinks here.

[aitap]

If tools::checkS3methods becomes able to ignore non-hardcoded package functions, it may make sense to exempt them from S3 dispatch as well. For example, a check for getAttrib(vl, install("exempt_from_S3_dispatch")) == R_NilValue could be added in this part of UseMethod (assuming getAttrib on functions is considered cheap enough). This would make function names with dots in them less misleading, because S3 won't pick them up by accident.

[llrs]

Not sure I understand the first paragraph, but anything that makes this easier might be good. How big is the penalty of adding getAttrib (or any undesired side effects)?

[aitap]

Assuming it's considered a good idea at all to exempt functions from being S3 methods (maybe Kurt will just turn the check off and that's it), for most functions the penalty will be very small because for them attributes(function) is NULL. But the more attributes an object has, the more time (and cache misses) getAttrib() will take to walk the linked list in search of the attribute.