[boost] Re: TR2 and C++0x heads up

From: Andrei Alexandrescu (See Website For Email) (SeeWebsiteForEmail_at_[hidden])
Date: 2005-04-26 23:48:04

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