Possibly reorganizing top-level header files, also allowing C++11/14/17/20/... entries

[eddelbuettel]

We currently use #include <Rcpp.h> for every project. It works, but is inelegant; many other C++ headers (from the standard library down to, say, Arnadillo) use use a single nown, say, cfloat or armadillo. Some libraries also use a dir/file scheme.

Now, sadly, we cannot do #include <rcpp> as we have a top-level directory there. But maybe using a scheme such as

#include <rcpp/rcpp>                // default, implies C++ at a given standard which may as well be C++11

// or

#include <rcpp/rcpp11>              // likely as above

// or

#include <rcpp/rcpp14>              // turn on C++14 features

// or

#include <rcpp/rcpp17>              // turn on C++17 features

// or

#include <rcpp/rcpp20>              // turn on C++20 features

This allows us to separate out different language standards in order to cleanly take advantage of different standards, opening a door to (partial) rewrite and extensions in a clean manner.

We could (and should) like also remove the top-level RcppCommon.h (moving it a level down) and just keep the top-level Rcpp.h as an include of the (default) rcpp/rcpp.

Thoughts?

[Enchufa2]

We currently use #include <Rcpp.h> for every project. It works, but is inelegant; many other C++ headers (from the standard library down to, say, Arnadillo) use use a single nown, say, cfloat or armadillo. Some libraries also use a dir/file scheme.

Boost and Abseil, however, use extension.

Now, sadly, we cannot do #include <rcpp> as we have a top-level directory there.

Why not? Putting a file called rcpp there containing just #include <Rcpp.h> would work. Or does this break on Windows? Could the Rcpp folder be renamed? It's unlikely anybody is directly including anything there.

But maybe using a scheme such as
[snip]
This allows us to separate out different language standards in order to cleanly take advantage of different standards, opening a door to (partial) rewrite and extensions in a clean manner.

Sounds good.

We could (and should) like also remove the top-level RcppCommon.h (moving it a level down) and just keep the top-level Rcpp.h as an include of the (default) rcpp/rcpp.

Agree.

[eddelbuettel]

Why not?

Case gets in the way. Some people in Cupertino did in fact "inhale" so the net effect now is (across all relevant file systems) that we can no longer rely on r != R. It's a sad world but those are them rules.

Feel free to try with a mock package at rhub to get access "that" OS too. I have had that problem for quite some time with littler because r is no longer a free identifier when R is installed providing R.

[eddelbuettel]

This was addressed in #1191.