-
Notifications
You must be signed in to change notification settings - Fork 194
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
Proposal: New handling of type aliases - new generics handling #818
Comments
I was thinking of something similar, albeit more focused on the type parameters (and not the properties): #[derive(serde::Serialize, serde::Deserialize, utoipa::ToSchema)]
struct Pet<T> {
id: u64,
name: String,
age: Option<i32>,
generic_property: T,
}
struct Pet2(Pet<String>);
impl<'__s> utoipa::ToSchema<'__s> for Pet2 {
fn schema() -> (&'__s str, utoipa::openapi::RefOr<utoipa::openapi::schema::Schema>) {
Pet::<String>::to_schema_builder()
.with_type_parameter_alias::<T>("String")
.build()
}
} We already have Anyway the crux of it is implementing |
@nik-here This is pretty good. Well thought implementation. I'll give this some solicitude and see if I can get some kind of solution for this long dragging issue. |
@JMLX42 @nik-here I think the implementation will be something from between the two. I start to believe that the generics must be wrapped with unnamed struct type as shown above.
Otherwise they wont work because we need the name for the generic schema which then will be the unnamed struct name. The unnamed struct can be used to reference the schema in the codebase. Directly inlining the instance of generic type definitions would not know which type to refer in schema. Maybe if possible it could directly create inlined schema in such a case. That said if there will be a new implementation I will most certainly scrap the current aliases implementation. |
@juhaku I have a new working proposal we've been working for with a colleague. I'll try to post it in the upcoming days. |
@JMLX42 Please do, and thanks for helping out ❤️ |
I have now a draft design in my head of how it at least in theory could work. And I am ready to test it out. |
We have a macro that allows to build this: #[derive(Serialize, ToSchemaAlias)]
#[alias(type_parameter(T = MyType))]
struct MeshLinks(Links<MyType>); Where The macro iterates over the schema built by
|
Nice idea, This allows using references in generic schemas whereas the current new implementation will always inline the generic implementations. |
What about an another approach to the macro
ToSchema
for aliases?This library could add another trait like this:
The purpose of
build_schema
is to dynamically generate new schemas, depending on the given HashMapgenerice_properties
.This trait would be implemented by the macro
ToSchema
instead of the traitToSchema<'__s>
for generic structs. However non generic structs implementToSchema<'__s>
directly. On top theToSchema<'__s>
trait would lose the functionaliases
.Each alias would implement
ToSchema<'__s>
separately and they callbuild_schema
with a generated HashMap.Here is an quick example, how an implementation by the macro should look like:
As you can see this issue #703 would be fixed by this.
Additionally it would be possible to implement a macro
#[alias]
, which is mentioned here #790 (comment).What are your thoughts on this?
The text was updated successfully, but these errors were encountered: