Add `pub impl` (NOT Trait!) for edition 2021

This post was flagged by the community and is temporarily hidden.

we haven't checked


If an impl block contains no pub items, it doesn't show up in the docs.

For granular control over publicity, use pub(in path).

To generate docs for internal items (which are not pub to the outside world), you can use cargo doc --document-private-items.

Please, do the minimal amount of testing before asking others to do so for you. If you can test it directly for yourself, you shouldn't be starting a thread on IRLO, especially with "I haven't tried it, but."

I appreciate the longer example, but in this case the signal is lost to the noise. You've just supplied a block of (untested) code without even specifying how you want the docs to show up, specifically.


Wait, this can prevent e.g. having an item visible in a module, while letting said item be visible to another function/method? That is can you turn off the default visibility?

Ah, fair enough, we would've expected it to, y'know, "this impl has docs -> add it to the docs". As there's no visibility modifier on impls. Good to know tho.

Given that the cutoff for basic design work and similar is April 1 for the 2021 edition, there's functionally a zero chance of this landing even if it were desired.

1 Like

Eh, just straight-up require "pub" before "impl" in 2021 edition? The details of the rest of the stuff can be worked out later.

Basic design work includes having an approved or almost certainly approved plan, to be clear.

That would be a wildly breaking change. It would also be redundant at the language level. If you want to control how documentation is generated, that shouldn't be a core language construct, because it does not and should not affect the visbility behavior of the functions. It should instead be either a #[doc(…)] attribute or a command line rustdoc flag.


Doc visibility and item visibility are tightly coupled already. Also it'd be nice to have that one extra visibility (impl-private) which we don't have today.

It's a breaking change, hence edition boundary, but it can be automatically fixed.

This isn't really a good justification for major breakage, whether it's introduced in an edition or not is irrelevant there.

Perhaps it's just me, but it seems like you try and introduce a lot of new features, which get shot down because they're half-baked at best, and really bad ideas at worst. And after that you move on and try again with something else, rinse and repeat. Now, I do appreciate your enthusiasm, that is a great thing to have around here.

But I also believe that that pattern should tell you something, and that something is that you need to think a lot more about the pros and cons of a potential new feature before even talking about it here. This is because even posting here means other people will read it. And if the post introduces some half-baked feature that is going to be shot down, then it stands to reason that others are effectively wasting their time in discussing that feature.

Now of course it should be possible to discuss a potential feature even when you can't see all the pros and cons, some of which might be counterintuitive or non-obvious.

However, doing that again and again, and then not seeing them through, wastes the time of other people, and gives you a reputation for "low signal, high noise", so to speak. Personally I'm now at a place where I'm questioning whether a new topic started by you is even worth reading, and that is unfortunate.

So I'm asking you, for your sake as well as that of the rest of us, please consider new features more fully before just throwing them out here "to see what sticks".


Why's this major breakage? We don't see it. We consider it no more different than | at the start of a pattern or , at the end of a [whatever]. That's why we're even suggesting it in the first place.

It'd be really cool to have the ability to have struct-private methods and functions, that aren't exposed outside of (inherent) impls on that struct. Because we'd use it. Because it'd help us catch bugs. Those things make it cool. .-.

You can already achieve this effect today in stable rust by putting the type and impl block in a module. I fact that kind of privacy control is one of the main reasons that modules exist. If you do that you have full control over what can access the associated items and what cannot.


Sure, but module boundaries reset rather than inherit imports. Even for inline modules.

That's easily worked around with a use super::*; statement in the module.

1 Like

Hm... and that works for the non-pub occurrences of use?

As long as the item is available in the name space of the parent module, the child module imports it as well.

1 Like

Because virtually every crate in existence would need to change, since every impl block is affected.

It's been said before, but it bears repeating - editions are not a tool for forcing enormous changes on every single crate author.


So... !pub impl then? (See also dyn, tho.)

Critical pattern to learn: when someone tells you there are fundamental problems with your proposal, your reaction should not be "what's the smallest and lowest-effort tweak I can make to my proposal to make someone consider it again". Your reaction should be "let me carefully consider that, and understand what pattern I'm missing here or what information I'm not understanding that's producing this response".

In other words: since your proposals are repeatedly generating negative responses, you need to consider what's causing that, and your default (correct) assumption should be that it's a fundamental problem with the nature of many of your proposals.


I don't understand what you're proposing.

dyn Trait is not comparable to your proposal, for a couple of reasons:

  • There is a concrete problem being solved by dyn Trait - confusion between traits and trait objects. The meaning of impl MyTrait for Box<dyn MyTrait> {} is significantly less clear without dyn Trait, since the two usages of MyTrait have completely different meanings.
  • Using dyn Trait works on all editions, and leaving off dyn produces a warning. Thus, making dyn required in the 2021 edition (which AFAIK has not yet been decided) would be effectively upgrading a warning to a hard error, not introducing and requiring a different syntax simultaneously.