I'm guessing you define "const splicing" such that only a const
reference can be produced, or that only const member functions can be
invoked. This would prevent invariants from being broken, at least
through mutation of data members. Calling member functions is more
complicated. It would not protect the external actor from concurrent
access, although this is likely less common.

On 10/11/2026 19.59, Peter Dimov via SG7 wrote:
> 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).
>
>