[Development] The future of smart pointers in Qt API

[André Pönitz]

> On Mon, Feb 03, 2020 at 11:53:57PM +0000, Scott Bloom wrote:
> > From: Development [mailto:development-bounces at qt-project.org] On
> > Behalf Of André Pönitz
> > [...]
> > An actual "need" for a unique pointer is typically a sign that
> > things are created, passed around until they end up somwhere, for
> > a long time so that people get unsure about ownership or have
> > developed an irrational fear of naked pointers.  Fixed by not
> > having the 'factory' create the object and pass the object
> > around, but by passing the factory around (by 'reference') and
> > letting the receiver create the object.  Additional advantage:
> > creation can take input both from the factory setup (say, lambda
> > capture) and the receiver side, saving potentially a lot of
> > state. And it's of course fine to use unique pointers if that's
> > not the reason. E.g. to delete dynamic stuff in case of early
> > returns. I.e.  a kind of, surprise, "scoped" pointer.
> > 
> > That people coming from Java exhibit a high affinity to shared
> > pointers is not exactly news in this millenium. A bit more
> > amusing is that some proponents of "modern" C++ demand using
> > unique pointers, when actually more direct, less boiler-plate
> > requiring tools (lambdas...) were standardized at the same time.
> 
> To be fair, while I 100% agree  with the reasons given, you are not
> listing one of the (only???) reasons, that a smart pointer shared
> or unique, are truly > necessary.
>  
> When you are working with the possibility that the lifetime of
> the pointer, might not be exception safe.   

Sorry for not being explicit, I meant this case to be covered by

 "And it's of course fine to use unique pointer [...] in case
  of early returns."

So, sure, that's a valid use case. But effectively this also uses
only the "scoped" feature of unique_ptr to ensure proper destruction,
not the feature to pass ownership around.

Andre'