C++ Logo


Advanced search

Subject: Re: [std-proposals] Proposal - Allow '.' operator to work on pointers (again sortof)
From: Arvid Norberg (arvid.norberg_at_[hidden])
Date: 2020-03-05 05:54:03

On Thu, Mar 5, 2020 at 12:29 PM J Decker via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> [...]
>> 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 = ...;
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.

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.

Arvid Norberg

STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups