-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: #[ts(bound)]
attribute
#268
Comments
I'm a bit confused why this doesn't need a |
Ah, never mind - thought i was losing my mind here for a second. |
@NyxCode You're right, I meant to write this: impl ts_rs::TS for Outer<TsDriver>
where /* no bounds */
{
...
} ...because |
Actually it looks like #264 preserves the type parameter in the impl block — is that the correct behavior? #[derive(TS)]
#[ts(export, concrete(D = TsDriver))]
struct Outer<D: Driver> {
inner: Inner<D>,
} Generates this: impl<D: Driver> ts_rs::TS for Outer<D>
where
D: ts_rs::TS,
{
type WithoutGenerics = Outer<TsDriver>;
...
} But shouldn't it generate this? impl ts_rs::TS for Outer<TsDriver>
{
...
} |
Ah, alright, now I see where the confusion came from. So the original Then, we tried actually generating Therefore, we settled on generating Everything works like it was an So the tl;dr why it didnt work is: If you access an associated type of a concrete type (e.g Footnotes |
@NyxCode What do you think about requiring that the associated types be spelled out completely (ie. #[derive(TS)]
#[ts(export, concrete(D = TsDriver))]
struct Inner<D: Driver> {
info: <D as Driver>::Info,
} Then I believe Rust would raise an error whenever it can't determine which associated type to use. That would also solve the issue of multiple trait bounds. |
Absolutely, that'd have worked! With the codegen as-is, which does We didn't see any downside with generating |
Well, there is one downside, which is that you don't get a compiler error if you do Since (we hope) most users just use |
@NyxCode Got it! I just tested the latest changes on main, but I'm still getting the extra bound when I use ts_rs::TS;
trait Driver {
type Info: TS;
}
struct MyDriver;
#[derive(TS)]
struct MyInfo;
impl Driver for MyDriver {
type Info = MyInfo;
}
#[derive(TS)]
#[ts(export, concrete(D = MyDriver))]
struct Inner<D: Driver> {
info: D::Info,
}
#[derive(TS)]
#[ts(export, concrete(D = MyDriver))]
struct Outer<D: Driver> {
inner: Inner<D>,
} impl<D: Driver> ::ts_rs::TS for Outer<D>
where
+ D: ::ts_rs::TS,
{
...
} Basically, the current implementation requires |
Yup, we're on the same page here! The tradeoff between the two solutions of generating trait bounds we explored turned out to be:
So you're absolutely right here - The generated bound |
OK great! I am putting together a |
Awesome, thanks! I think the best place to add it is here. If there's a |
I just implemented the attribute here: main...WilsonGramer:ts-rs:bound-attribute Let me know what you think! |
Is your feature request related to a problem? Please describe.
#264 introduces the
#[ts(concrete)]
attribute, but it can generate unnecessary bounds on the type parameter when it's used "directly" in a type:ts-rs thinks that a value of type
D
is used inOuter
because it's passed as a parameter toInner
, when in realityInner
only usesD::Info
. The generated code looks like this:Describe the solution you'd like
Add a
#[ts(bound)]
attribute to let people specify the bounds on theTS
impl manually:Which would replace the auto-generated bounds with the provided string:
Describe alternatives you've considered
See #261 and #264.
The text was updated successfully, but these errors were encountered: