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
