C++ Logo

std-proposals

Advanced search

Re: Proposal - Allow '.' operator to work on pointers (again sortof)

From: Arvid Norberg <arvid.norberg_at_[hidden]>
Date: Thu, 5 Mar 2020 12:54:03 +0100
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

Received on 2020-03-05 05:58:15