--- 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:
immutable --+--> inout(const) -+-> const
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
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------