On 4/15/16 6:31 PM, Timon Gehr wrote:
On 15.04.2016 23:56, Steven Schveighoffer wrote:
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.
I'm sorry, should have put on my standard disclaimer that I am not a
compiler writer :) I actually have no idea how this is done in the
compiler, just how a compiler should behave as I understand it in my head.
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.
Right, but again: these are named by the writer of the template, not the
language, right? In that case, any identifier becomes a modifier. Or are
you thinking of something different?
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.
Of course, but the transference of mutability from parameter to return
value is the obvious draw of such a wildcard. In most cases, there is
only one return value, and therefore only one pool that needs to be handled.
ref/out parameters can serve as alternate returns as well as composed types.
It's not that functions don't have multiple returns with their own
inout, but I don't think it's very common. As we get more and more
obscure, the cost/benefit ratio for complexity vs. power gets higher.
And already people don't like where we are right now with it.
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.
Especially given the discussion happening here, I agree.
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.
I don't see how the library would do that.
Just throwing a strawman out there:
void foo(bingo = inout, zingo = inout)(bingo(int)* x, zingo(int)* y)
So inside foo, bingo is one flavor of inout, zingo is another. This
could vary library to library, function to function.
It would work, and be sound design. I would just hate it is all :)
Perhaps you have a better system in mind?
-Steve
