On 2020/12/05 23:59 +0900, Arthur O'Dwyer wrote:
> If there's something in this vicinity to improve the safety and
> teachability of C++, I'd look harder at the idea that &C::b is sometimes
> *not* of type (T C::*). That seems like a construct that would come up
> (handwave) 100x more commonly than `is_pointer_interconvertible_with_class`
> — which is still far from common, but at least it'd be nice to fix, or at
> least figure out a specific reason why we can't.
>
> (Even if we could fix the type of &C::b, that's still an extremely uncommon
> construct, and it might not be worth fixing — just wall up that part of the
> language and never talk about it again. ;))

FYI, from the paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0466r5.pdf
> The awkwardness of the deduced type of pointer-to-member constants was
> discussed in core language issue 203; no action was taken for fear of
> breaking existing code.
https://wg21.cmeerw.net/cwg/issue203
> Additional note, April, 2015:
> EWG has determined that the utility of such a change is outweighed by
> the fact that it would break code. See EWG issue 89.
https://cplusplus.github.io/EWG/ewg-closed.html#89
> Discussed in Rapperswil 2014. EWG thought that the change to existing
> semantics would practically require a time machine, and noted that
> these semantics didn't appear by accident. Changing the semantics was
> estimated to break too much existing code, so closing as NAD.

-- 
k_satoda