[Boost-users] Re: Re: [Foreach]TroubleiteratingoverBoost.MultiIndexcontainers

From: Ian McCulloch (ianmcc_at_[hidden])
Date: 2005-03-04 22:58:49

Peter Dimov wrote:

> David Abrahams wrote:
>> "Peter Dimov" <pdimov_at_[hidden]> writes:
>>
>>> That's the thing. It doesn't actually buy us anything.
>>
>> - Simpler matching rules
>> - Customizability for built-in types
>> - Code is explicit about what operation it's customizing and what
>>  operation it's calling.
>> - A few more, but you're disputing them below...
> 
> Customizability for built-in types, agreed. I don't really see the
> inherent value in the others. They seem like circular reasoning to me. The
> overload resolution rules are complex for a reason; if we could use
> something simpler instead, we would.

I'm not sure.  IIUC, for such library customization points the important
thing is not the ADL, but 2-phase name lookup.  If you could restrict name
lookup to a particular namespace during template instantiation, that may
well be a solution - just make the name visible in the namespace that the
library requires.  But the way name lookup works, to get lookup at the
point of instantiation you must use an unqualified name, which gives you
ADL as well.  Is it really essential that these notations are coupled in
this way?

> 
>>> In practice people tend to respect de-facto standards; a + b is an
>>> addition, and swap(a, b) swaps a and b. The main fight is over who
>>> gets to keep the primary template.
>>
>> No, the problem is what happens when you have no de-facto standard.
>> Customizable interfaces get invented, and when they do, they are just
>> some new thing.  Everybody wants to think that they will invent the
>> de-facto standard use for a name, but sometimes these things collide.
>> Just look at _1, _2, et. al.
> 
> Right. And if they did not collide, nothing would become a de-facto
> standard, because people could keep using their own versions. There would
> be no pressure to resolve these collisions.

So even on boost, such collisions occur - what about libraries that are
developed completely independently?  Which politburo is to decide how each
name is supposed to be used?  How is it to be enforced?  And wern't
namespaces supposed to solve these issues anyway?

> 
>>> But this is not really a problem with ADL customization points,
>>> because in their purest form, there is no primary template. The
>>> primary template is usually a compatibility workaround for types
>>> that do not support the ADL interface yet.
>>
>> I think you're being just a tiny bit too sanguine here.  There are
>> layers of concepts that need to be built upon commonly-used types, and
>> there's a great danger that different libraries will pick the same
>> simple names for different operations in their own domains.  Just
>> consider the widespread use of numeric types in all kinds of
>> domain-specific applications.  Is every library going to pick the same
>> meaning for
>>
>>        zero(x)
>>
>> ??
> 
> Yes, I hope so. I also hope that they would pick the same meaning for x+y.

Ok, quick (but serious) question: What are the semantics of zero(x) ?

Cheers,
Ian