A. Jiang
A. Jiang
Ah, I found that there's already LWG-554 which is closed as NAD. So perhaps we should make `numeric_limits::traps` `false` for all non-promoted integer types.
> * This stuff varies depending on not only the hardware and OS (like sizeof(long)), but also the compiler (and it wouldn't surprise me if Clang adds a -ftrap-zero-div flag...
> * False for int/char/bool, because that property is not about operations - it's about values, and more specifically about trap representations. Two's complement hardware doesn't have trap representations on...
> I'm not sure. I mean, object composition does not necessarily precludes calls unwrapping. Good. It seems to me that we can unwrap calls in `function::operator()` in an ABI-preserving way.
> [[func.wrap.general]](https://eel.is/c++draft/func.wrap.general) does not mention `function_ref`. Do you think it should? This is LWG-4264. I guess it should. But since `function_ref` has reference semantics and other polymorphic function wrappers have...
I found that explicitly constructing `atomic_ref` from `atomic_ref` was well-formed even before this DR, but it was broken because the constructor bound a temporary object (created due to `operator T`)...
`` is _not_ a core header, but it seems that we're just making it usable in kernel mode by skipping somethings. It should be investigated what are necessary for skipping....
BTW, it's possibly optimizing to simplify `operator
> Even if we optimize `operator
When NaN and Inf are not properly supported, should we make the corresponding function return `0.0` and `has_*` give `false`?