Message-ID: <20260104002505.147944ea@Tarkus>
Date: 2026-01-03T21:25:05Z
From: Ivan Krylov
Subject: non-API ATTRIB and SET_ATTRIB will be dropped soon
In-Reply-To: <53ffc423-b184-fc87-6f98-5f0b952bf473@uiowa.edu>
Dear Luke,
On Sat, 20 Dec 2025 08:10:30 -0600 (CST)
luke-tierney--- via R-devel <r-devel at r-project.org> wrote:
> The 'Working with attributes' section in the 'Writing R Extensions'
> list some alternatives. Additional functions for working with
> attributes, without exposing internal attributes structure, could be
> added if they are needed.
Two tangentially related questions:
1. Should packages use the return value of Rf_setAttrib()? I've noticed
that some branches taken by the code (e.g. setAttrib(foo,
R_CommentSymbol, bar)) return R_NilValue, while others return the newly
installed attribute value.
I'm asking because data.table needs to resize a temporary data frame
that it owns, and for this purpose it needs to mutate its 'row.names'
attribute in compact integer form. The current code walks the ATTRIB()
list in search of the desired attribute, since Rf_getAttrib() would
return an ALTREP form instead. We'll probably replace it with
R_mapAttrib(), but I'm curious about alternatives.
2. In R_mapAttrib(), while walking ATTRIB(), the code always protects
the current pair 'a', and then it protects CAR(a) and TAG(a) before
calling the user-provided callback. Why protect TAG(a)? Because it's a
good practice to protect arguments of user callbacks, or because it's
really possible for TAG() of an attribute pair to become
garbage-collected?
--
Best regards,
Ivan