Should other functions pass down arguments via the `args` attribute?

[dragosmg]

Currently ard_stack_hierarchical() passes down the by and variables arguments via the arg attribute. Should other functions take a similar approach? If yes, what should the arg attribute contain?

cards/R/ard_stack_hierarchical.R

Lines 493 to 497 in 4d23c32

	attr(result, "args") <- list(
	by = by,
	variables = variables,
	include = include
	)

Possible candidates for a similar treatment:

• bind_ard() (if it can extract them from the individual ARDs)
• individual ARDs (?)

I found the arg attribute useful when implementing some changes in shuffle_ard().

[ddsjoberg]

YES! I like the idea. We have another issue about assigning a class to the outputs (#393) and as a part of that effort, making this type of return consistent would be great.

[dragosmg]

I had shuffle_ard() in PR #466 preserving the arg attribute (but I think it is out-of-scope there). I will submit a separate PR covering only the preservation of arg in shuffle_ard(), if that's OK. The arg attribute would definitely be useful for downstream {tfrmt} functionality.

In my opinion the key questions are:

• which functions should produce the arg attribute?
• which arguments should be captured? maybe this could be linked to classing the output.
• which functions consume arg?
• should any functions be allowed to modify it?
• which functions allow arg to pass through (unmodified?)? (related to the question above)

[ddsjoberg]

Where the attributes will be useful (from ARD group meeting)

• ard_strata()
• ard_pairwise()
• For all ARD functions that have by and strata arguments, would be useful to know which the user are passing.