Lauri Vasama wrote:
> Indeed, the current model is very consistent. The requested change is not
> motivated by ideas of philosophical purity or the like, but rather by very
> practical implications.
>
> The first issue is safety. Reflection of program metadata (not involving
> splicing), which by necessity happens entirely at compile time, is always
> memory safe. Splicing of non-public members on the other hand is a
> fundamentally unsafe operation. The access controls protect class invariants
> from being invalidated by external actors, and they protect external actors
> from concurrent access happening within the class. Violating assumptions
> through either route leads to undefined behaviour.
>
> A good demonstration of the fundamental unsafety of access breaking comes
> from Rust. If such a feature existed in Rust, it would have to be considered
> unsafe, lest the entire borrow checker be made unsound. In a time when
> safety is more important than ever, C++ should not be introducing new
> implicitly unsafe features.

Does this objection also apply to const splicing? You can const_cast it away,
but const_cast is already unsafe (would have been marked unsafe in Rust).