Once again a post DConf topic.
T[] implicitely cast to cont(T)[] . Isn't it nice ? Yes but,
Foo!T do not with Foo!const(T), and for good reasons.
This make it very cumbersome to write collections in D in general
and make them fully usable with the const system.
It has been raised several time by Steven and several others, I'm
hitting the same problem as well.
Many people raised the need for better collection lib and I have
to say I do agree. This and the allocator design are the 2 major
pain point that need to be removed to get a high quality
collection library.

Foo!T and Foo!(const T) are completely different and essentially unrelated
types. They're only connection is that they're instantiated from the same
template. You can't assume that anything about them is the same. It's
perfectly possible to do something like
struct Foo(T)
{
static if(is(const(T) == T))
{
string s;
byte b;
auto bar() { return s ~ b; }
}
else
{
T t;
float baz() { return 2.2; }
string toString() { "hello"; }
}
}
So, the compiler can't assume that Foo!T has any relation to Foo!(const T). In
reality, 99.999999% of the time, the only difference would be constness, but
doing nonsense like what that Foo definition does is perfectly possible. With
const T[] and const(T)[], the compiler knows all about how arrays work, so it
knows that converting const T[] to const(T)[] (i.e. make it tail-const) is
perfectly valid, and it just can't do that with user-defined types.
At one point, I tried to make a range's opSlice return a tail-const version of
the range (and alias that to this for implicit conversions), but I ended up
with a recursive template instantiation in the process, which blew the stack
when compiling or somesuch. I _think_ that it could be done by using static if
to break the recursion (though I didn't try that at the time), but I'm not
entirely sure that that can be done, and even if it can, then it's getting
fairly complicated to define a range which can be sliced as tail-const like
arrays can, which likely means that almost no one will do it.
I don't know what the solution is (Steven has some ideas, but I don't know
what they are), but if const and ranges are ever going to mix, we need to be
able to reasonably get tail-const ranges from const ranges. Otherwise, as soon
as you get a const range, it's pretty much useless.
- Jonathan M Davis

I don't know what the solution is (Steven has some ideas, but I don't
know
what they are), but if const and ranges are ever going to mix, we need
to be
able to reasonably get tail-const ranges from const ranges. Otherwise,
as soon
as you get a const range, it's pretty much useless.

I wrote a proof-of-concept tail-const range framework at some point, and
posted it to BugZilla[1]. It shows that such a thing is possible in the
language as-is, however I don't think it would win a beauty contest.
This is a hard problem to get right, and I'd love to see Steven's ideas.
[1]: http://d.puremagic.com/issues/show_bug.cgi?id=5377
--
Simen

I don't know what the solution is (Steven has some ideas, but I don't
know
what they are), but if const and ranges are ever going to mix, we need
to be
able to reasonably get tail-const ranges from const ranges. Otherwise,
as soon
as you get a const range, it's pretty much useless.

I wrote a proof-of-concept tail-const range framework at some point, and
posted it to BugZilla[1]. It shows that such a thing is possible in the
language as-is, however I don't think it would win a beauty contest.
This is a hard problem to get right, and I'd love to see Steven's ideas.
[1]: http://d.puremagic.com/issues/show_bug.cgi?id=5377

Stay tuned. My ideas are evolving (article in progress). I think it will
not necessarily be an easy pill to swallow.
I want to get all my thoughts ironed out before posting. But the gist of
it is:
1. Yes, it is a big problem, and it's increasingly apparent that it needs
to be solved.
2. It cannot be done via library. We will necessarily need
compiler/language help for this.
3. It will not be that disruptive, simply because nothing can do it
properly now. So I think the change will give a large ROI (that was for
Don).
-Steve