On 9/17/10 8:24 AM, David Simcha wrote:
> On 9/17/2010 3:08 AM, Andrei Alexandrescu wrote:
>> So the crux of the matter is not operating on constant ranges (which I believe we can safely drop), but obtaining non-constant ranges from constant containers.
>
> I agree we need to drop operating on constant ranges for the general case, but I think it's trivial to fix for a lot of common cases by just adding Unqual. This would fix arrays, iota and everything else that has a "natural" tail const.

Walter and I also discussed the idea that the compiler could automatically transform const(T[]) -> const(T)[] when passing built-in arrays into functions. Of course that only works for arrays...


Andrei

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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos