I think it's a stretch to argue this.

I am unbelievably excited by reflection. But I also very strongly suspect
that we're going to see a slew of antipatterns appearing in the wild before
things settle down. Maybe analogous to the 'absolutely everything virtual'
that you see in code bases of a certain vintage.

Despite this, I think that reflection has so much to offer that I'd rather
see it deployed now.

But I would be very surprised if it doesn't create significant problems for
people. Some of these problems will hopefully decrease in frequency as
people learn the right idioms (and new ones are discovered). But just as
some people write C++ as if the last 25 years never happened, I think it's
a reasonable prediction that certain messes created by reflection will
never be cleaned up.

>From my perspective I think it's a price worth paying.



On Tue, 21 Oct 2025 at 17:22, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:

> On Tue, 21 Oct 2025 at 19:10, Ville Voutilainen
> <ville.voutilainen_at_[hidden]> wrote:
> >
> > On Tue, 21 Oct 2025 at 19:06, Tom Honermann <tom_at_[hidden]> wrote:
> > >
> > > On 10/21/25 11:47 AM, Ville Voutilainen wrote:
> > > > On Tue, 21 Oct 2025 at 12:20, Timur Doumler <cpp_at_[hidden]> wrote:
> > > >> I understand the calls for real deployment experience, but I don't
> understand how is a Contracts TS or whitepaper would help us get that?
> > > > Well, see, it's actually less about what the ship vehicle
> > > > semi-magically (I'm intentionally joking here) does. It's about what
> > > > chance anyone
> > > > has to experiment with the feature before we nail it into an IS.
> > > >
> > > > Let's face it, it's excruciatingly difficult and therefore unlikely
> > > > for so-called third parties to experiment with what we have right
> now.
> > > > You would
> > > > need to build a fork-branch compiler, and then deploy that and then
> do
> > > > the actual experimentation. That by nature shuts out quite a bunch of
> > > > users.
> > >
> > > The following is intended as a serious question; I'm not intending to
> > > throw shade at other C++26 features.
> > >
> > > The only implementation of P2996 reflection is in the same state of
> > > requiring a fork-branch compiler build of Clang. I'm assuming you
> > > consider that implementation sufficient for reflection because I don't
> > > see papers calling for its removal due to lack of deployment
> experience.
> > > There has been no deployment experience of P2996 reflection. Why is
> that
> > > sufficient for reflection, but not sufficient for contracts?
> >
> > Because the impact of reflection on APIs of C++ code in general is
> > much smaller, and much more controlled and contained,
> > and because the core language part that will be hard to change is
> > likewise better-contained and not everywhere-seeping
> > like it is for contracts.
>
> I should add, tho, that the above doesn't quite mean that your
> assumption is completely correct. And it isn't quite that.
> But there are priorities in life, and relative impacts to consider,
> and there's a limited amount of time to deal with
> all the various nondeployed things that we standardize. Some of them
> have proven to be deeper time sinks
> than others.
>