SemVer says that updating childlib from 1.0.0 to 1.0.1 cannot cause parentlib to stop compiling. If the update does cause dependents to stop compiling then this

SemVer says that updating childlib from 1.0.0 to 1.0.1 cannot cause parentlib to stop compiling. If the update does cause dependents to stop compiling then this must be a major version update. Rust does have some subtle holes in its rules for SemVer here where there are changes you can make in a minor version that have the capability of breaking your caller (and this is sort of ignored by the logic that the caller could have been more explicit in how it called the method, either using Universal Function Call Syntax or, in the case of inferred types breaking, specified an explicit type, but this does still cause issues from time to time), but overall it tries hard to stick to this rule. So any official Reflection API needs to take SemVer into account. Being able to access private fields from outside the crate that defines the type is always going to be a really big SemVer issue as private fields otherwise do not affect the public API of a crate (only the presence or absence of private fields on a type matters to public API). Similarly, outside of the defining crate, reflection can't allow for the creation of a #[non_exhaustive] type from its public fields as the type may gain more fields in a non-breaking update.