[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 #13 from Steven Schveighoffer <schveiguy at yahoo.com> 2012-02-03 15:46:53 PST ---
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.

I see now that inout(const) must be a consideration for substituting inout.

Now, regarding overload resolution as it pertains to resolving what inout
means, I still think a simple algorithm as I previously stated should work.  We
just need to add inout(const) as a possible substitute.  I think the ordering
should be something like:

mutable, immutable, inout, inout(const), const

Note that inout and inout(const) are the local version (not the wildcard
version).  Also note that mutable, immutable, and inout could be in any order.

The algorithm I stated earlier needs to be modified.  The easiest way to state
it is, try each of the above substitutes for inout in order, and the first one
that type-checks, wins.  I think it works because there are no cycles in the
implicit conversion graph:

mutable ----+------------------+
            |                  |
immutable --+--> inout(const) -+-> const 
            |                  |
inout ------+------------------+

But I don't see why we need complex overload rules as you stated.  Can you show
a counter-example to my simple design?  I'd like to keep things simple, because
inout is already difficult to understand and making it simple to explain is a
huge benefit.

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