I just wanted to note that this problem is a heck of a lot worse than
it looks now, and IMHO really requires changes to IFTI to deal with at
all reasonably. Also note that it's not even a problem specific to
ranges, as things as simple as pow() were broken and required some ugly
kludges to fix, due to similar issues.
I've discovered that huge amounts of code in Phobos are relying on Bug
3534 (http://d.puremagic.com/issues/show_bug.cgi?id=3534) to work, since
this allows calling popFront()/popBack() on const/immutable arrays. I
tried to change popFront() and popBack() to explicitly prevent them from
being called on const/immutable arrays, thinking/hoping that not too
much code would be relying on this bug and that I could fix whatever
does. It ended up having ripple effects all over Phobos, breaking
modules from std.string to std.algorithm to std.xml, so I gave up for now.
I realize D isn't getting tail const, so a perfect general solution is
out of the question. However, I do think that a lot of important cases
(arrays and stuff without mutable indirection) can be solved by making
IFTI implicitly instantiate with Unqual!T when passed a T, iff T is
implicitly convertible to Unqual!T. For example:
struct S {
int[] arr;
int i;
}
immutable str = "abc";
immutable num = 1;
immutable S s;
void doStuff(T1, T2, T3)(T1 t1, T2 t2, T3 t3) {}
doStuff(str, num, s);
This would call doStuff!(immutable(char)[], int, immutable(S)).
immutable(char[]) can implicitly convert to immutable(char)[], so the
implicit conversion is done. immutable(int) can implicitly convert to
int, so the conversion is done. immutable(S) cannot implicitly convert
to S, so the conversion is not done.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
