Dots splicing semantics for SE functions

[lionel-]

Using rlang::splice().

One issue is whether we allow bare list splicing or if we require the use of a modifier/adverb for signalling splicing. Bare-list splicing would apply most of the time, since most functions expect either atomic vectors or S3 objects in .... It is less verbose:

bind_cols(mtcars, list(mtcars, mtcars), mtcars)

On the other hand, some functions also expect lists in .... A replacement for structure() would be an example. In this case an adverb like spliced() is necessary:

struct(obj,
  attr1 = "attr",
  attr2 = list("attr"),
  spliced(list(attr3 = "attr"))
)

We'd need a standardised way of documenting those semantics in roxygen. But even then, would it be confusing to have these two kinds of splicing in the tidyverse?

[hadley]

Also recode() currently uses ...

[hadley]

The other big question is whether we should use call-splicing (where we inspect the call) or value-splicing (where we inspect the value). The advantage of call-splicing is that it's the same style as tidyeval; the advantage of value-splicing is that it's simpler.

[lionel-]

Having a uniform interface is appealing. But I think we'd want to keep a clean separation between SE and NSE functions. For instance that would allow us to signal SE arguments to R and give more guarantees to the compiler. This would enable it to compile these arguments in the future. Though maybe we don't care about that?

By the way, do we want to support :=? It's self-quoting so no NSE, and would make it easy to use a variable as name.

[lionel-]

By the way, do we want to support :=? It's self-quoting so no NSE, and would make it easy to use a variable as name.

But then we're relying on !! to unquote the name. So probably we'd only want to do that if we used call-splicing.

One issue with call-splicing to keep in mind, when we are unquoting values, is that it will lead to noisy stacktraces.

[hadley]

I think if we're clear about the distinction between call-splicing and value-splicing we should be ok.

One question is where spliced() (or maybe splice_in()) should live. In rlang and re-export in dplyr? (And every other package that uses it)

[lionel-]

yes I would think in rlang. We'd support splicing in rlang's primitives too, like in with_handlers().