On 4/15/16 5:17 PM, Timon Gehr wrote:
On 15.04.2016 22:47, Steven Schveighoffer wrote:
There's no difference between a function that declares its variables
inout within its parameters or one that declares them locally.
...
Yes, there is. Semantic analysis sees the parameter types before it sees
the body.
I don't know what the current implementation sees the function as doing.
The way I look at it, the function context is like an extra parameter to
the inner function. If it contains inout data, then that needs to be
taken into account if the inner function has additional inout parameters.
For example:
inout(int) *x;
inout(int) *foo(inout int) {return x;}
foo is really taking 2 parameters: y and the context pointer that
contains x. It almost looks like this:
inout(int) *foo(inout int, ref inout(int) *x) { return x;}
call this with: foo(1, x)
And it won't compile.
However, call it with: foo(inout(int)(1), x);
and it should be fine, returning an inout(int)*.
They should be treated the same once the function starts compiling.
...
I think I have stated clearly why this is impossible. :P
Impossible or difficult to do with the current implementation?
At the point where we need to tag multiple pools of inout parameters,
the complexity of the language doesn't justify the benefits.
...
I think this is a funny place to draw the line, but I guess this is a
matter of taste.
I may have said this incorrectly. The language itself wouldn't really be
that much more complex. It's the cost of understanding what each of the
different inout pools mean. The benefit would be quite small, whereas
there are obvious places inout makes sense -- the 'this' parameter and
the return value.
Then there is the syntax that would be required, I'm not sure what that
looks like.
We could make it possible, for instance, to templatize the mutability
modifier instead of using a specific keyword. Then you could have
foo(int)[]. Then I think you could do all this (and scrap inout), but I
wouldn't want to work in that language.
Well, that is precisely the way that languages with real type systems
address issues like this one. D has many others like it.
Aye, solutions like Rebindable, which is pretty much a failure IMO, show
how lack of expressiveness in the core language can't be easily substituted.
Note that for type systems, complexity and expressiveness do not
necessarily correlate.
Humans are creatures of habit and familiarity. To allow each library to
define what words mean what for modifiers would be really difficult to
deal with.
-Steve
