On 20/11/2017 12:41, Peter Dimov wrote:
Peter Bartlett wrote:
The only nit I had in the paper was that after all the banging on about it being a value type, we are given operator bool, operator* and operator->, making it pointer-like again. Could operator T& and operator T const& work?
Polymorphic means virtual functions, and when you have a polymorphic_value<T> pv, where T has a virtual function `f`, you can call `pv->f()`. With a conversion to T&, you can't call `pv.f()`.
You could pass it as a parameter to something that accepts a T& or T const& and then make polymorphic calls from that, or alternatively locally define a separate reference variable: Container<Base> c(new Derived); Base& r = c; r.f(); // calls Derived::f() But yes, this is significantly messier (and more potentially surprising to users) than using operator-> instead. Additionally since polymorphic_value can be empty, retaining some pointer-like syntax seems preferable as again this makes it less surprising to consumers. Although on a peripherally related note, this reminds me of a language gripe I have with operator->, in that it is not used to resolve ->* expressions. This means that code such as (p->*f)(x) has to be changed to (*p.*f)(x) if p is converted from a raw to a smart pointer, because (almost) nobody ever implements operator->* explicitly. (Although I tried it as an experiment and it seems relatively straightforward to do so in C++11, albeit at the cost of injecting std::function.)