Corentin Jabot wrote:
> code is code.
> if a developer relies on the names, presence, order, or shape of private
> members of a third party library, it is not robust over time.
>
> The long term ability to maintain large projects at scale trumps the very mild
> inconvenience of more robust defaults.
>
> If someone wants to reflect on private members, it should be explicit. it has
> nothing to do with usage or usefulness, it has to do with ensuring a healthy
> ecosystem in the presence of Hyrum's law, to the extent that we can.

Code can already rely on a lot of things it isn't supposed to rely on.

It can rely on the size or alignment of library types. It can rely on the order
and placement of the fields of `struct timespec`, even though that's
explicitly unspecified.

More to the point, it can rely on the result of every type query in <type_traits>
even when no such results are guaranteed by the documentation of a library
type.

Even though all this complicates our (standardization) work because it makes
it effectively impossible for a change to be "unobservable to a correct
program", we consider the tradeoff acceptable, because the reflection
functionality in <type_traits> is useful enough to outweigh the costs.

It's the same with <meta>. Every query there makes things more observable
than before. And that's exactly what <meta> is for.