3 ms·

The SemVer argument is that a 1.0.0 to 1.0.1 bump shouldn't cause any downstream code to stop compiling. In this case this really just means that reflection sho

The SemVer argument is that a 1.0.0 to 1.0.1 bump shouldn't cause any downstream code to stop compiling. In this case this really just means that reflection shouldn't allow you to construct an instance of a type from its public fields if the type is annotated with #[non_exhaustive]. This is also an argument against even having an unsafe reflection API that allows access to private fields, because being able to construct an instance of a type from its private fields means depending on something that SemVer normally protects you from, and an API being unsafe isn't supposed to be an opt-out for SemVer.

vlovich123 2y ago
You should probably have access to all fields you would otherwise be able to see (eg pub crate or private within the same module)
alkonaut 2y ago
I didn’t follow that argument, where would reflection be used here? Was the problem that if parentlib 1.0.0 used reflection on childlib 1.0.0 then potentially bumping childlib to 1.0.1 would cause it to completely break the functionality of parentlib? In that case yes, that’s what I’d expect would happen. And I’d still think it’s useful functionality.
- lilyball 2y ago
  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.
  - alkonaut 2y ago
    What would this change be that made parentlib stop compiling? Wouldn’t changes to the child lib just potentially stop parentlib from running properly (when an expected private field is missing or similar)?

vlovich123 2y ago

You should probably have access to all fields you would otherwise be able to see (eg pub crate or private within the same module)

alkonaut 2y ago

I didn’t follow that argument, where would reflection be used here? Was the problem that if parentlib 1.0.0 used reflection on childlib 1.0.0 then potentially bumping childlib to 1.0.1 would cause it to completely break the functionality of parentlib? In that case yes, that’s what I’d expect would happen. And I’d still think it’s useful functionality.

lilyball 2y ago
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.
- alkonaut 2y ago
  What would this change be that made parentlib stop compiling? Wouldn’t changes to the child lib just potentially stop parentlib from running properly (when an expected private field is missing or similar)?