const-correctness in std.range

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, 1 September 2014 at 03:45:25 UTC, Vlad Levenfeld wrote:
> I notice that some of the range adapters in std.range (iota, 
> takeExactly) have a const empty property, while others (take, 
> retro) don't. This makes maintaining const-correctness 
> downstream (with my own range adapters atop phobos') more 
> difficult. I'm wondering if there is a rationale for this, if 
> there is some use for a non-const empty?

  If a range is wrapping another range, you generally can't mark 
anything const without using static ifs to check whether those 
functions are const for the range being wrapped, otherwise the 
wrapper will fail to compile if the functions aren't const, and 
they often aren't - either because the person who wrote the code 
didn't bother or because an implementation detail makes it 
problematic or impossible. It would be really nice if we had some 
kind of const or inout inferrence, but unfortunately, we don't.

It's quite possible that some of the ranges in Phobos have const 
functions where they shouldn't be const and that some of them 
should have const functions but don't. empty can frequently be 
const, but there's no guarantee that it can be (e.g. some ranges 
might actually do work in their empty, even though that's usually 
not the best place to do it; however, there are cases wher it may 
be forced). In general though, at this point, to get it right, 
you need to use static if to switch between const and non-const 
implementation depending on the range being wrapped.

- Jonathan M Davis