-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Support importing enum variants through type aliases #83248
Comments
The reason You're probably better off trying to distinguish between imports of the original vs a reexport, for determining the deprecated status. |
@eddyb Is this the same reason that importing associated items doesn't work? I recall a tentative proposal for that from a few years ago: https://internals.rust-lang.org/t/importing-associated-constants/6610/4 , but I'm not sure what the current thinking is. Is it just something that's probably never going to be supported? |
@bstrie Yeah. In theory, you can use type Foo = <X as Trait<Y>>::AssocType; You could imagine getting CTFE involved as well, so that the type can only be known after const-evaluating an arbitrarily complex expression with miri. This is the sort of thing that separates the type-relative name resolution, from the regular name resolution: the typesystem itself has to be present for the former, but cannot soundly exist until the latter is complete. |
RFC 2338 made it possible to access enum variants through type aliases, like so:
However, the following code still fails to compile:
with:
Type aliases being limited in this way is a problem for libstd because it means that deprecating/renaming any enum must inevitably involve a breaking change, since re-exporting cannot be used (#30827). This was encountered in #82122 (review) .
The text was updated successfully, but these errors were encountered: