Should Futureverse transition to snake_case API? (I think so)

[HenrikBengtsson]

I have mostly punted on the camelCase() vs snake_case() discussion, or rather which of the two conventions to use. Way back when, when you couldn't have underscores in function and variable names, I advocated for the camelCase convention (search for "RCC"). I developed lots of code under this convention, and I still like it for certain things. For instance, I like it when a S3 class is named with a capital letter, because it makes them stand out among functions that start with lower case. Starting with a capital letter more or less requires you to use a 'CamelCase' name. However, I don't mind to at least move to snake_case for function names. Class and data type names are rarely seen by end-users anyway.

Regardless which, it would be nice to have consistency across Futureverse, and I'm leaning towards snake_case to achieve this. Obviously, if doing so, any existing camelCase counterparts must remain in the API for a very long time, possibly forever. Even if one could work with all 400-800 revdep package maintainers to migrate to use the snake_case alternatives, there will be 1,000's of end-users scripts out there that will break if we remove any of the existing functions.

Here's a summary of the current API state:

future is using camelCase throughout, although most users and developers only work with single-word functions plan(), future(), value(), and resolve() + the future backend names. There is also a camelCase dependency coming from the parallelly package; some of its functions used to be in future, but are now only re-exports, since some developers have already learned to import them from future. It's on the roadmap to deprecate and remove as many of these re-exports as possible, but that's a multi-year task, at it will still break scripts from old projects.

future.apply and furrr are using the future_ prefix, so one can argue that they're already using snake_case. There are a few exceptions in future.apply, but that stems from copying the base-R names as-is.

doFuture has registerDoFuture(), which just mimics the naming convention of foreach and the other doNNN adapter packages. There's also a withDoRNG(), which uses camelCase for consistency with registerDoFuture().

progressr uses snake_case. The exception is withProgressShiny(), because of consistency with shiny::withProgress().

parallelly uses camelCase, because it tries to be as close to the parallel package as possible. (There is, or was, a hope that some of the improvements would one day end up back in parallel).

listenv uses snake_case.

globals uses camelCase. That mostly originates from an early version enhancing what I though was missing in codetools. For example, globals::findGlobals() tried to improve on codetools::findGlobals(). Then it grew from there using camelCase throughout. Also, globals is not really used by end users.