[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 #18 from timon.gehr at gmx.ch 2012-02-03 17:14:50 PST ---
(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #13)
> > > Once again you are right Timon!
> > > 
> > > I was neglecting to see in the original example that the call was id(foo(y))
> > > instead of just id(y)!  I sometimes cannot penetrate your inadvertent
> > > obfuscation :)  Your original example was (should have been) sufficient.
> > > 
> > 
> > OK. What measures can I take to less obfuscate my code? =)
> 
> hehe, use temporaries to demonstrate what types should be.  Or more inline
> comments maybe.  I just missed seeing the double call in one expression.
> 
> For example, this could have been more effective:
> 
> // your definition for foo
> 
> inout(int)[] id(inout(int)[] x) { return x;}
> 
> inout(const(int))[] bar(inout(int)[] x)
> {
>    inout(const(int))[] tmp = foo(x);
>    return id(tmp); // need to be able to call
> }
> 
> > I think what you propose would work.
> > 
> > But the overload rule I want to add (see issue 7431) is actually quite
> > intuitive and I think it is a good move to make the overload rules consistent
> > enough so that we could re-use them for inout matching. It benefits code that
> > does not use inout too.
> > 
> > Not fixing the overload rules would result in inout being _more_ powerful than
> > three overloads => inout could not be replaced by three overloads
> > transparently, if it was later determined that the different const versions
> > need different function bodies.
> 
> inout is *already* more powerful.  It guarantees no molestation, even for
> mutable args.
> 

Indeed, it gives the same guarantees as const.

> But I see your point.  I'm not opposed to fixing both, but this way of
> explaining inout is simple to me, and to someone who doesn't want to get into
> the complexities of understanding overload resolution.  In other words, one
> doesn't have to be able to understand overload resolution to understand inout.
> 

One goal of overload resolution is to be as intuitive as possible. Few
programmers who use overloading are actually intimately familiar with the rules
that govern the resolution process.

> Consequently, if the way it gets implemented is that overload resolution is
> fixed, and then inout uses that, it's not any different, but it's easier to
> explain this way (IMO).
> 

That is probably true.

> > The only difference between using the repaired overload
> > resolution and your proposal I can see is that yours introduces possible
> > disambiguation in the case of multiple alias this. I don't know if this is good
> > or bad (my initial proposal had the same characteristic).
> > 
> > inout(int)[] foo(inout(int)[] x){return x;}
> > 
> > class C{
> >     int[] x(){writeln("x!");return new int[10];}
> >     immutable int[] y(){writeln("y!");return new immutable(int)[10];}
> >     alias x this;
> >     alias y this;
> > }
> > 
> > void main(){
> >     C c = new C;
> >     foo(c); // should this work or fail?
> > }
> 
> I think you give me too many headaches :)  My gut says this should fail,
> because the call is not just ambiguously typed, but what you *pass* to the call
> is ambiguous.  Consider this less benign example:
> 
> struct S
> {
>    int[] x;
>    immutable(int)[] y;
>    alias x this;
>    alias y this;
> }
> 
> x and y are not just generated temporaries, so the data you pass could be
> different depending on the compiler choice of what order to try the first three
> type constructors.
> 
> My rules depend on the assumption that the argument type is already decided. 
> In the case of literals, that's ok, because an arbitrary choice doesn't change
> code paths, just the type of the expression.
> 
> In this case, we have to cry ambiguity, and fail to compile, in the name of
> consistency.  So how to amend my algorithm?  I suppose something like:
> 
> try at a minimum immutable, mutable, and inout.  If more than one of these
> typechecks, the call is ambiguous.

What if one is a better match than the other? If it should fail I think we
should use the repaired overload resolution. It has exactly the required
semantics.

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