On Mon, 05 Mar 2012 20:34:09 -0500, Stewart Gordon <smjg_1...@yahoo.com>
wrote:
On 05/03/2012 22:31, Steven Schveighoffer wrote:
On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon
<smjg_1...@yahoo.com> wrote:
On 05/03/2012 13:49, Steven Schveighoffer wrote:
<snip>
It's currently transitive, and this would break transitivity. If we
want to look at
fundamentally redefining inout so that it can break transitivity,
then we can look at
that. But I don't think this is a simple "add-on" to the current
functionality.
<snip>
Can you give an example of how it breaks transitivity?
Using the above foo function:
Which has only one level of indirection. So I can't see how
transitivity comes into play.
void main()
{
void bar(int *x) {*x = 5;}
int i = 2;
foo(&i, &bar); // this sets i to 5 via the inout reference we pass into
it.
}
<snip>
The foo function doesn't set i. The bar function does.
The issue is that the bar function modifies i via the inout parameter to
foo. That is, bar does not modify i directly, but modifies foo's
parameter.
The design of inout is that the function with inout parameters doesn't
know or care about the constancy of its arguments, _therefore_ cannot
modify the data. The function that is passed in as a delegate, OTOH,
_does_ know the constancy of its argument, and so _can_ modify it if the
constancy permits. This is necessary to support foreach in the way
we're talking about.
I think maybe transitivity is not the right term. It's just a straight
const violation.
The thing I'm getting at is, there are two pieces to inout -- one is, it
passes the constancy of the parameters back through the return value. The
second is it acts as a surrogate for const in terms of API guarantees.
That means, if I pass in a parameter as an inout parameter, it will not be
modified during the function execution *through that parameter*.
Again, I want to stress that I think the idea is sound and could be
implemented. But I think it fundamentally changes the way inout is
conceptually designed.
-Steve
