[LLVMdev] New type of smart pointer for LLVM

[David Blaikie]

On Thu, Oct 2, 2014 at 9:11 AM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

>
> > On Oct 1, 2014, at 3:53 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> >
> > I even question whether we need a "maybe owning" smart pointer, or
> whether this is just an indication that the underlying data structure is
> *wrong*. The idea of "maybe" and "owning" going to gether, in any sense,
> seems flat out broken to me from a design perspective,
>
> I absolutely agree with this.
>

I'm uncertain about this, but willing to believe it's a bad idea. I've been
looking rather narrowly at code when I do unique_ptr cleanup and sometimes
don't have the context (or the time/inclination to build the context) to
consider larger design changes that might remove the need for this semantic.


>
> > and so I'm not enthused about providing abstractions that make it easier
> to build systems with unclear ownership semantics.
>
> We have a number of APIs that use this model, without abstractions.  To
> the extent that providing the abstraction encourages the model, it's
> dangerous.  But if it helps to clarify the code that's already there and
> facilitates a transition to better models, then it might be worthwhile
> anyway.
>

Agreed. If we come to the conclusion that this idiom is wrong, I might
still be happy to migrate these existing APIs (listed 10-15 I could find
with a quick search) under the notion that this device is still a sign that
something cunning is going on and we'd rather remove the cunning if/when
possible.

Alternatively we decide this is just totally bad ownership design, push
back against it & come up with some relatively regular refactoring I can
make when I come across these - and I'll just apply that and remove the
semantic that way, up-front, rather than migrating to a stop-gap.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141002/3943c434/attachment.html>