Skip to content
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

Redo generic handling #44

Open
oscartbeaumont opened this issue Feb 22, 2023 · 2 comments
Open

Redo generic handling #44

oscartbeaumont opened this issue Feb 22, 2023 · 2 comments
Labels
breaking change This will probs end up in the next major version.

Comments

@oscartbeaumont
Copy link
Member

I wonder if something like:

#[derive(Type)]
pub struct A {
   a: String
}
#[derive(Type)]
pub struct B {
   #[specta(inline)]
   b: Option<B>
}

should be export A = { b: { a: String } | null } instead of export A = { b: B | null }.

This would require a refactoring of the generic handling because currently the B comes from generics and is always a reference.

It would also be nice to add #[specta(inline_all)] which would opts.any_parent_inlined ? Type::inline : Type::reference for generics. This way.

Redo handling of opts. parent_inline. We should (in most cases) not pass opts directly to child impls because parent_inline is only valid for the type above the current one.

@oscartbeaumont oscartbeaumont added the breaking change This will probs end up in the next major version. label Apr 24, 2023
@oscartbeaumont oscartbeaumont added the blocked Blocked on external factor label Aug 12, 2023
@oscartbeaumont
Copy link
Member Author

oscartbeaumont commented Aug 12, 2023

This is blocked by limitations in stable Rust. If this playground (Rust issue) compiles on stable and meets Specta's MSRV/release cycle we can continue.

Potentially there is another way to make it work but this isn't important enough to try and make it work in a half-a**ed way.

@oscartbeaumont oscartbeaumont removed the blocked Blocked on external factor label Aug 19, 2023
@oscartbeaumont
Copy link
Member Author

I think there is a better way to do this. Removing the generics param from the trait would be nice and it can probably be done by some internal inferences using the macro & Rust's proper type system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change This will probs end up in the next major version.
Projects
None yet
Development

No branches or pull requests

1 participant