Date: Sat, 18 Jul 2020 15:42:50 +0300
Ville Voutilainen via Std-Proposals:
> On Fri, 17 Jul 2020 at 17:40, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>> But if that were actually the only use-case, then we wouldn't need ptr<T> at all! There's already an idiomatic C++ way of doing that:
>> void betterfunc(Foo& f);
>> ... betterfunc(local); ... // no ownership
>> ... betterfunc(*std::make_unique<Foo>(42)); // construct an owning unique_ptr, and then deallocate it afterward
>> If the parameter `Foo& f` were const-qualified, we could even do this:
>> ... betterfunc(Foo(42)); ... // construct a Foo and deallocate it afterward, without even using the heap!
>
> ..but if the parameter of betterfunc is supposed to be nullable, none
> of that nonsense works.
This is exactly why we need std::optional<T&> in the standard.
> On Fri, 17 Jul 2020 at 17:40, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>> But if that were actually the only use-case, then we wouldn't need ptr<T> at all! There's already an idiomatic C++ way of doing that:
>> void betterfunc(Foo& f);
>> ... betterfunc(local); ... // no ownership
>> ... betterfunc(*std::make_unique<Foo>(42)); // construct an owning unique_ptr, and then deallocate it afterward
>> If the parameter `Foo& f` were const-qualified, we could even do this:
>> ... betterfunc(Foo(42)); ... // construct a Foo and deallocate it afterward, without even using the heap!
>
> ..but if the parameter of betterfunc is supposed to be nullable, none
> of that nonsense works.
This is exactly why we need std::optional<T&> in the standard.
Received on 2020-07-18 07:46:21