Casey Carter

(Disclaimer: I'm _not_ the FP expert on our team.) My initial response is to see this as a feature rather than a bug; the user requested non-standard behavior via the...

> > I don't think there's anything we can do here to fix it, you can complain to gcc? > > This is already fixed on the G++ 14 branch....

Our implementations of parallel algorithms delegate to the serial implementations when the `ExecutionPolicy` is `execution::seq`, or when they fail to allocate memory needed to parallelize. Consequently, our serial implementations need...

I'm going to mark this "decision needed" so we can discuss it in the maintainer meeting this week. We need to decide how we're going to communicate to Nvidia and...

@frederick-vs-ja Good news: DevCom-10588147 is fixed in 17.12p3. Bad news: Now only EDG fails the repro. =/ Did you file a separate bug against EDG, or should we do so...

I agree that the input iterator requirements imply that `i->flip()` must work since `(*i).flip()` does. (I also agree that the `vector` spec is a mess.) It's not clear to me...

> Indeed, the semantic equivalence between `a->m` and `(*a).m` is unachievable when `*a` is an rvalue and `m` denotes some not-fortunate-enough member (still very common, e.g. a public non-static data...

For reference, making `flip` callable seems feasible by moving it from `_Vb_reference` into `_Vb_iter_base` (which is a base of both `_Vb_reference` and the iterator types) and having `_Vb_iterator::operator->` return a...

> [[iterator.cpp17.general]/1](https://eel.is/c++draft/iterator.cpp17.general#1) only says `m` denotes an identifier, not an arbitrary name. So given `~reference` and `operator=` are not identifiers, IIUC, they're not counted for the requirements. Aha! Yes, thanks....

> About the non-standard issue: I think it's not about the constructor of `std::exception`, but rather about the behavior of the derived classes like `runtime_error(const char* what_arg)` - there I...