feat: Forward generics to the interface #264
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## feat/generics_forwarding #264 +/- ##
============================================================
+ Coverage 86.56% 87.25% +0.68%
============================================================
Files 25 25
Lines 1742 1812 +70
============================================================
+ Hits 1508 1581 +73
+ Misses 234 231 -3 ☔ View full report in Codecov by Sentry. |
jawoznia
force-pushed
the
generics_in_interface_implementation
branch
2 times, most recently
from
41dfe82 to
9ec276d
Compare
jawoznia
changed the title
jawoznia
force-pushed
the
generics_in_interface_implementation
branch
2 times, most recently
from
97d37e1 to
90fd2d2
Compare
| // | ||
| // Sylvia will fail to recognize generic used if their path is different. | ||
| // F.e. if we this query would return `SvCustomMsg` and we would pass | ||
| // `sylvia::types::SvCustomMsg` to the `Generic` trait paths would not match. |
There was a problem hiding this comment.
I don't understand it, and I don't like this limitation. It should work as in Rust. Could you explain what does it exactly mean?
There was a problem hiding this comment.
This is because when we check if generic type is used in context of given type it compares their full path.
In such case Msg, types::Msg and sylvia::types::Msg are three different types.
There was a problem hiding this comment.
I don't find this explains everything. types::Msg and sylvia::types::Msg are obviously not generic parameters - they are coming from a module, so you just should assume they exist and let Rust resolve it. Msg is either a generic type or a type available in global scope. Still, its Rust that would handle figuring out the exact type, but for additional codegen you should consider a type being maybe a generic argument only if it has no path besides the ident. If that is the case, you should be able to see the generic parameters of your definition block. If the ident you face is defined as generic, it is generic. Otherwise, it is not generic, and you don't make any further assumptions about that. I need help understanding how scoping makes any deal here. Could you give some very particular examples of what is possible and what is not? And I am not asking about a description of an example, but an example itself - I think some misunderstanding is happening here. We can a call about this if you want as it seems to be not trivial.
| Ok(Response::new()) | ||
| } | ||
|
|
||
| // Sylvia will fail if single type is used to match against two different generics |
There was a problem hiding this comment.
Wait, that means that I can't have both generics being monomorphized to String? That cannot be the case, and using particular solutions is not an excuse.
There was a problem hiding this comment.
These comments are actually related to the generic_contract where we pass the concrete types to the generics.
Comment landed here when I copied the examples.
|
|
||
| // Sylvia will fail if single type is used to match against two different generics | ||
| // It's because we have to map unique generics used as they can be used multiple times. | ||
| // If for some reason like here one type would be used in place of two generics either full |
There was a problem hiding this comment.
There are plenty of reasons for that, and we cannot make people using aliases for every generic String.
There was a problem hiding this comment.
Ye, now that I think of it it doesn't make sense.
I didn't want to initially change this behavior, but now as I look at the algorithm we basically take the list of generic parameters and traverse the signatures of methods. There is no risk of fake duplication as the iterated collection are passed generics.
I will change this.
| // | ||
| // Sylvia will fail to recognize generic used if their path is different. | ||
| // F.e. if we this query would return `SvCustomMsg` and we would pass | ||
| // `sylvia::types::SvCustomMsg` to the `Generic` trait paths would not match. |
There was a problem hiding this comment.
Again - I don't understand it, but it scares me.
Part of #263