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

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

David Abrahams wrote:
> "Peter Dimov" <pdimov_at_[hidden]> writes:
>
>> Ian McCulloch wrote:
>>> Peter Dimov wrote:
>>>
>>>> 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?
>>
>> It is unenforceable, of course. But this doesn't mean that it can't
>> happen.  Library authors are, in general, reasonable people; they do
>> cooperate and do respond to issues.
>
> I don't know about that.  The various placeholders in Boost still have
> usability problems when #included together.  And the bind placeholders
> are still causing ODR violations.

The placeholders do have the same meaning; they are an example of a de-facto 
standard. The conflicts that exist are (a) resolvable, (b) caused by factors 
that do not apply to our discussion.

And for the record, Lambda's placeholders cause exactly the same ODR 
violations, although I'm not sure whether "cause" is the proper term.

> It's all very well that library
> writers may adjust eventually, but users can't always upgrade, or they
> can't always upgrade quickly.  There ought to be a mechanism for
> staying out of one another's way.

Such a mechanism does exist. I maintain that not using this mechanism is 
better in the long term.

>> This isn't really specific to ADL customization points. Consider, for
>> example, container requirements, where a.begin() must return
>> A::iterator or A::const_iterator. What happens if another library
>> has its own requirements table that specifies different semantics
>> for a.begin()? Can I make my container conform to these requirements
>> as well? Of course not.
>
> That's why generic library writers have developed a guideline to write
> concept requirements that don't depend on member functions.

Maybe they did. My point is that I never see anti-v.begin() campaigns; it's 
ADL that gets all the flack.

>>> And wern't namespaces supposed to solve these issues anyway?
>>
>> The central question is: can we, the C++ community, decide on a
>> common vocabulary for the primitive operations a type supports? If
>> we can, there is no problem.
>
> I disagree most strongly.
>
> One problem is that not all operations are going to be considered
> "primitive."  More importantly, there should be a way to develop
> software with confidence that it has a future and scales well, without
> having to worry that all customizable names are "pending the
> community's verdict on common meaning."

See above; there is such a way, and the debate is whether not having to 
worry is a good thing. Customization points are very important and need to 
be treated with caution. Once they become de-facto standards, the library no 
longer owns them, even if they are in the library's own namespace.

>>>>> 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)
>>> ?
>>
>> I don't know; this is Dave's example. Whatever the community
>> decides, as long as it's consistent. The user should learn what it
>> means _once_.
>
> It could take many years for a name like that to settle down,
> especially if two major libraries with strong user base and
> backward-compatibility considerations pick competing definitions.

OK; so what alternatives do we have?

1. lib1::numeric_traits<X>::zero( x ); // somewhat unwieldy
2. lib1::zero( x ); // syntactic sugar for the above
3. lib1_zero( x );

What, exactly, are the advantages of #2 over #3? That you can bring 
lib1::zero into scope with a using declaration and call it unqualified? But 
that invites ADL and in the context of our example collides with the other 
'zero'.

Current language assumed. In this discussion I do not consider your 
extension proposal; it will take even more years to settle down.