Description
This is a meta discussion about the ... behavior for import() and export(). It is related to the following issues
import()for xlsx doesn't follow the de-facto standard #312- Potential future candidates for refactoring arguments #280
- Using an existing function for filtering
...instead of writing it out each time. #231 - When an underlying import function lacks a
...argument, most invalid arguments will error instead of being ignored. #221 - col_names is rejected with ODS files #206
- Standard for import methods #132
I closed them all so that we can focus the discussion here.
The ... and the undocumented remapping behaviors have been a major source of confusion in the past; and I think we need to rectify this in the upcoming v1.0.0, the major release where the API should be considered "stable" and probably the only chance in the near future to introduce breaking changes.
As I argue in #280 , in my opinion passing unused arguments to the underlying reading/writing function should be an error, rather than a warning. But I really want to know how you all (users and developers) think about this.
Also, we also have two choices regarding the undocumented remapping behaviors (mostly for xlsx, ods, and csv): (1) document them all in v1.0.0; or (2) abandon them all and let ... be ... that gets passed to the underlying function.
My initial think was to abandon them all to reduce the complexity of rio. But I don't have a grip on how many of you wrote code in the past like this:
tempods <- tempfile(fileext = ".ods")
export(mtcars, tempods)
import(tempods, header = TRUE) ## expecting header will get passed as `col_names`And certainly, I don't want to break your existing code. If you do have code that was written like that, please let me know. It would be taken into account when I think about the question of these undocumented remapping behaviors.