const T& as input about cpp11

[jimhester]

I don't really see what this extra indirection buys you though, it isn't actually a constant reference to an R object, it is a constant reference to a intermediate object. You might as well just use a copy by value object directly rather than a reference.

e.g. in Rcpp const int& is basically equivalent to

my_fun(const int&);

SEXP x_sxp;
const int x_wrap = INTEGER(x_sxp)[0];
my_fun(x_wrap);

But the semantics of that in terms of behavior and number of copies are identical to

my_fun(const int);
SEXP x_sxp;
my_fun(INTEGER(x_sxp)[0]);

As far as extensions go you should be able to define custom as_cpp() overloads. If you define them in arrow_types.h they will be added to the generated code.

[romainfrancois]

Yeah, this is more about the const-ness of the function the package developer is writing, e.g.

// [[arrow::export]]
Rcpp::List Table__to_dataframe(const std::shared_ptr<arrow::Table>& table,
                               bool use_threads) {
  int64_t nc = table->num_columns();
  int64_t nr = table->num_rows();
  Rcpp::CharacterVector names(nc);
  std::vector<std::shared_ptr<arrow::r::Converter>> converters(nc);

  for (int64_t i = 0; i < nc; i++) {
    converters[i] =
        arrow::r::Converter::Make(table->column(i)->type(), table->column(i)->chunks());
    names[i] = Rcpp::String(table->field(i)->name(), CE_UTF8);
  }

  if (use_threads) {
    return arrow::r::to_dataframe_parallel(nr, nc, names, converters);
  } else {
    return arrow::r::to_dataframe_serial(nr, nc, names, converters);
  }
}

having table as a const std::shared_ptr<arrow::Table>& here prevents me from messing with it inside the function. I can do a as_cpp<shared_ptr<T>>(SEXP from) I guess with some enable_if but I don't think I could do a as_cpp<const std::shared_ptr<T>&>().

[jimhester]

You can do as_cpp<const std::shared_ptr<T>>() though, e.g. without the reference.

[romainfrancois]

Fair enough. That would look different from the rest of the code base, but that's fine I guess.

Now, arrow also has a few functions that take a const std::unique_ptr<T>&, e.g.

// [[arrow::export]]
int64_t ipc___Message__body_length(const std::unique_ptr<arrow::ipc::Message>& message) {
  return message->body_length();
}

The way this is organized is that the R6 object eventually holds an external pointer to the unique_ptr, we create the unique_ptr<> once when the XPtr is created and the XPtr is responsible for deletion, but still we can use const std::unique_ptr<arrow::ipc::Message>& message in the parameters without having to copy, which is by design forbidden.

[romainfrancois]

Maybe this is "too magical" and arrow can step back to using something more explicit that would be copiable, e.g.

// [[arrow::export]]
int64_t ipc___Message__body_length(arrow::r::R6<std::unique_ptr<arrow::ipc::Message>> message) {
  return message->body_length();
}

[romainfrancois]

Closing this, arrow has to do do its own code generation anyway because of availability or not of the shared library.