Rcpp: Rename Rcpp_fast_eval()?

[lionel-]

I think it needs a new name because the Rcpp::Rcpp_ double namespacing does not make much sense and using underscores does not follow the general Rcpp API style.

Should we rename to Rcpp::eval()? @kevinushey suggested this might cause problem for code that imports the whole Rcpp namespace because it is such a short name.

Alternatively this could be Rcpp::evalProtect() to parallel Rcpp::unwindProtect(). Though I like it less because it exposes an implementation detail (unwind protection) in the name.

[eddelbuettel]

Agreeing with

• current name not great
• Rcpp::eval() to short and high-risk for a clash
• leaving evalProtect() (or maybe evalProtected() ?) as a better choice

Current reverse depends situtation is good -- did another one overnight and we are otherwise ready for Rcpp release 0.12.18. So let's get a decent consensus here, change, test and ship.

[kevinushey]

Agree that unwindProtect() isn't a great name since it feels like we're just exposing an implementation detail in the name.

What about something like safeEval() or evaluateSafely()?

[lionel-]

Sorry if we already discussed this before, but wouldn't the revdep checks reveal if there are actually name clashes? Or is that trickier?

[eddelbuettel]

It would reveal it _conditional on the tested code_ and I think we concluded that even now at 1401 rev,deps it is too narrow. There is simply more code in the open.

safeEval() sounds nice too.

[eddelbuettel]

Also, even as we rename this we are not yet turning it on via the #define, correct?

[lionel-]

Right.

[eddelbuettel]

So is it safeEval() then?

[lionel-]

I think it exposes an implementation detail as much as evalProtect() and is less consistent with unwindProtect(). On the other hand it is shorter. So I am neutral on this one.

[lionel-]

We should also take into account the future name of Rcpp_eval(). You mentioned you wanted to rename it. What should be its name? The difference is that it catches R errors and rethrows them as typed C++ exceptions. Also I have implemented a catch-all version of unwindProtect() for the next version of Rcpp. This version will not throw exceptions but return relevant information for continuing a jump/throw later on, which will be useful to go through a C stack like libpython. A consistent naming might be:

• unwindProtect() for calling back a C function with longjump protection. This function throws longjump exceptions.

• unwindCatch() for calling back a C or C++ function via an R tryCatch() call. This features longjump protection and catching of R errors, R longjumps, and C++ exceptions. This function doesn't throw.

• evalProtect() for evaluation with longjump protection. This throws longjump exceptions.

• evalTry() for evaluation with longujmp protection and catching of R errors. This throws longjump exceptions and R error exceptions.

evalCatch() and unwindTry() could be added for consistency though probably wouldn't be as useful. Does this make sense?

[eddelbuettel]

Sure.

[lionel-]

Just discussed this with Dirk and we agreed on changing the name later on, along with Rcpp_eval().

Alternative nomenclature:

• safeUnwind() (instead of unwindProtect())

• catchUnwind() (catch LJs, R errors, C++ exceptions)

• safeEval() (instead of Rcpp_fast_eval())

• tryEval() (instead of Rcpp_eval())

[eddelbuettel]

So we leave this open to come back to later, and are otherwise release ready as #884 is pretty minor.

[github-actions[bot]]

This issue is stale (365 days without activity) and will be closed in 31 days unless new activity is seen. Please feel free to re-open it is still a concern, possibly with additional data.