Apply suggestions from code review

Co-authored-by: Kevin Reid <[email protected]>

Author: mejrs

src/frequently-requested-changes.md

@@ -218,25 +218,25 @@ Cross-referencing to other discussions:
 * <https://github.com/rust-lang/rust/issues/17027>
 * <https://github.com/rust-lang/unsafe-code-guidelines/issues/176>
 
-## A way to bypass visibility, including a `unsafe` bypass
+## A way to bypass visibility, including an `unsafe` bypass
 
-Items are only accessible if they are marked `pub` or re-exported as such,
+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.
+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.
+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.
+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
+problems. As such, a better way to achieve this would be to make patch
 dependencies more ergonomic to use and maintain.