(original) (raw)
On Thu, Oct 2, 2014 at 9:11 AM, Duncan P. N. Exon Smith <dexonsmith@apple.com> wrote:
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
\> On Oct 1, 2014, at 3:53 PM, Chandler Carruth <chandlerc@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