C++ Logo


Advanced search

Re: P0466: about the danger of type parameters deduced by &C::m

From: Kazutoshi Satoda <k_satoda_at_[hidden]>
Date: Sun, 6 Dec 2020 00:18:50 +0900
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:
> 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.
> 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.
> 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.


Received on 2020-12-05 09:18:56