On 12.12.2011 19:56, Steven Schveighoffer wrote:
Currently, the rules of inout say you cannot put inout on a parameter
without putting it on the return type as well. This makes sense, it
gives the compiler one place to worry about whether implicit casting
rules will properly work.
But Timon Gehr brought up in another thread (started by Merdhad) that we
can separate the resolution of inout from the applicability of the
parameters. Essentially, calling an inout function goes through two phases:
1. determine what inout resolves to
2. try and call the function.
inout rules don't have to change regarding resolving inout's actual
value. In other words, if all inout places are matched as int,
immutable, or inout, then inout resolves to that value. Otherwise inout
resolves to const.
If this ends up being viable, this is actually easier to explain than
the current rules for inout. We just have to make sure the rules are
sound before doing something like this.
Looks as though 'inout' is about to become a misnomer...
