Dear Luke, On Sat, 20 Dec 2025 08:10:30 -0600 (CST) luke-tierney--- via R-devel <[email protected]> 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 ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
