Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Andrew Sutton (andrew.n.sutton_at_[hidden])
Date: 2008-11-25 10:19:05

>
> My point was that a default constructed range may be in a perfectly valid
>> state, too, depending on its iterators.
>>
>>
>
> Indeed.  I think that a default constructed iterator_range should be usable
> and empty
> iff default constructed iterators are non-singular and equal.  This
> effectively
> pushes dealing with default construction onto the iterators.  IMO, this is
> more consistent than the old behavior, where a default constructed
> iterator_range was "empty", but r.begin() == r.end() could be undefined
> behavior.
>

I think this is the right answer (and pretty well argued by now). The
behavior of the iterator_range should "inherit" (is there a better word for
this?) its semantics from the underlying iterator. To do otherwise would
impose requirements on iterators that may not (easily) support those
semantics, making the concept less generic (as in represents fewer possible
implementations).

Considering the converse, you'd have to provide some kind of axiomatic
guarantee at the concept level. Ranges that are empty by default might be a
refinement of this (to borrow DA's name) NonSingularRange that does provide
this guarantee.

concept Range<typename X>
{ ... }

concept NonSingularRange<typename X> : Range<X>
{
  axiom EmptyByDefault()
  { X() == X() && empty(X()); }
}

If you publish your interfaces with these constraints (using
Boost.ConceptCheck, for example), then the burden of ensuring proper
initialization lies with your users, not you.

As for fixing the process... we should probably start getting in the habit
of trying to actually write the concept definitions even though we can't
compile them. At least it would seem to provide an unambiguous statement of
semantic behavior. Plus, it's good practice. It also lets us build tests to
a definition rather than the documentation.

Just a thought.

Andrew Sutton
andrew.n.sutton_at_[hidden]