range and algorithm-related stuff

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> I'm working on the new range stuff and the range-based algorithm. In all 
> likelihood, you all might be pleased with the results.
>
> I wanted to gauge opinions on a couple of issues. One is, should the 
> empty() member function for ranges be const? On the face of it it should, 
> but I don't want that to be a hindrance. I presume non-const empty might 
> be necessary sometimes, e.g. figuring out if a stream is empty effectively 
> means fetching an element off it.
>

Ranges are structs.  It should not matter if you want to make some const and 
some non-const.  Basically, it depends on the range implementation.  If you 
can make it const, make it const, if not, don't make it const.  It shouldn't 
break any APIs.

For example, an array range might have empty be const, but a stream range 
might not.  What matters is what functions you can use those ranges in, but 
those are generally templated functions, so the compiler will tell you 
whether it can be used or not when it tries to compile it.

Personally, I see no benefit to having empty() be const.  What benefits do 
you gain by specifically making empty const and the other functions not 
const?  Presumably, the underlying container must be not const in order for 
head, next, etc. to work properly, so there is no requirement there.

-Steve