Re: [boost] Is Boost.Range broken?

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

> Sure there are, but that's irrelevant. The standard doesn't require 
> iterators that have been constructed to be in a valid state, and that's 
> all there is to it.

By the same logic, we should never be able to build any compound types which
have any members which could potentially be in some invalid state.  
When I default construct a string class, it has some internal representation
with a char pointer, which doesn't necessarily point to any valid memory. Does
that mean that the observable behaviour of that class should be undefined?  Or
that asking the string if it's empty should abort my application?
Maybe you want your string class to do that but I can't have mine work like
that.  Hence we need two different implementations.  That is exactly what I
proposed.

> It's not a matter of choice of design. It's a matter of following the 
> standard.

I really have not idea what you're referring to.  There is nothing about
iterator_range in the C++ standard.  We can choose to define the semantics any
way we choose.  

> In your specific case it's not a problem, but iterator_range aims at 
> being generic.

Generic means that it's applicable to a wide variety of types.  Cutting out
support for a subset of valid types for no good reason = less generic.

> As I said, if it was just me, I would have designed the iterator 
> concepts differently so as *not* to require default construction, which 
> standard iterator concepts do, and that is bringing the singular states in.

Then perhaps you should try to come up with a design we could discuss here
rather than just criticizing without actually proposing something.  Then we
could get somewhere.  

This, what is happening now on this mail topic is very typical of this mailing
list and this is what makes it so hard to try be involved.  By now, I could have
written ten range implementations and fixed all of my code.  Instead, I'm
spending time trying to get this (IMHO important) component somehow integrated
back into boost. 

If instead of arguing about minutia we could actually talk about a real design,
we could make progress.  At the moment all of the useful brain power is spent on
trying to prove that what we're doing is wrong.  Your problem domain is
different from mine.  Physicists call the imaginary number 'j'.  In mathematics,
we refer to it as 'i'.  Does it make one or the other wrong?  

I gave a demonstrable use case, which, IMHO, is actually very powerful thanks to
the generality of iterator_range.  Not one of the opponents of what we're saying
has come up with a single suggestion of how the current iterator_range can meet
my needs or justify why it should be acceptable for boost to change documented
behaviour without any notice.  Whether or not the original semantics were "pure"
in some way is irrelevant.  Boost is a published library and it broke people's
code.  Now you are arguing in favour of alienating a collection of current users
of boost because it seems, you don't deem their use case important enough.  

Boost needs to be nimble and glaring problems should, of course, be fixed.  At
the same time, the developers should recognise how widely used boost is and at
least have enough of a feeling of responsibility towards the users not to just
break things willy-nilly.  I asked Thorsten if there were any actual use cases
in which the overhead of the additional boolean check was causing problem.  He
never replied.  And when such breakage happens, my hope would be that the
developers would try to work with the affected people instead of calling their
use cases irrelevant.

Tom