Thorsten Ottosen wrote:
In Lillehammer we rejected a policy-based smart pointer and it should never have gotten that far; I mean, David H. spent a lot of time writing the proposal and that time could have been saved.
Although I understand "rejection" is an overstatement, I wonder how the committee deals with conflicts of interest. The ideological competitor to policy_ptr is shared_ptr, and while the former has zero backing up inside the committee, the latter is backed up by people who also get to lobby and vote. Now I'm not sure about others, but in such situation I'm biased. I mean, if I were to propose and back up X, I would naturally believe X is better than Y, Z, and even \Omega, and I won't be 100% objective. I wouldn't be unreasonable, but as soon as it would come about things that are hard to objectify, I'd assign more weight to negative arguments against the competing design (policies are complicated, not enough experience, too much choice etc.) than to arguments in favor of that design (the inclusion relationship between policy_ptr and its technical superiority that is obvious to me - but then hey, I'm biased). It's human nature. Case in point: shared_ptr fosters binary compatibility across calls to shared libraries with different allocators and all that jazz. That's an advantage, no doubt about that. But then people who proposed and back up shared_ptr assign a lot of weight to that argument, which I believe reflects their bias. Here's why. If people would really really believe this is a crucial advantage, they'd be looking at the rest of the standard and they would shriek in horror: "There's absolutely NO other component in the standard library - no string, no vector, no map, no allocator, no NOTHING that offers the same compatibility! But wait! There's even no standardization of dynamically-linked libraries!" So if they'd really be objective, they'd be into working on implementing the same stuff in containers and/or allocators like white on rice. But the truth is, nobody cares about string and vector not being passable across binary module boundaries. Now really - nobody blinks an eye. But whenever talk comes about shared_ptr, oh yes, that's essential! And that comes in conveniently with the argument that there is too much configurability ("too many notes") in policy_ptr, and therefore, what a wreck, each library will just misuse that configurability to create incompatible smart pointer stuff just for kicks. (At this point it is also very convenient to forget about things like good ole default template arguments, policy convertibility, and the upcoming type aliases.) So the question would be, how does the committee deal with conflict of interests like that? Because honest, if I were on the committee, every misplaced comma in the shared_ptr proposal would stick like a sore thumb to me, and I'd sure manage to convince others of the same. Andrei