Matthew Kay

> Yeah I just ran into something in CmdStanR where we have some code that mistakenly assumes that variables() will return the same thing regardless of the draws format. variables()...

If someone wants to tackle this a good place to start might be the methods for customizing tibble printing (since we are already using tibbles): https://pillar.r-lib.org/articles/extending.html

Noting here so we don't forget: from the conversation over at https://github.com/stan-dev/posterior/pull/160#issuecomment-847435468 I think that [touchstone](https://lorenzwalthert.github.io/touchstone/index.html), not bench, is the more promising direction for this.

I suspect this is probably a combination of the fact that we do weird things to make `rvar` mimic arrays and `data.table` probably doesn't always access the rvar data type...

I'll leave it open but label it help wanted --- if someone wants to investigate this I'd be more than happy!

This seems like a nice idea to me. I know we ended up deciding against using {future} for other parallel stuff awhile back, though personally I am leaning more towards...

I get the need for some way to calculate multivariate measures, but it occurs to me the selection part of this question is maybe overloading summarise_draws to do more than...

> I am a little unsure about the rest of your comments. The point is not necessarily to perform selection on the fly and I agree this is better handled...

> That would be cool. There are also packages (e.g. rstanarm and at least one more that I'm forgetting at the moment) that return character for the ppd in these...

> Would it be terrible to include something like a col_name argument that let the user choose between brms or posterior, where the brms option returned the typical brms names...