That's sensible. I can't imagine this going much beyond pointers,
arrays, and built-in types, but as you say it does simplify a lot of the
common cases.
So, the idea is whenever doing IFTI the following should apply (where
qual is const or immutable):
qual(int) -> int (same for all other numerics)
qual(T*) -> qual(T)*
qual(T[]) -> qual(T)[]
We might be able to extend this to:
qual(S) -> S
for all structs S that have no mutable indirections and no this(this).
Andrei
On 9/18/10 10:01 AM, David Simcha wrote:
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
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
