P1328R1 constexpr type_info::operator==()

[StephanTLavavej]

P1328R1 constexpr type_info::operator==()

Feature-test macro:

#define __cpp_lib_constexpr_typeinfo 202106L

[cpplearner]

type_info is defined in <vcruntime_typeinfo.h>, which is not part of this repo.

[StephanTLavavej]

I have created an internal PR to update vcruntime_typeinfo.h in 17.3 Preview 1, after which we can fully enable this feature with a GitHub PR. Unfortunately, VCRuntime open-sourcing is indefinitely delayed again.

[StephanTLavavej]

Merged MSVC-PR-392482 for 17.3 Preview 1.

[jonwil]

Is the vcruntime open source delay because of the previously mentioned performance stuff? (i.e. the lack of a way to make sure 3rd party submissions aren't hurting perf)

[CaseyCarter]

Is the vcruntime open source delay because of the previously mentioned performance stuff? (i.e. the lack of a way to make sure 3rd party submissions aren't hurting perf)

Yes, that is the case. Until we have some kind of benchmarking in place to defend against critical perf regression, we're not comfortable open-sourcing VCRuntime. (Despite that the vast majority of VCRuntime changes that come from the STL don't touch perf-critical code.)

[jonwil]

Obvious question is why it can't be opened up but (as with patches that break ABI) patches to perf critical code not accepted for merge until the infrastructure is in place to detect regressions.

[CaseyCarter]

Obvious question is why it can't be opened up but (as with patches that break ABI) patches to perf critical code not accepted for merge until the infrastructure is in place to detect regressions.

That's a good question which I wasn't motivated enough to get an answer to. @MahmoudGSaleh and @mnatsuhara were involved more directly in the cross-team opensourcing discussions, maybe Mahmoud could comment?

[StephanTLavavej]

17.3 Preview 1 didn't contain an MSVC toolset update (due to factors outside of our control) - we are actually waiting for 17.3 Preview 2 here.