[...]
Smart pointers were given as an example.
Smart pointers continue to work as they do, because they are an object that contains a pointer to an object, and are not 'pointers'. they are of a class type 'smart pointer', they are not pointers to a class of type 'smart pointer'.
I provided examples, in this list and updated in the gist, of how pointer to smart pointers can still work, and actually '.' operator which can perform indirection can simplify that use case by still just being 'access property of pointer'.
Here's an example:
std::shared_ptr<Foo> p = ...;
There is no '*' or '&' or [] there. The proposed modification changes nothing.
std::cout << p.unique() << '\n';
Does call a function on shared_ptr<> or on Foo?
(hint: unique() used to exist on shared_ptr, was deprecated in C++17 and removed in C++20)
If I understand your proposal correctly, it would break the feature of this code failing to compile in C++20.
again, that is not a *(pointer), that is an instance of a class, aka an object. '.' remains working on objects exactly the same. and C++20 removing .unique() will fail. there's no pointer to perform indirection on. It was certainly bad phrasing to say "allow operation '.' to behave like '->' " .
Perhaps more importantly, if there are ever *new* member functions added to shared_ptr<> in a future version of C++, that would case similar kinds of breaking of code.
and still it's not a pointer to class as the left hand value of '.' . Smart pointers are instances of pointers... a unique pointer can be a **. For instance in my C library I pass the address of the pointer of the list, which allows me to update that in-place; pass by reference even... and forwarding that ** keeps the original pointer instance all the way back so there's really only 1 instance of the reference to the list in memory. (But, I digress, you didn't use any * and I'm spewing them all over).
J