[Issue 6519] Problem with inout and type inference of polysemous types

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=6519


Don <clugdbug at yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[CTFE] Problem with inout   |Problem with inout and type
                   |and enum type inference     |inference of polysemous
                   |                            |types


--- Comment #2 from Don <clugdbug at yahoo.com.au> 2011-08-18 00:54:22 PDT ---
Here's an example which doesn't involve CTFE at all.

inout(int) foo(inout int data) {
    return 7;
}

void main()
{
    pragma(msg, typeof(foo(7)).stringof); // ---> inout(int)
}

The problem may be in expression.c, functionParameters().
If at parameter matches an inout parameter with implicit conversion, the inout
stays unresolved. That's necessary to allow things like:
foo(A, B)(inout(A) a, inout(B) b)

when B is int; it should work when A is immutable, and also when it is mutable.
But...
array literals are a problem. You can write:
int[] a = [1,2,3];
and also
immutable(int)[] b = [1,2,3];
In the first case, a sort of implicit .dup gets added.
Suppose we define 
     inout(int[]) foo(inout(int[]) x) { return x; }

Should the following compile?
   int[] x = foo([1,2,3]);
   immutable(int[]) y = foo([1,2,3]);
   const(int[]) z = foo([1,2,3]);

Currently only z compiles. The others say you cannot convert from inout(int[]) 
to int[].

One solution might be to say that if _all_ inout parameters are polysemous
value types, so that the return constness remains ambiguous, a tie-breaking
rule is applied to all of the parameters.
There are two reasonable options:
(a) always mutable. This would mean that x would compile, but z would stop
working in existing code. y would continue to be rejected.
That is, the type of foo([1,2,3]) would be typeof([1,2,3]).

(b) always const. No change to what compiles. This gives more efficient code,
since array literals don't need to be duped.

A third option would be that the return type propagates to the parameters.
Then, x, y, and z would all work, and we'd have perfect forwarding.
Implicit conversion of the return type of a call to such a function, would mean
implicit conversion of all the ambiguous parameters to such a function. Note
that this is recursive: a parameter of an inout function could itself be the
return value of another inout function.

This would be optimally efficient; there would never be an unnecessary implicit
.dup of array literals. It's a bit scary though -- I worry that that there
might be unintended consequences of such an idea.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------