Generic template types

[dtolnay]

How feasible would it be to support generic template types?

{{ t }}

#[derive(Template)]
#[template(path = "test")]
struct Test<T> {
    t: T,
}

error[E0243]: wrong number of type arguments: expected 1, found 0
 --> src/main.rs:7:10
  |
7 | #[derive(Template)]
  |          ^^^^^^^^ expected 1 type argument

error[E0243]: wrong number of type arguments: expected 1, found 0
 --> src/main.rs:7:10
  |
7 | #[derive(Template)]
  |          ^^^^^^^^ expected 1 type argument

error: aborting due to 2 previous errors

[djc]

Should be straightforward. I only handle the lifetimes part of Generics so far because I was lazy/test-driven.

[dtolnay]

Nice. I think as long as you detect this case and fail with a better message, this can wait until after you announce the project.

[djc]

Nah, might as well fix it now. Shouldn't be too hard to at least fix the simple cases.

[djc]

BTW, I think your test as written will not work. There needs to be a trait bound T: std::fmt::Display added, but I assume that would be acceptable. I have a fix for this which I'll try to push tonight.

[dtolnay]

Askama should infer the bound, similar to what we do in Serde. This works:

#[derive(Serialize, Deserialize)]
struct Test<T> {
    t: T,
}

[djc]

How does that work in Serde? I'm not sure it would work in Askama, or at least it seems like it would make Askama an order of magnitude more complex than it currently is. This is because Askama templates can require arbitrary complexity from types of fields in the template (which I think is quite a bit different from Serde).

[djc]

(That is to say, it would be fairly easy for this specific case, but it seems Hard for the general case.)

[dtolnay]

You're right, I did not consider that arbitrary expressions make it not feasible to infer bounds.

Either of these should work when using {{ t }}, right?

#[derive(Template)]
#[template(path = "test")]
struct Test<T: Display> {
    t: T,
}

#[derive(Template)]
#[template(path = "test")]
struct Test<T> where T: Display {
    t: T,
}

[djc]

Yup, I have that covered.

[djc]

BTW, I was using to_tokens() to copy over the trait bounds and noticed that the spacing doesn't look so nice, is that worth a bug? I can understand if it's too hard to fix generically in syn or quote.

[dtolnay]

to_tokens() is not designed to generate human-readable output. It is for handing tokens to the compiler. If the user wants to see the generated code they can run cargo expand and see pretty formatted output. Syn / quote should not need to re-implement a pretty-printer for that.

[djc]

(Added test case in f71b2f0, which I tagged with the wrong issue number by mistake.)