[jira] [Resolved] (ARROW-14804) [R] import_from_c() / export_to_c() methods should accept external pointers

["Jonathan Keane (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARROW-14804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Keane resolved ARROW-14804.
------------------------------------
    Fix Version/s: 7.0.0
       Resolution: Fixed

Issue resolved by pull request 11919
[https://github.com/apache/arrow/pull/11919]

> [R] import_from_c() / export_to_c() methods should accept external pointers
> ---------------------------------------------------------------------------
>
>                 Key: ARROW-14804
>                 URL: https://issues.apache.org/jira/browse/ARROW-14804
>             Project: Apache Arrow
>          Issue Type: Improvement
>          Components: R
>            Reporter: Dewey Dunnington
>            Assignee: Alessandro Molina
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 7.0.0
>
>          Time Spent: 5h
>  Remaining Estimate: 0h
>
> The import and export to C methods for Field, Shema, DataType, Array, RecordBatch, and RecordBatchReader all require the pointer to be passed as a {{double}} (casted from {{uintptr_t}} casted from {{*}}. I imagine there's good reason for this path to exist; however, the R externalptr type and 64-bit integer are more natural types and I think it would not be hard to allow pointers to be passed in this way. A [short discussion|https://github.com/apache/arrow/pull/11679#discussion_r755178800] of this occurred when updating the Python docs on how to pass Array pointers to R.
> The implementation lives in [arrow_cpp11.h|https://github.com/apache/arrow/blob/eb2fa2df6dedf2743047df9dd19d7ed4f4482c22/r/src/arrow_cpp11.h#L49-L54] and it seems like it would be easy to allow a user to pass something more R-like while still keeping the double route open for the packages that need it.
> I see that this is getting used for pointers that R6 objects are storing for the underlying C++ objects...I imagine there's a good reason for this but I wonder if there's a way to make the places where this interacts with other packages more intuitive.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)