I recently learned about quosures and tidy evaluation, and it feels very magical .

But because of the whole "a-little-bit-of-knowledge-is-a-dangerous-thing"-situation, I want to make sure I'm using it right .

**Requirements**:

- Let's say I have some vector
`x`

for which I would like to implement a fairly expensive function`compute_a_lot()`

. - Let's say further that
`compute_a_lot()`

should also work on subsets of x, say`x[2:5]`

, and that, crucially, when working on the subset, its result should depend on some info about*all*`x`

(say, implausibly,`length(x)`

). - Assume that I have already implemented a method for
`'[.x'`

to retain attributes on subsetting.

(My real use case is a print method for `x`

, which needs to ensure all subsets of `x`

are scaled equally).

**Two naive solutions**:

- A naive solution of this problem would be to run
`compute_a_lot()`

whenever`x`

is created, and to save the result as an attribute of`x`

, which a method of`compute_a_lot()`

could then just return when called on`x[1:2]`

. But that would be very painful for the user, because`compute_a_lot()`

would be run before it is*actually*needed, if ever. - Another naive solution would be to just to save the
*whole*`x`

as an attribute of`x`

, which would be retained on subsetting and available for`compute_a_lot()`

of`x[1:2]`

. But that just seems disgusting.

**So I thought, hey, I know a solution – quosures!**

whenever `x`

is created, I run something like

```
attr(x, "compute_a_lot_value") <- rlang::quo(compute_a_lot(x, ...))
```

Then, when `compute_a_lot()`

is *actually* called on some `x[1:3]`

and it's result *needed* , I run

```
rlang::eval_tidy(attr(x, "compute_a_lot"))
```

This seems to accomplish what I want: `x`

always carries around with it the instructions (expression + environment) to calculate `compute_a_lot()`

, but these instructions are acted upon only when it's really necessary.

I understand that quosures are mostly used in the context of NSE, so I'm a little worried I'm using it right.

**Is this (delaying computation) a proper use of quosures?**

Ps.: The whole thing happens in the context of `x`

being an S3 class and print methods, but it seemed like that wasn't necessary to reprex here for the main issue.

Pps.: I am vaguely aware of / very excited about promises and future for long-running computations, but asynchronicity (?) is not the issue here, but just plain delaying the computation.