You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The user shouldn't have to write out their own reflect::library! description of extern crate std. A complete definition of everything in std should be built in to the reflect crate because practically all users will need it.
We still need to keep reflect::library! so that users can provide definitions of crates other than std, for example if serde_derive were implemented using reflect then it would need to contain a reflect::library! providing all the relevant signatures from the serde crate.
The text was updated successfully, but these errors were encountered:
In core/std there are traits that are impl-ed with generic parameters for a generic type. Correct me if I wrong, but current library! syntax is not supporting generics and it's probably infeasible to perform trait solving to resolve generic traits implementations. So my question is, should we just ignore any impls that have generic parameters or traits that are implemented for the generic types?
We'll fully support generic impls. It's not hard because the RUNTIME::std::path::to::Trait style makes the macro author do the method resolution for us.
The user shouldn't have to write out their own reflect::library! description of extern crate std. A complete definition of everything in std should be built in to the reflect crate because practically all users will need it.
We still need to keep reflect::library! so that users can provide definitions of crates other than std, for example if serde_derive were implemented using reflect then it would need to contain a reflect::library! providing all the relevant signatures from the serde crate.
The text was updated successfully, but these errors were encountered: