On 15.04.2016 23:56, Steven Schveighoffer wrote:
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,
Rather, when the inout data is actually accessed.
then that needs to be
taken into account if the inner function has additional inout parameters.
...
That's sensible, of course. The current implementation is a lot more
conservative though.
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?
...
What I'm saying is that the check that is currently implemented is not
adequate for the new case. This is not terribly important though. The
point was that there needs to be a design effort beyond lifting the
limitation, and you seemed to claim that the current implementation
already takes care of the presented issue, which is not the case.
Your ideas are sound though.
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.
They would just be named parameters to the function on the type system
level, similar to template arguments but not causing repeated instantiation.
The benefit would be quite small, whereas
there are obvious places inout makes sense -- the 'this' parameter and
the return value.
...
The return value might contain more than one pointer, and functions
often have more than one parameter.
Then there is the syntax that would be required, I'm not sure what that
looks like.
...
Anything that is analogous to template parameters, e.g. an additional
set of arguments with a different delimiter. Many workable
possibilities. Anyway, it is unlikely to happen.
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
I don't see how the library would do that.
