Re: [boost] [range] How to extend Boost.Range?

From: David Abrahams (dave_at_[hidden])
Date: 2005-09-12 13:08:26

Thomas Witt <witt_at_[hidden]> writes:

> David Abrahams wrote:
>> 
>> Yeah, they sure do, and -- at least from one valid perspective --
>> appropriately so.  The begin semantics you're interested in when you
>> call boost::begin(x) are those that have been defined by Boost.Range,
>> and not some other idea of what "begin" means.
>
> Given this "narrow" (no belittlement intended) view I tend to agree. Is 
> it correct to say that this view does not lead to the idea of "public 
> domain" customization points as expressed below?

Yes.  Whether or not that is the best way to look at things, I am
still undecided.

Interestingly I was just consulting with some people doing
high-performance statistical simulation for a bank, and they were very
concerned about the impact of ADL on the name "swap," since that has a
very specific meaning in the world of finance.

>>>> Not if you buy Peter Dimov's argument that many customization points
>>>> become "public domain" and are no longer the property of any library.
>>>> Read that part of the thread carefully.  Once people start supplying
>>>> begin() hooks, other library authors may start making interfaces that
>>>> work with Boost.Range compatible types.
>>> I've read through his argument at least twice in the past. That being 
>>> said I might still not get the point. I do agree with the names 
>>> becomming public domain. What I disagree with is that names like 
>>> boost_range_begin are suitable for this. 
>> 
>> What should the name be?
>
> A suitable name for a "public domain" customization point as I see it 
> would be begin(). 

If you want that as you've written it, without qualification, the
language puts you in conflict with your own desire to avoid adding
"potentially useless" "warts" into the interface.  Maybe you don't
view that as a wart, but begin(x) is useless to anyone who isn't aware
of the concept it is "hooking."

> That being said it's not necessarily the right solution in this
> case.

Right.

>>> They will likely always be warts in an interface.
>> 
>> Why do you think of them as part of the interface, if, as you say,
>> they're not intended to be used directly by end-users?  The fact that
>> they appear in the header file, or even in the same namespace with
>> public interface elements, doesn't automatically make them interface
>> elements.  To be an interface element, a function must be documented
>> as such.  These hooks have the same role as a class template
>> specialization in the library namespace would.
>
> As much as I sympathize with this view. My experience shows this is not 
> the way it works in practice.

I know that some people just look at the source anyway.  At least
functions found through ADL can be separated from the class
declaration and explicitly marked in comments as "not for user
consumption."

>>>>> Apart from the fact that the hook strategy is unlikely to scale well
>>>>> (how many potentially useless hooks do you want in your library?) 
>>>> In my library?  Useless?  I'm confused.  Am "I" the author of a
>>>> library component who is trying to get it to work with other libraries
>>>> like Boost.Range?
>>>>
>>> Just assume you are.
>> 
>> Well, it's not useless if it makes my component work with
>> BOOST_FOREACH.  So I still don't understand your question.
>
> When I say 'useless' I mean useless in this specific usage scenario. 
> I.e. somebody uses library A but not boost. In this case boost hooks in 
> library A are 'useless'.

So you'd prefer ADL hooks without 'boost' in their names?  How does
one get the default behavior for builtin arrays without including
boost?

>> Clearly.  All I'm hearing from you are complaints, without a proposal
>> for an alternative that works.
> My main concern is that the proposed solution using specific ADL hooks 
> does not scale.

Can you say more about that?  I don't understand what you mean.

> I would prefer an approach where a Range concept is specified that any 
> type can model without ever referring to boost. The role of boost.range 
> would be to provide a range interface for often used types that 
> otherwise won't have one.

Can you suggest such a concept definition?  Certainly, something like

    supports begin(x)

is never going to be valid by itself for builtins.  You need the using
declaration, and then you need to know where to get it.

Hmm, I suppose one possibility is that the requirement is

    supports begin(x)

and then the builtins and the standard containers are in principle not
Ranges.  Of course, the user can make them into ranges by declaring
the appropriate begin(s) in his own namespace, either by writing his
own definitions or by #including the right boost headers and adding
using declarations.

>> The problem of building customization points for generic C++ libraries
>> has no really satisfying solution at the moment.  Any approach we
>> choose will be a compromise.
>
> Agreed.
>
>> It isn't clear to me why this particular
>> compromise should be deemed worse than any of the others.
>
> The reason I think it's worse is that I think it does not scale. 

Worse than what?

> That being said, I'll stop complaining now and we'll see what time
> will tell.  It might well prove me wrong.

I'd rather hear some real suggestions ;-)

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com