Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-11-22 14:39:35

> The library may indeed have been poorly documented, but I don't see how
> what you wrote here addresses Scott's statement in any way.  You simply
> cannot count on undocumented behaviors of a library; they are subject to
> change without notice.

The behaviour WAS documented, as I've stated in a different thread:  It's right
there at the top of the iterator_range class if the pre 1.35 docs.

However, I have to say I don't like what you're doing - I feel like you're
trying to prove that what we're doing is actually wrong in some way.  We're
looking for a solution to real problem.  Forget for a second about whether it 
or it documented.  The question is - what can be done?

> I doubt I'll find quotes from the source very persuasive, since what you
> can count on should be determined by the docs.... of course comments in
> the source are a kind of documentation.

Dave was just demonstrating why the is_singular() function is broken.

> > at the top of iterator_range we see:
> >
> > /*! \file
> >    Defines the \c iterator_class and related functions.
> >    \c iterator_range is a simple wrapper of iterator pair idiom. 
> > It provides
> >    a rich subset of Container interface.
> > */
> >
> > This implies to me that range is trying to look and feel like a container 
> > - 
> > not like an iterator.  
> 
> I understand that you drew that conclusion, but IMO it's a huge stretch
> to claim that a concept that doesn't even exist for containers
> (singularity) should behave in some container-like way for ranges.

Remember that our problem is not with is_singular(), it is with empty(). 
is_singular() is just an implementatin artifact.  The behaviour we care about 
is whether or not a default constructed iterator_range should be empty(), 
in line with standard containers.  The comment from the source was Dave's 
example of why it wasn't unreasonable to assume such behaviour.

> > I agree that singular iterators (as defined in the standard) are
> > undefined when default constructed; 
> 
> To be precise, they're not undefined.  All singular iterators are alike,
> regardless of how they're produced (default-constructed or otherwise).
> They have two defined operations: assignment and destruction.

But not all default constucted iterators are singular.

> Perhaps.  But did the documentation guarantee that it would work?

Yes - please see the old docs or my previous posts.

> You're free to define models of Range that have a default-constructed
> empty state.  Requiring all models of Range to behave that way is
> antithetical to the principles of generic programming.

We certainly agree on this.  We're not proposing that we have a single
iterator_range class that fits all purposes, again as I've stated in several 
posts.

> but AFAICT the only thing that a
> Range has in common with a container is that it supplies a begin() and
> end() that delimit a sequence of elements.

Actually, the similarity is much stronger than that:

        iterator  begin() const;
        iterator  end() const;
        size_type size() const;
        bool      empty() const;

Unfortunately I don't have my standard at hand (it's at work) but IIRC all of
the are part of the "Container requirements".

> I would find that argument more compelling if there was a "singular"
> concept that applied to containers, but there isn't.

We don't care about the singular concept.  We only care about the default
constructed/empty() concept.

Tom