-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Possibly bogus private type warning with trait impls #32318
Comments
Duplicate of #30503 |
While I'd consider them to be slightly different issues (private type aliases in public signatures vs type aliases used internally/hidden in trait impls) where one could be allowed while the other not... If #30503 is decided on positively it certainly would fix this! My inclination is that as far as trait impls are concerned, this sort of checking should at most only apply to associated types and |
|
The impl itself is not hidden, but the inner implementation of it is. The public/exposed part is that the impl exists, any of its associated type bindings, and that it may have generic trait bounds. I guess the conceptual difference for me is that the type signature of an impl'd method can never really change; it's just not possible, even if you use a type alias in place of another type. Guess I'm splitting hairs though, either way I certainly would like to see the ability to use |
The original code now compiles without any warnings, so I'm going to close this. |
The following example triggers a E0446 complaining about a "private type in public interface" even though it's only used in a trait impl, and not actually exposed to the public.
For some context, a more realistic usage pattern where I've seen this come up a few times is with associated types. This was valid before the change, though whether it was intentional or not I'm not sure... It seems reasonable to allow it to me:
The text was updated successfully, but these errors were encountered: