Date: Tue, 10 Nov 2026 20:34:58 +0200
On Tue, 10 Nov 2026 at 20:25, Peter Dimov <pdimov_at_[hidden]> wrote:
>
> Ville Voutilainen wrote:
> > On Tue, 10 Nov 2026 at 20:00, Peter Dimov via SG7 <sg7_at_[hidden]>
> > wrote:
> >
> > > 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).
> >
> > I don't think const splicing significantly changes the picture. The standard
> > library has a requirement that const is physical const, but that doesn't
> > necessarily apply elsewhere.
>
> How do you envisage breaking an object's invariant using const splicing?
If I have a class with a thread-safe API that mutex-protects
concurrent member calls, and I get a data member reflection and splice
it,
even for reading, I have now opened the thing up for races that
couldn't have occurred before.
>
> Ville Voutilainen wrote:
> > On Tue, 10 Nov 2026 at 20:00, Peter Dimov via SG7 <sg7_at_[hidden]>
> > wrote:
> >
> > > 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).
> >
> > I don't think const splicing significantly changes the picture. The standard
> > library has a requirement that const is physical const, but that doesn't
> > necessarily apply elsewhere.
>
> How do you envisage breaking an object's invariant using const splicing?
If I have a class with a thread-safe API that mutex-protects
concurrent member calls, and I get a data member reflection and splice
it,
even for reading, I have now opened the thing up for races that
couldn't have occurred before.
Received on 2026-11-10 18:35:13
