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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-04 18:56:33

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.

>> 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.

>> 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.