<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 9:11 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Oct 1, 2014, at 3:53 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
><br>
> 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,<br>
<br>
</span>I absolutely agree with this.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> and so I'm not enthused about providing abstractions that make it easier to build systems with unclear ownership semantics.<br>
<br>
</span>We have a number of APIs that use this model, without abstractions.  To<br>
the extent that providing the abstraction encourages the model, it's<br>
dangerous.  But if it helps to clarify the code that's already there and<br>
facilitates a transition to better models, then it might be worthwhile<br>
anyway.<br></blockquote><div><br>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.<br><br>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.<br><br>- David</div></div><br></div></div>