Support computation in interpolation

[sfackler]

It's fairly common to have to adjust values you want to interpolate before use, for example: https://github.com/sfackler/rust-postgres-derive/blob/e89a9a5e41cf83539323fe3cae39ece5b4bb685b/postgres-derive-internals/src/fromsql.rs#L90-L92.

It'd be nice if it was possible to "inline" those struct accesses, Ident creation, etc into the interpolation itself. For example, to change

let ident = &foo.ident;
quote!(#ident)

to

quote!(#{foo.ident})

[dtolnay]

Yep I would love to support something like this. Some details left to figure out:

1. What a computation does inside of repetition:

   let x = /* ... */;
   
   quote! {
       #( #{x.name} )*
   }

   Is this for x in x { token(x.name) } or for x in x.name { token(x) }? If it is one of them, is there a way to express the other?

2. Heuristic to tell which piece of the computation is the loop variable:

   let x = /* ... */;
   
   quote! {
       #( #{f(x)} )*
   }

   Leaving aside the ambiguity in the previous bullet, is this for x in x { token(f(x)) } or for (f, x) in f.zip(x) { token(f(x)) }?

3. Any limit on what computations are supported?

   quote! {
       let mut #{ Ident::new(format!("__{}", f.ident)) } = None;
   }

   Are we comfortable with encouraging this style which may be less readable than let mut #var? Do we just support any expression and leave it to the programmer's judgment regarding readability?

   As a first pass maybe limit it to just the two forms $ident.$ident and $ident($ident)? Does that cover sufficiently many of the use cases?

[sfackler]

With respect to 3, I'd personally lean towards arbitrary exprs unless a $foo:expr won't work with the macro definition, but just field access would cover most use cases I think.

[Arnavion]

Another point for arbitrary expressions for (3) - I'd really like to be able to do something like:

let result = quote! {
    #{ if generate_enum {
        quote! {
            enum Foo { }
        }
    } else {
        quote! {
            struct Foo { }
        }
    } }
};

It can be done by lifting the whole thing outside the outer quote block into its own binding, but if the outer quote block is big and the conditional part is tiny, it reads better to have the conditional at the same place where it would be used.

[colin-kiegel]

My primary use case from the derive_builder crate looks like this

pub struct Initializer<'a> { /* ... */ }

impl<'a> ToTokens for Initializer<'a> {
    fn to_tokens(&self, tokens: &mut Tokens) {
        let struct_field = self.field_ident;
        let match_some = self.match_some();
        let match_none = self.match_none();
        tokens.append(quote!(
            #struct_field: match self.#struct_field {
                #match_some,
                #match_none,
            },
        ));
    }
}

I would like that to become

pub struct Initializer<'a> { /* ... */ }

impl<'a> ToTokens for Initializer<'a> {
    fn to_tokens(&self, tokens: &mut Tokens) {
        tokens.append(quote!(
            #{self.field_ident}: match self.#{self.field_ident} {
                #{self.match_some()},
                #{self.match_none()},
            },
        ));
    }
}

[dtolnay]

We explored some possible implementations in #30 and I no longer believe this feature would be a net benefit.

[gnzlbg]

and I no longer believe this feature would be a net benefit.

Can you expand on why? I've wanted this many times.

[XAMPPRocky]

@gnzlbg I found an explanation of the rationale. Hopefully that clarifies why this decision was made.

[gnzlbg]

Thanks, that's super thoughtful, and makes a lot of sense!