http://d.puremagic.com/issues/show_bug.cgi?id=7355
--- Comment #13 from Steven Schveighoffer <schvei...@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: -------