From e8256d66667e0fd40f57b04ec37ec4ff3661c635 Mon Sep 17 00:00:00 2001 From: mejrs <59372212+mejrs@users.noreply.github.com> Date: Tue, 15 Apr 2025 10:52:12 +0200 Subject: [PATCH 1/2] Fix hyperlinks --- src/frequently-requested-changes.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/frequently-requested-changes.md b/src/frequently-requested-changes.md index 3e5229b..fde7586 100644 --- a/src/frequently-requested-changes.md +++ b/src/frequently-requested-changes.md @@ -214,6 +214,6 @@ of tail or internal padding, as they can be reused due to the lack of a possible Cross-referencing to other discussions: -* https://github.com/rust-lang/rfcs/issues/1397 -* https://github.com/rust-lang/rust/issues/17027 -* https://github.com/rust-lang/unsafe-code-guidelines/issues/176 +* +* +* From 99d81d9355791f0ad041a5854fcfe15028b8082f Mon Sep 17 00:00:00 2001 From: mejrs <59372212+mejrs@users.noreply.github.com> Date: Wed, 16 Apr 2025 13:31:58 +0200 Subject: [PATCH 2/2] frequently requested changes: bypassing visibility --- src/frequently-requested-changes.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/src/frequently-requested-changes.md b/src/frequently-requested-changes.md index fde7586..78af6a2 100644 --- a/src/frequently-requested-changes.md +++ b/src/frequently-requested-changes.md @@ -217,3 +217,26 @@ Cross-referencing to other discussions: * * * + +## 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 `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.