Casey Carter

> A single test on `x86 x86 8` failed: > > ``` > 1: Failed Tests (1): > 1: libc++ :: std/thread/thread.condition/thread.condition.condvarany/notify_one.pass.cpp:2 > ``` > > However, this seems like...

That is almost certainly the design intent, but AFAICS that design intent doesn't matter. The wording clearly indicates that we convert the argument into a span and use the result...

Verified the changes still match MSVC-PR-569343 as of iteration 4.

Bit of a hack that fixes _only_ `expected` iterators - and not an entire class of such problems. Tell `expected` that it is equal to nothing: ```diff template + requires...

> Interesting. I guess this is just predicated on the knowledge that `std::any` isn't equality comparable anyway so there's (I guess) no harm in just removing the overload for `expected`?...

For posterity, my reduced repro: ```c++ struct any { template any(U&&); }; template struct expected { template expected(U&&); template requires requires(const T& t, const U& u) { t == u;...

I've gotten clarification from LWG on what the defective wording intends to say. I'll push changes for my review comments in the next couple of days (and prepare an LWG...

> I know C++26 features aren't being accepted at the moment but this should probably be blocked on the outcome of https://wg21.link/P3415 Half of the reason to ship experimental features...

I've done some investigation of this while resolving #315, with amazing results. For reference, the "old" `atomic` visualizer looks like: ```xml {*($T1*)&_My_val} *($T1*)&_My_val ``` After the `atomic` refactoring from VS...

We need to investigate this sooner rather than later to determine exactly how we're going to make UCRT functions `constexpr`. I suspect we'll have to teach the compiler(s) to recognize...