`#[derive(TS)]` and associated types

[WilsonGramer]

`#[derive(TS)]` and associated types

[NyxCode]

If, at some point, we get const-generic &'static str on stable, something like this would work:

trait MyTrait {
    type U: TS;
}

#[derive(TS)]
struct MyStruct<T: MyTrait> {
    u: T::U,
}

impl<const NAME: &'static str> MyTrait for ts_rs::Dummy<NAME> { 
    type U = i32; 
}

Then, MyStruct::<Anything>::decl() would always yield

type MyStruct<T> { u: number };

no matter what Anything is.

[NyxCode]

(serde#2710)

[WilsonGramer]

Alternatively, #[ts] could support a bound attribute like serde: #[ts(bound = "")]

[NyxCode]

Hey!
This is a known limitation (we should probably document that somewhere).

Besides the technical reasons we currently don't support this, it's also unclear to me what we should generate for types containing associated types of a trait.

The only thing we could do is let you export a concrete instance of MyStruct to a non-generic typescript type.
However, TS currently requires that we can just export the type without any additional information. If the type is generic, then we generate a generic TypeScript type.

In this example, it's the implementation of TS::decl() trying to generate a generic TypeScript definition that causes the compiler error you see. The function which would give you the concrete (non-generic) TypeScript definition is TS::decl_concrete(), but if the thing doesn't compile, that doesn't matter.

[WilsonGramer]

@NyxCode That makes sense, thank you! What do you think about an attribute to ignore a generic parameter?

#[derive(TS)]
struct MyStruct<#[ts(skip)] T: MyTrait> {
    #[ts(as = "i32")]
    u: T::U,
}

For context, my use case is a compiler whose data structures are generic over a Driver:

trait Driver {
    type Info;
    ...
}

struct Expression<D: Driver> {
    info: D::Info,
    kind: ExpressionKind<D>,
}

enum ExpressionKind<D: Driver> {
    String(String),
    Number(i32),
    Call(Box<Expression<D>>, Vec<Expression<D>>),
    ...
}

But my TypeScript interface to this compiler always uses the same driver, so Info is always the same type (TsInfo) when the compiler is used via TypeScript. With the design above, I could use #[ts(skip)] on the D type parameter and #[ts(as = "TsInfo")] on the info field. That way, my Rust code can remain generic over the driver while my TypeScript API ignores the driver altogether.

Let me know what you think!

[NyxCode]

I played with the idea of introducing #[ts(concrete = "SomeType")].
With it, your example would look like this:

trait Driver {
    type Info: TS; // (1)
}

struct TsDriver;
impl Driver for TsDriver {
    type Info = String;
}

#[derive(TS)]
struct Expression<#[ts(concrete = "TsDriver")] D: Driver> {
    info: D::Info,
}

(1): Ideally, this trait bound wouldn't be necessary, but it currently is.

I've put together a proof-of-concept here. There are a lot of edge-cases this just glosses over, but it's a start.
Could you give that branch a go and see if that's already enough for your use-case?

[WilsonGramer]

@NyxCode This is pretty much what I need! The only issue is that as of this change, ts-rs generates a private struct for the type parameter that I can't implement the trait for, so I get this error:

use ts_rs::TS;

trait Driver {
    type Info;
}

#[derive(TS)]
struct TsInfo;

impl Driver for ts_rs::Dummy {
    type Info = TsInfo;
}

#[derive(TS)]
struct Expression<D: Driver> {
    #[ts(as = "TsInfo")]
    info: D::Info,
}

error[E0277]: the trait bound `<Expression<D> as ts_rs::TS>::decl::D: Driver` is not satisfied
  --> src/lib.rs:14:10
   |
14 | #[derive(TS)]
   |          ^^ the trait `Driver` is not implemented for `<Expression<D> as ts_rs::TS>::decl::D`
   |
   = help: the trait `Driver` is implemented for `ts_rs::Dummy`
note: required by a bound in `Expression`
  --> src/lib.rs:15:22
   |
15 | struct Expression<D: Driver> {
   |                      ^^^^^^ required by this bound in `Expression`
   = note: this error originates in the derive macro `TS` (in Nightly builds, run with -Z macro-backtrace for more info)

Would removing the trait bounds on that generated struct fix the issue?

[WilsonGramer]

@NyxCode Whoops – I forgot to add the #[ts(concrete)] attribute, haha! It works great with that!

use ts_rs::TS;

trait Driver {
    type Info;
}

#[derive(TS)]
struct TsInfo;

impl Driver for ts_rs::Dummy {
    type Info = TsInfo;
}

#[derive(TS)]
struct Expression<#[ts(concrete = "ts_rs::Dummy")] D: Driver> {
    #[ts(as = "TsInfo")]
    info: D::Info,
}

[WilsonGramer]

@NyxCode The only issue I'm getting now is when I add in serde — the ts attribute isn't being removed:

use serde::{Deserialize, Serialize};
use ts_rs::TS;

trait Driver {
    type Info: TS;
}

#[derive(TS)]
struct TsInfo;

impl Driver for ts_rs::Dummy {
    type Info = TsInfo;
}

#[derive(Debug, TS, Serialize, Deserialize)]
#[ts(export)]
struct Expression<#[ts(concrete = "ts_rs::Dummy")] D: Driver> {
    info: D::Info,
}

error: cannot find attribute `ts` in this scope
  --> src/lib.rs:17:21
   |
17 | struct Expression<#[ts(concrete = "ts_rs::Dummy")] D: Driver> {
   |                     ^^

Putting TS after Serialize, Deserialize doesn't seem to fix it either.

[NyxCode]

I forgot to add the #[ts(concrete)] attribute, haha! It works great with that!

Awesome!

You could get rid of the #[ts(as = "..")] and put a trait bound on Driver::Info instead.
While in theory neither should be necessary, getting rid of that requirement would be pretty messy.

I also just pushed an other commit, and now #[ts(export)] works as expected.
While the branch definetely needs a lot of cleanup, it's nice to see that this could be a solution to this issue.

The only issue I'm getting now is when I add in serde — the ts attribute isn't being removed:

Oh, that's very interesting! No clue what's going on here, will have to look into that.

[NyxCode]

Hm. Seems like serde is copying the #[ts(concrete = "..")] attributes over into it's impl Serialize. That's not good.

Unless there's some way to prevent that, we'll have to change the syntax, maybe to

#[derive(TS)]
#[ts(concrete(B = TsDriver)]
struct Expression<A, B: Driver> { }

[WilsonGramer]

@NyxCode Looks like changing the attribute to be on the struct instead of the generic parameters is the way to go — see dtolnay/syn#422.

[WilsonGramer]

@NyxCode I just opened #262 to make the attribute be on the type instead of the generic parameters!

[NyxCode]

FYI @WilsonGramer: in #264, we got rid of the : TS bound in

trait Driver {
    type Info: TS;
}

by generating smarter bounds on the impl.