[Issue 7355] inout incorrectly resolved if the same type has both mutable and immutable parts

[d-bugmail at puremagic.com]

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



--- Comment #10 from timon.gehr at gmx.ch 2012-02-02 13:05:31 PST ---
(In reply to comment #9)
> (In reply to comment #8)
> > This rule should work satisfactory:
> > 
> > - The compiler is required to resolve inout such that the behavior is as if
> > there were four (five, with inout(const(T)) enhancement in place) separate
> > overloads. This could be implemented similar to how you propose it, by adding
> > all of the versions to the overload set, or by using some insights to speed up
> > the process (not very hard)
> 
> This sounds fine.  However, inout(const(T)) is not a substitute for inout(T),
> so it should be four.
> 

inout(const(T)) should be its own type. And as soon as that is the case, inout
const will have to be a valid substitute for inout.

For example, this should type check:

immutable(int)[] arr = [2,3,4];
inout(const(int))[] foo(inout(int)[] x){
    return uniform(0,2) ? arr : x;
}
inout(int)[] id(inout(int)[] x){
    return x;
}
inout(int)[] bar(inout(int)[] x){
    inout(int)[] y = [1,2,3];
    inout(const(int))[] z = id(foo(y)); // inout const substitute for inout
    return z~x;
}


> inout(const(T)) is special in what can implicitly convert to it.  But the inout
> is the only wildcard there.

True, but that does not mean it should not be a valid substitute for inout. 

> 
> The rest is not necessary.  The normal overload rules already should handle
> which one is chosen.  Since inout, mutable, and immutable do not implicitly
> convert to each other, it's not possible for there to be an ambiguity, is
> there?  immutable and mutable (and by extension inout) should be preferred over
> const.

There are indeed corner cases, for example:

void foo(immutable(int) x, float y){}
void foo(const(int) x, float y){}
void foo(int x, float y){}

void main(){foo(1,1);} // error, matches all three

A different solution would be to refine the overload rules.


> 
> It's important to note that the inout overload we are talking about is not the
> wildcard inout, but the local const-like inout.

Exactly. The same holds for inout(const(T)).

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