Steven Schveighoffer Wrote: > "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 > >
Checking if a range is empty() prior to accessing its head is useful. If empty() is const, you can't do that.
