C++11 as minimum supported standard

[Enchufa2]

Meta-issue for discussion and to keep track of all the individual changes required to achieve this goal.

---

It may be helpful to define three classes of tasks and an ordering as DE sees it

• First order: establish C++11 as the baseline allowing variadic templates (and the 'can use C++11' define) to reduce to unconditional code which, as a major side effect and first order goal, leads to removal of all the pre-C++11 autogenerated code. Other cleanups below inst/include and in src/ happen basically as a side effect
• Second order, by a wide margin: cleanup below inst/ and removal of old helpers or illustrations which does not really affect anyone
• Third order, and possibly tied with or marginally ahead of the previous point: cleanup of R helper functins

---

Tasks

• Clean up inst/include/Rcpp/platform/compiler.h. Ancient tests and defines that are not required anymore.
  "Spring cleaning" of some ancient pre-processor directives #1363
  Header cleanup with C++11 as a baseline #1364
• Review HAS_VARIADIC_TEMPLATES checks and remove carefully, also cleaning up inst/include/Rcpp/generated stuff. (DE: I expect this to be one single careful PR)
  Remove use of HAS_VARIADIC_TEMPLATES #1366
  Use variadic templates unconditionally #1367
• Review RCPP_USING_CXX11 checks and remove carefully. RInside uses this macro (see this search). Then, the definition could be removed. (DE: Thanks for the heads-up. I can take this.)
  Remove RCPP_USING_CXX11 which is now implicit #1369
• Find remaining if __cplusplus < 201103L and assess removal
  Cleanup __cplusplus checks based on C++11 availability #1370
  Cleanup __cplusplus checks #1371
• Review RCPP_USING_UNORDERED_* checks and remove carefully. Review RCPP_UNORDERED_* types and just replace with the appropriate std::unordered_* type.
  Remove macros for unordered maps/sets #1372
• Remove branch in inst/include/Rcpp/sugar/functions/sapply.h:41 (see TODO there). (DE: Unsure about this one, lesser priority for me. To be determined...). (IU: Maybe the other way around: maybe we should just remove the first branch, the one that uses the std library. Then ::Rcpp::traits::result_of could (or could not) be reimplemented based on the std library.)
  Enable lambdas in all sugar functions #1373
• Reach out packages jiebaR, fwsim, diveRsity (removed from CRAN), which use RCPP_UNORDERED_MAP and RCPP_UNORDERED_SET (see this search) in order to replace those uses too. We can deprecate these definitions and remove them in a future release.
• Maybe implement more variadic templates if any missing, then clean up remaining inst/include/Rcpp/generated stuff.
• Same for generated stuff under inst/include/Rcpp/module.
• Same for generated stuff under inst/include/Rcpp/sugar/block.
• Same for generated stuff under inst/include/Rcpp/sugar/functions/mapply.
• Clean up R/RcppLdpath.R. Functions that have been deprecated for ages. Some internal functions could just be dropped (also the inst/discovery script). The exported ones require some revdep checking. (DE: Sure but low priority as it has not bitten anyone. We could also chase packages still doing 'Depends: Rcpp' but ... to what payoff?)
• Clean up plugins in R/Attributes.R. Particularly, cpp98, cpp0x, probably cpp11 too. (DE: Unsure. There will be old code snippets hanging around that have this. Just as with old LdFlags() calls we could just make them null-ops)
• Update vignettes accordingly.

@eddelbuettel Feel free to add/drop/edit/reorder above.

[Enchufa2]

fwsim maintainer contacted here: https://lists.r-forge.r-project.org/pipermail/rcpp-devel/2025-March/010973.html

[eddelbuettel]

Yes trickier issue. "Eventually" we will make the same subsitution but we probably need to have a 'deprecated' period first where we warn. This is still a user-facing API.

[coatless]

I'm thrilled to see the new baseline move to C++11 tis like watching The Flintstones discover electricity. 😉

Let me know if I can help with anything! Looks like it's split with DE + IU and Kevin reviewing. Major props.

[eddelbuettel]

We're not there yet, but we are moving from wheels that are almost quadratic with their five sides to those with six. Almost a smooth ride now.

Kidding aside, many/most client packages have compilerd under C++11 or C++14 or C++17 (and some even C++20) for years. But the baseline is so safely aheard of C++98 that we can simply do the cleanup now. Fairly easily.