Frequently requested changes: add bypassing visibility

[mejrs]

Inspired by @RalfJung at https://internals.rust-lang.org/t/discussion-allowing-unsafe-to-bypass-visibility/22606/8

---

A way to bypass visibility, including an unsafe bypass

Items are only accessible if they are marked pub or re-exported as such;
they are otherwise private by default. People sometimes wish to break that
rule to access internals of libraries they're using, for example to access
private fields of a type or to call private functions.

This could break invariants assumed by the crate's author, which, if any
unsafe code depends on those, could lead to undefined behavior.

More importantly, allowing people to violate privacy would destroy SemVer.
If people can access and use implementation details of other crates then
that means that almost any change is now a breaking change. This would lead
to widespread fallout across the crate ecosystem.

Making it unsafe does nothing to prevent these issues. unsafe is
used to deal with memory safety problems and it is not in any way useful to
deal with SemVer concerns.

Forking a crate (to insert the necessary pubs) does not have these
problems. As such, a better way to achieve this would be to make patch
dependencies more ergonomic to use and maintain.

[mejrs]

@rustbot labels +I-lang-nominated

[rustbot]

Error: The feature relabel is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[tmandry]

Thanks, this looks good to me. Nominating for team discussion.

[traviscross]

This line doesn't read correctly to me as stated, i.e. "or re-exported as such" seems too strong. E.g.:

mod m {
    fn f() {}
}
pub use m::f; //~ ERROR function `f` is private

[traviscross]

Suggested change

	Forking a crate (to insert the necessary `pub`s) does not have these
	problems. As such, a better way to achieve this would be to make patch
	dependencies more ergonomic to use and maintain.
	Forking a crate (to insert the necessary `pub`s) does not have these
	problems, and so making patch dependencies more ergonomic to use and
	maintain could be one alternative to explore.

[traviscross]

Suggested change

	Making it `unsafe` does nothing to prevent these issues. `unsafe` is
	used to deal with memory safety problems and it is not in any way useful to
	deal with SemVer concerns.
	This does not fit with our model of `unsafe` in Rust.

[traviscross]

Suggested change

	More importantly, allowing people to violate privacy would destroy SemVer.
	If people can access and use implementation details of other crates then
	that means that almost any change is now a breaking change. This would lead
	to widespread fallout across the crate ecosystem.
	It's also hard to see how allowing privacy violations could be made
	compatible with SemVer.

[joshtriplett]

It seems worth adding a note here somewhere that unsafe does allow the use of transmute or similar, which could be used to read or write memory in ways that bypass privacy, but that that's a violation of semver and we would strongly discourage it. Something like "transmute allows this, but at least has the advantage of looking obviously wrong and dangerous on the surface. We don't see any value in making such a semver violation more ergonomic."

[traviscross]

We discussed this in the call today, including debating the merits of the "devil's advocate" case. Where we landed is that we're OK with including this item, but in addition to the edits above, we probably want to edit this further so that it reads more as "here's why this would be hard and some of the problems you'd need to address in any proposal" rather than as seeming to suggest that we'd never do it.

Essentially, a proposal for this would need to discuss, among other things:

• Why forking the crate isn't good enough (e.g. has too much hassle, and why there might be a limit to how much we could reduce that hassle).
• How the user could assert responsibility for breaking the crate's use of visibility to ensure soundness and to make SemVer guarantees in a way that we might find acceptable (e.g. "I'm choosing to act like a debugger here") and why we should find that acceptable.
• How this mechanism would affect -- or more to the point, shouldn't affect -- how people think of stability surfaces and library evolution, and how this could be communicated.