I'm not quite up to date on the proposal and syntax, but the principle is
that anything "dangerous" needs to be easily visible/auditable. ie greppable

const_cast, reinterpret_cast are easily seen in even a skimmed code review.
And are greppable *with 0 false positives*.

Anything that breaks access controls should be the same - easily greppable
with 0 false positives. And by easily I mean don't make me use a regex.

The very first SG7 (an evening session run by Chandler) voted on access
control, and there was barely consensus to even allow reflection of private
members at all (waaay less consensus than, say, contracts).

The compromise was the promise that breaking access control would be
obvious and greppable.

Be seeing you,
Tony

(P.S. this is why get() on smart pointers is a bad name. It should be
"unwrap" or unsafe_get or or _anything_ more unique than "get". Because
unwrapping any wrapped object is typically removing a level of type safety
enabled by the wrapper, and should be given an extra moment of thought when
coding and in code review)

On Tue., Nov. 10, 2026, 1:00 p.m. Peter Dimov via SG7, <sg7_at_[hidden]>
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).
>
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>