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
error: no associated item named `A` found for type `main::Foo` in the current scope
I can understand why this error occurs: variant access such as Foo::A occurs via a path, and type Bar = Foo simply aliases the type, not the path accessor, thus an error is produced when trying to access an enum's variants via an alias.
In examples like the one above this normally isn't a huge issue as it is possible to pub use Foo as Bar instead, which accomplishes the same thing in practise.
However, in practise I often come across cases where pub use does not suffice. The most pressing use-case I've come across is when Foo has a type parameter, and I want to create an alias of Foo with the type parameter filled, i.e.
Here I want to expose Bar from my API as if it were a Foo<i32> when it comes to its use as a type as well as variant access. Doing a type alias (as above) allows for using Bar in signatures without issues (see the fn baz signature) however I cannot access the variants using Bar, meaning I would have to also require a user to import Foo in case they wish to access variants. Alternatively, if I instead pub use foo::Foo as Bar I can now access variants using Bar without issue, however the type parameter is no longer filled, meaning the fn baz signature no longer works and I'm unable to express through my API that Bar should always be Foo<i32> and not Foo<T>.
It would be really nice if we could either:
pub use Foo<i32> as Bar; or
pub type Bar = Foo<i32>; // This allows variant access via Bar::A
The text was updated successfully, but these errors were encountered:
Currently the following is not allowed:
playpen
This code produces the following error:
I can understand why this error occurs: variant access such as
Foo::A
occurs via a path, andtype Bar = Foo
simply aliases the type, not the path accessor, thus an error is produced when trying to access an enum's variants via an alias.In examples like the one above this normally isn't a huge issue as it is possible to
pub use Foo as Bar
instead, which accomplishes the same thing in practise.However, in practise I often come across cases where
pub use
does not suffice. The most pressing use-case I've come across is whenFoo
has a type parameter, and I want to create an alias ofFoo
with the type parameter filled, i.e.playpen
Here I want to expose
Bar
from my API as if it were aFoo<i32>
when it comes to its use as a type as well as variant access. Doing a type alias (as above) allows for usingBar
in signatures without issues (see thefn baz
signature) however I cannot access the variants usingBar
, meaning I would have to also require a user to importFoo
in case they wish to access variants. Alternatively, if I insteadpub use foo::Foo as Bar
I can now access variants usingBar
without issue, however the type parameter is no longer filled, meaning thefn baz
signature no longer works and I'm unable to express through my API thatBar
should always beFoo<i32>
and notFoo<T>
.It would be really nice if we could either:
pub use Foo<i32> as Bar;
orpub type Bar = Foo<i32>; // This allows variant access via Bar::A
The text was updated successfully, but these errors were encountered: