[R] read_csv_arrow() signature should match readr::read_csv()

[asfimport]

So that using it is natural for R users. Internally handle all of the logic needed to map those onto csv_convert_options, csv_read_options, and csv_parse_options. And give a useful error message if a user requests a setting that readr supports but arrow does not.

Reporter: Neal Richardson / @nealrichardson
Assignee: Neal Richardson / @nealrichardson

PRs and other links:

• GitHub Pull Request #4711

_{Note: This issue was originally created as ARROW-5500. Please see the migration documentation for further details.}

[asfimport]

Wes McKinney / @wesm:
This brings up a bigger question of whether the arrow library as it is being developed now is the desired "front end" for end-users.

[asfimport]

Neal Richardson / @nealrichardson:
Perhaps it does. IMO the idea that we would want two R packages–one that just wraps the C++ library for developers, and a separate one that provides an interface for analysts to work with datasets–is YAGNI. There's no reason we can't have the lower-level C++ API wrappers and the analyst-centric interface in the same package, and no value at this point to splitting them. 

Currently there already is a lower-level csv_table_reader, and all the read_csv_arrow() function does is invoke it: https://github.com/apache/arrow/blob/master/r/R/csv.R#L179-L181

I'm proposing adding R-flavored substance to read_csv_arrow() (and documenting it). I'm not proposing removing or making private the classes and methods that invoke the C++ library, so a "developer" could choose to write something at that layer if it were useful. 

[asfimport]

Wes McKinney / @wesm:
Issue resolved by pull request 4711
#4711