www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - inout and function/delegate parameters

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
At the moment, if a function has an inout parameter, it must have an inout
return type.

But this prevents doing stuff like

     void test(ref inout(int)[] x, inout(int)[] y) {
         x = y;
     }

or passing the constancy through to a delegate instead of a return value.

A typical use case of the latter is to define an opApply that works regardless
of the 
constancy of this and allows the delegate to modify the iterated-through
objects _if_ this 
is mutable.

     int opApply(int delegate(ref inout(T)) dg) inout;

But then I realised a potential ambiguity:
(a) the constancy is passed through to the delegate
(b) the delegate has an inout parameter in its own right

If we go by interpretation (b), then each signature contains only one inout, so
even if we 
relaxed the rules to allow this it would just be equivalent to

     int opApply(int delegate(ref const(T)) dg) const;

however, this won't always be true in the general case.

The essence of functions with inout parameters is that they have a hidden
constancy 
parameter.  This is essentially a template parameter, except that only one
instance of the 
function is generated, rather like Java generics.  If we made this parameter
explicit in 
the code, we could distinguish the two meanings:

(a) int opApply(constancy K)(int delegate(ref K(T)) dg) K;
(b) int opApply(constancy K)(int delegate(constancy L)(ref L(T)) dg) K;

Moreover, in case (a), opApply would accept for dg:
- an int delegate(ref T) only if this is mutable
- an int delegate(ref immutable(T)) only if this is immutable
- an int delegate(ref const(T)), or a delegate that is itself
constancy-templated, 
regardless of the constancy of this

Perhaps the simplest example where meaning (b) is actually useful is

     inout(char)[] process(inout(char)[] delegate(inout(char)[]) dg,
inout(char[]) text) {
         return text;
     }

but still, somebody might want meaning (a).  Anyway, under DMD 2.058 (Win32)
this gives

inout_delegate.d(1): Error: inout must be all or none on top level for 
inout(char)[](inout(char)[] function(inout(char)[]) fn, inout(char[]) text)

but why?  At least it seems that DMD acknowledges the ambiguity, even if the
error message 
doesn't make sense.


The question really is: When inout is applied both to a parameter in a
function's 
signature and to something in the signature of a function/delegate parameter
therewithin, 
how should it be interpreted?  The spec doesn't seem to address the issue at
all.  Indeed, 
we can ask two things:
- what actually does the compiler make of it at the moment?
- what would be the ideal way for it to work?

Possibilities I can see:

- always (a)
- always (b)
- (a) if at either level inout only occurs once, otherwise (b) (probably
undesirable 
because of fragility)
- just reject such signatures as ambiguous

And moreover, should we support some syntax (similar to what I've used here or
otherwise) 
to state explicitly whether we want to pass the constancy through to the
delegate 
signature or not?

Stewart.
Feb 19 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/19/2012 03:27 PM, Stewart Gordon wrote:
 At the moment, if a function has an inout parameter, it must have an
 inout return type.

 But this prevents doing stuff like

 void test(ref inout(int)[] x, inout(int)[] y) {
 x = y;
 }

 or passing the constancy through to a delegate instead of a return value.

 A typical use case of the latter is to define an opApply that works
 regardless of the constancy of this and allows the delegate to modify
 the iterated-through objects _if_ this is mutable.

 int opApply(int delegate(ref inout(T)) dg) inout;

 But then I realised a potential ambiguity:
 (a) the constancy is passed through to the delegate
 (b) the delegate has an inout parameter in its own right

 If we go by interpretation (b), then each signature contains only one
 inout, so even if we relaxed the rules to allow this it would just be
 equivalent to

 int opApply(int delegate(ref const(T)) dg) const;

 however, this won't always be true in the general case.

 The essence of functions with inout parameters is that they have a
 hidden constancy parameter. This is essentially a template parameter,
 except that only one instance of the function is generated, rather like
 Java generics. If we made this parameter explicit in the code, we could
 distinguish the two meanings:

 (a) int opApply(constancy K)(int delegate(ref K(T)) dg) K;
 (b) int opApply(constancy K)(int delegate(constancy L)(ref L(T)) dg) K;

 Moreover, in case (a), opApply would accept for dg:
 - an int delegate(ref T) only if this is mutable
 - an int delegate(ref immutable(T)) only if this is immutable
 - an int delegate(ref const(T)), or a delegate that is itself
 constancy-templated, regardless of the constancy of this

 Perhaps the simplest example where meaning (b) is actually useful is

 inout(char)[] process(inout(char)[] delegate(inout(char)[]) dg,
 inout(char[]) text) {
 return text;
 }

 but still, somebody might want meaning (a). Anyway, under DMD 2.058
 (Win32) this gives

 inout_delegate.d(1): Error: inout must be all or none on top level for
 inout(char)[](inout(char)[] function(inout(char)[]) fn, inout(char[]) text)

 but why? At least it seems that DMD acknowledges the ambiguity, even if
 the error message doesn't make sense.


 The question really is: When inout is applied both to a parameter in a
 function's signature and to something in the signature of a
 function/delegate parameter therewithin, how should it be interpreted?
 The spec doesn't seem to address the issue at all. Indeed, we can ask
 two things:
 - what actually does the compiler make of it at the moment?
 - what would be the ideal way for it to work?

 Possibilities I can see:

 - always (a)
 - always (b)
 - (a) if at either level inout only occurs once, otherwise (b) (probably
 undesirable because of fragility)
 - just reject such signatures as ambiguous

 And moreover, should we support some syntax (similar to what I've used
 here or otherwise) to state explicitly whether we want to pass the
 constancy through to the delegate signature or not?

 Stewart.
I think some kind of disambiguation is essential. I see multiple solutions: 1. (b) would be the default. We could use the some parameter storage class to opt-in a): (a) int opApply( somequalifier int delegate(ref inout(T)) dg) inout; (b) int opApply(int delegate(ref inout(T)) dg) inout; This would work well. Maybe this is a little bit hackish, but I propose to use somequalifier:=inout a) int opApply(inout int delegate(ref inout(T)) dg) inout; b) int opApply(constancy K)(int delegate(constancy L)(ref L(T)) dg) K; Actually affecting the constancy of the delegate itself is not an useful operation anyway, but it could still be achieved: a) int opApply(inout inout(int delegate(ref inout(T)))) dg) inout; // every inout means the same thing b) int opApply(inout(int delegate(ref inout(T)))) dg) inout; // the inout on the delegate parameter is distinct from the other two 2. We introduce an infinite number of wildcard storage classes: inout, inout', inout'', inout''', inout'''', ... a) int opApply(int delegate(ref inout(T)) dg) inout; b) int opApply(int delegate(ref inout'(T)) dg) inout; This would have the additional boon that it would allow to type check a larger set of const-correct functions [1], like the following: void swapPairs(ref inout(int)[] x1, ref inout'(int)[] y1, ref inout(int)[] x2, ref inout'(int)[] y2){ swap(x1,x2); swap(y1,y2); } [1] furthermore, we'd finally get identifier' identifiers ;)
Feb 19 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 19/02/2012 15:31, Timon Gehr wrote:
<snip excessive quote>
<snip>
 a) int opApply(inout int delegate(ref inout(T)) dg) inout;
 b) int opApply(constancy K)(int delegate(constancy L)(ref L(T)) dg) K;
???
 Actually affecting the constancy of the delegate itself is not an useful
operation anyway,
 but it could still be achieved:

 a) int opApply(inout inout(int delegate(ref inout(T)))) dg) inout; // every
inout means
 the same thing
So "inout inout" would be a special token sequence to link the outer and inner inouts together.
 b) int opApply(inout(int delegate(ref inout(T)))) dg) inout; // the inout on
the delegate
 parameter is distinct from the other two
I don't see what the inout applied to the type of dg is actually doing here....
 2.

 We introduce an infinite number of wildcard storage classes:
 inout, inout', inout'', inout''', inout'''', ...
<snip>
 [1] furthermore, we'd finally get identifier' identifiers ;)
The lexer would need to be tweaked to support these. And it might get confusing to overload ' like this, given that some other keywords can be immediately followed by a character literal. Maybe inout$ with some kind of identifying token.... (a) int opApply(int delegate(ref inout$0(T)) dg) inout$0; (b) int opApply(int delegate(ref inout$1(T)) dg) inout$0; Hmm.... Stewart.
Feb 19 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/19/2012 06:09 PM, Stewart Gordon wrote:
 On 19/02/2012 15:31, Timon Gehr wrote:
 <snip excessive quote>
 <snip>
 a) int opApply(inout int delegate(ref inout(T)) dg) inout;
 b) int opApply(constancy K)(int delegate(constancy L)(ref L(T)) dg) K;
???
oops... a) int opApply(inout int delegate(ref inout(T)) dg) inout; b) int opApply(int delegate(ref inout(T)) dg) inout;
 Actually affecting the constancy of the delegate itself is not an
 useful operation anyway,
 but it could still be achieved:

 a) int opApply(inout inout(int delegate(ref inout(T)))) dg) inout; //
 every inout means
 the same thing
So "inout inout" would be a special token sequence to link the outer and inner inouts together.
No, but probably it is more clear with the fixed b) case above. The inout parameter storage class would be used for linking.
 b) int opApply(inout(int delegate(ref inout(T)))) dg) inout; // the
 inout on the delegate
 parameter is distinct from the other two
I don't see what the inout applied to the type of dg is actually doing here....
 2.

 We introduce an infinite number of wildcard storage classes:
 inout, inout', inout'', inout''', inout'''', ...
<snip>
 [1] furthermore, we'd finally get identifier' identifiers ;)
The lexer would need to be tweaked to support these. And it might get confusing to overload ' like this, given that some other keywords can be immediately followed by a character literal.
I am not aware of any except 'case'. But you are right. It would certainly confuse most existing D editors.
 Maybe inout$ with some kind of identifying token....

 (a) int opApply(int delegate(ref inout$0(T)) dg) inout$0;
 (b) int opApply(int delegate(ref inout$1(T)) dg) inout$0;

 Hmm....

 Stewart.
That would be a possibility.
Feb 19 2012
prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
I think the 'scope' keyword may resolve issue.

Attributes of lazy parameter in template function belong to caller side.

int foo()(lazy int value)  safe pure /*nothrow*/ { return value(); }
void main() {
    int n =3D foo(10);
    // evaluating lazy parameter never break safety and purity of foo.
    // (violating nowthrow-ness might be a bug.)
    // because the violation belongs to caller side - it is main function.
}

Similarly, scope delegate body always in caller side, so calling it
means temporary exiting to caller side.

void foo(ref inout int x, scope void delegate(ref inout(int)) dg) {
    dg(x);
}
void main() {
    int a;
    foo(a, (ref int x){ x =3D 10; });  // don't break foo's inout-ness,
so should be allowed
    assert(a =3D=3D 10);
}

How about?

Kenji Hara

2012/2/19 Stewart Gordon <smjg_1998 yahoo.com>:
 At the moment, if a function has an inout parameter, it must have an inou=
t
 return type.

 But this prevents doing stuff like

 =A0 =A0void test(ref inout(int)[] x, inout(int)[] y) {
 =A0 =A0 =A0 =A0x =3D y;
 =A0 =A0}

 or passing the constancy through to a delegate instead of a return value.

 A typical use case of the latter is to define an opApply that works
 regardless of the constancy of this and allows the delegate to modify the
 iterated-through objects _if_ this is mutable.

 =A0 =A0int opApply(int delegate(ref inout(T)) dg) inout;

 But then I realised a potential ambiguity:
 (a) the constancy is passed through to the delegate
 (b) the delegate has an inout parameter in its own right

 If we go by interpretation (b), then each signature contains only one ino=
ut,
 so even if we relaxed the rules to allow this it would just be equivalent=
to
 =A0 =A0int opApply(int delegate(ref const(T)) dg) const;

 however, this won't always be true in the general case.

 The essence of functions with inout parameters is that they have a hidden
 constancy parameter. =A0This is essentially a template parameter, except =
that
 only one instance of the function is generated, rather like Java generics=
.
 =A0If we made this parameter explicit in the code, we could distinguish t=
he
 two meanings:

 (a) int opApply(constancy K)(int delegate(ref K(T)) dg) K;
 (b) int opApply(constancy K)(int delegate(constancy L)(ref L(T)) dg) K;

 Moreover, in case (a), opApply would accept for dg:
 - an int delegate(ref T) only if this is mutable
 - an int delegate(ref immutable(T)) only if this is immutable
 - an int delegate(ref const(T)), or a delegate that is itself
 constancy-templated, regardless of the constancy of this

 Perhaps the simplest example where meaning (b) is actually useful is

 =A0 =A0inout(char)[] process(inout(char)[] delegate(inout(char)[]) dg,
 inout(char[]) text) {
 =A0 =A0 =A0 =A0return text;
 =A0 =A0}

 but still, somebody might want meaning (a). =A0Anyway, under DMD 2.058 (W=
in32)
 this gives

 inout_delegate.d(1): Error: inout must be all or none on top level for
 inout(char)[](inout(char)[] function(inout(char)[]) fn, inout(char[]) tex=
t)
 but why? =A0At least it seems that DMD acknowledges the ambiguity, even i=
f the
 error message doesn't make sense.


 The question really is: When inout is applied both to a parameter in a
 function's signature and to something in the signature of a
 function/delegate parameter therewithin, how should it be interpreted? =
=A0The
 spec doesn't seem to address the issue at all. =A0Indeed, we can ask two
 things:
 - what actually does the compiler make of it at the moment?
 - what would be the ideal way for it to work?

 Possibilities I can see:

 - always (a)
 - always (b)
 - (a) if at either level inout only occurs once, otherwise (b) (probably
 undesirable because of fragility)
 - just reject such signatures as ambiguous

 And moreover, should we support some syntax (similar to what I've used he=
re
 or otherwise) to state explicitly whether we want to pass the constancy
 through to the delegate signature or not?

 Stewart.
Feb 19 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/19/2012 11:27 PM, kenji hara wrote:
 I think the 'scope' keyword may resolve issue.

 Attributes of lazy parameter in template function belong to caller side.

 int foo()(lazy int value)  safe pure /*nothrow*/ { return value(); }
 void main() {
      int n = foo(10);
      // evaluating lazy parameter never break safety and purity of foo.
      // (violating nowthrow-ness might be a bug.)
      // because the violation belongs to caller side - it is main function.
 }

 Similarly, scope delegate body always in caller side, so calling it
 means temporary exiting to caller side.

 void foo(ref inout int x, scope void delegate(ref inout(int)) dg) {
      dg(x);
 }
 void main() {
      int a;
      foo(a, (ref int x){ x = 10; });  // don't break foo's inout-ness,
 so should be allowed
      assert(a == 10);
 }

 How about?

 Kenji Hara
If I get you right, then this cannot work in general. immutable int y=0; void foo(ref inout int x, scope void delegate(ref inout(int)) dg) { dg(y); // boom }
Feb 19 2012
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 19 Feb 2012 09:27:42 -0500, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 At the moment, if a function has an inout parameter, it must have an  
 inout return type.

 But this prevents doing stuff like

      void test(ref inout(int)[] x, inout(int)[] y) {
          x = y;
      }
This is a legitimate request, I think there is an effort underway by myself Timon and Kenji to make this work. (well mostly Kenji and Timon)
 or passing the constancy through to a delegate instead of a return value.

 A typical use case of the latter is to define an opApply that works  
 regardless of the constancy of this and allows the delegate to modify  
 the iterated-through objects _if_ this is mutable.

      int opApply(int delegate(ref inout(T)) dg) inout;
What you ask isn't possible given the current design of inout. During inout function execution, inout is a special form of const, even if the object on which opApply is being called is mutable.
 But then I realised a potential ambiguity:
 (a) the constancy is passed through to the delegate
 (b) the delegate has an inout parameter in its own right

 If we go by interpretation (b), then each signature contains only one  
 inout, so even if we relaxed the rules to allow this it would just be  
 equivalent to

      int opApply(int delegate(ref const(T)) dg) const;
Yes, this is what I think it should be equivalent to. As I said, inside opApply, inout is like const, and is transitive. So you cannot "temporarily" make it mutable.
 however, this won't always be true in the general case.

 The essence of functions with inout parameters is that they have a  
 hidden constancy parameter.  This is essentially a template parameter,  
 except that only one instance of the function is generated, rather like  
 Java generics.  If we made this parameter explicit in the code, we could  
 distinguish the two meanings:
No the constancy is not a parameter (not even a hidden one). The magic of inout happens at the call, not inside the function. Inside, it's just another type of const. However, there is an entire part of delegates that is yet untapped -- implicit conversion of delegates. For example, int delegate(ref const int x) could be implicitly converted to int delegate(ref int x). Maybe there is something there that can be used to solve this problem. Maybe there is a rule we could apply when calling an inout-enabled function that allows implicit conversion of a delegate to an inout -flavored version of the delegate (as long as the normal delegate matches the decided inout constancy factor). But that violates transitivity. I'm not sure Walter would go for this. -Steve
Feb 24 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/24/2012 05:26 PM, Steven Schveighoffer wrote:
 On Sun, 19 Feb 2012 09:27:42 -0500, Stewart Gordon <smjg_1998 yahoo.com>
 wrote:

 At the moment, if a function has an inout parameter, it must have an
 inout return type.

 But this prevents doing stuff like

 void test(ref inout(int)[] x, inout(int)[] y) {
 x = y;
 }
This is a legitimate request, I think there is an effort underway by myself Timon and Kenji to make this work. (well mostly Kenji and Timon)
 or passing the constancy through to a delegate instead of a return value.

 A typical use case of the latter is to define an opApply that works
 regardless of the constancy of this and allows the delegate to modify
 the iterated-through objects _if_ this is mutable.

 int opApply(int delegate(ref inout(T)) dg) inout;
What you ask isn't possible given the current design of inout. During inout function execution, inout is a special form of const, even if the object on which opApply is being called is mutable.
The call site has enough information to type check the call given that there is some syntax to tie the two inout qualifiers together. inout shouldn't imply const, we already have const for that.
 But then I realised a potential ambiguity:
 (a) the constancy is passed through to the delegate
 (b) the delegate has an inout parameter in its own right

 If we go by interpretation (b), then each signature contains only one
 inout, so even if we relaxed the rules to allow this it would just be
 equivalent to

 int opApply(int delegate(ref const(T)) dg) const;
Yes, this is what I think it should be equivalent to. As I said, inside opApply, inout is like const, and is transitive. So you cannot "temporarily" make it mutable.
inout means 'some qualifier but we don't know which one'. The call site on the other hand knows which qualifier it is. If the call is made to work there is no 'making it mutable', because it is mutable all the time. The inout function cannot change the data because it cannot know what the constancy is.
 however, this won't always be true in the general case.

 The essence of functions with inout parameters is that they have a
 hidden constancy parameter. This is essentially a template parameter,
 except that only one instance of the function is generated, rather
 like Java generics. If we made this parameter explicit in the code, we
 could distinguish the two meanings:
No the constancy is not a parameter (not even a hidden one). The magic of inout happens at the call, not inside the function.
The same is (mostly) true for Java generics.
 Inside, it's just another type of const.

 However, there is an entire part of delegates that is yet untapped --
 implicit conversion of delegates. For example, int delegate(ref const
 int x) could be implicitly converted to int delegate(ref int x). Maybe
 there is something there that can be used to solve this problem. Maybe
 there is a rule we could apply when calling an inout-enabled function
 that allows implicit conversion of a delegate to an inout -flavored
 version of the delegate (as long as the normal delegate matches the
 decided inout constancy factor). But that violates transitivity. I'm not
 sure Walter would go for this.
Unfortunately this violates type safety. Also see: http://d.puremagic.com/issues/show_bug.cgi?id=7542
Feb 25 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 02/24/2012 05:26 PM, Steven Schveighoffer wrote:
 On Sun, 19 Feb 2012 09:27:42 -0500, Stewart Gordon <smjg_1998 yahoo.com>
 wrote:

 At the moment, if a function has an inout parameter, it must have an
 inout return type.

 But this prevents doing stuff like

 void test(ref inout(int)[] x, inout(int)[] y) {
 x = y;
 }
This is a legitimate request, I think there is an effort underway by myself Timon and Kenji to make this work. (well mostly Kenji and Timon)
 or passing the constancy through to a delegate instead of a return  
 value.

 A typical use case of the latter is to define an opApply that works
 regardless of the constancy of this and allows the delegate to modify
 the iterated-through objects _if_ this is mutable.

 int opApply(int delegate(ref inout(T)) dg) inout;
What you ask isn't possible given the current design of inout. During inout function execution, inout is a special form of const, even if the object on which opApply is being called is mutable.
The call site has enough information to type check the call given that there is some syntax to tie the two inout qualifiers together. inout shouldn't imply const, we already have const for that.
inout is defined as "during this function execution the given parameter will be treated as const". This is necessary to have a single implementation for all flavors of const. Remember, inside the function the compiler has no idea that the actual data is mutable, const or immutable. One of the cornerstones of inout is that it must generate one function.
 But then I realised a potential ambiguity:
 (a) the constancy is passed through to the delegate
 (b) the delegate has an inout parameter in its own right

 If we go by interpretation (b), then each signature contains only one
 inout, so even if we relaxed the rules to allow this it would just be
 equivalent to

 int opApply(int delegate(ref const(T)) dg) const;
Yes, this is what I think it should be equivalent to. As I said, inside opApply, inout is like const, and is transitive. So you cannot "temporarily" make it mutable.
inout means 'some qualifier but we don't know which one'. The call site on the other hand knows which qualifier it is. If the call is made to work there is no 'making it mutable', because it is mutable all the time. The inout function cannot change the data because it cannot know what the constancy is.
What you would propose is that a delegate which takes a const/mutable/immutable implicitly translates to one which takes an inout. I agree it can be made to work, but it does not fit into the current definition of inout. It would be ideal for inout to solve this, but it's not chartered in such a way to do so. 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.
 however, this won't always be true in the general case.

 The essence of functions with inout parameters is that they have a
 hidden constancy parameter. This is essentially a template parameter,
 except that only one instance of the function is generated, rather
 like Java generics. If we made this parameter explicit in the code, we
 could distinguish the two meanings:
No the constancy is not a parameter (not even a hidden one). The magic of inout happens at the call, not inside the function.
The same is (mostly) true for Java generics.
 Inside, it's just another type of const.

 However, there is an entire part of delegates that is yet untapped --
 implicit conversion of delegates. For example, int delegate(ref const
 int x) could be implicitly converted to int delegate(ref int x). Maybe
 there is something there that can be used to solve this problem. Maybe
 there is a rule we could apply when calling an inout-enabled function
 that allows implicit conversion of a delegate to an inout -flavored
 version of the delegate (as long as the normal delegate matches the
 decided inout constancy factor). But that violates transitivity. I'm not
 sure Walter would go for this.
Unfortunately this violates type safety. Also see: http://d.puremagic.com/issues/show_bug.cgi?id=7542
That bug does not exactly capture what I said. The inout translation *must* happen at the same point where inout is resolved at the call site. For example, you can't do this: int delegate(inout(int)*) iod; int delegate(int *) md; iod = md; // error, we don't know what inout will resolve to. But this could be made to work: void foo(inout(int)* x, int delegate(inout(int)*) d) { d(x);} int x; foo(&x, md); // translation is valid, because we know what inout resolves to. foo(&x, iod); // also valid, because iod must have been defined to actually take an inout parameter. Again, if you look at inout as a form of const, this breaks transitivity, it's kind of a cousin of logical const. Walter needs to be involved to have his say. I think it could be made to work. The more I think about it, the more I think this is worth changing. inout provides a unique way to make something that is normally a template that generates multiple copies of the same code into one that generates one copy. The large benefit of it is you can write one function instead of 3, and still have it not be a template. -Steve
Mar 05 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 05/03/2012 13:49, Steven Schveighoffer wrote:
 On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:
<snip>
 inout means 'some qualifier but we don't know which one'. The call site on the
other
 hand knows which qualifier it is. If the call is made to work there is no
'making it
 mutable', because it is mutable all the time. The inout function cannot change
the data
 because it cannot know what the constancy is.
What you would propose is that a delegate which takes a const/mutable/immutable implicitly translates to one which takes an inout. I agree it can be made to work, but it does not fit into the current definition of inout.
I'm not sure if you understand correctly. Is isn't a matter of implicit conversion of delegates from one type to another, but a matter of (in this case) opApply accepting a delegate with a parameter whose constancy matches that of this. You can think of a function signature with an inout parameter as being really a union of three function signatures. inout(T)[] func(inout(T)[] param) is a union of T[] func(T[] param) immutable(T)[] func(immutable(T)[] param) const(T)[] func(const(T)[] param) In the same way, the essence of what Timon and I are proposing is that we'd be able to make opApply's signature a union of void opApply(int delegate(ref T) dg) void opApply(int delegate(ref immutable(T)) dg) immutable void opApply(int delegate(ref const(T)) dg) const or, to generalise a bit, declare a function whose signature is a union of void func(ref T param, int delegate(ref T) dg) void func(ref immutable(T) param, int delegate(ref immutable(T)) dg) void func(ref const(T) param, int delegate(ref const(T)) dg) or similarly with pointer or array parameters.
 It would be ideal for inout to solve this, but it's not chartered in such a
way to do so.
If I'm not mistaken, inout isn't chartered to do anything particular when it occurs in a function signature nested within another. The spec just leaves it ambiguous.
 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? Stewart.
Mar 05 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 On 05/03/2012 13:49, Steven Schveighoffer wrote:
 On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr <timon.gehr gmx.ch>  
 wrote:
<snip>
 inout means 'some qualifier but we don't know which one'. The call  
 site on the other
 hand knows which qualifier it is. If the call is made to work there is  
 no 'making it
 mutable', because it is mutable all the time. The inout function  
 cannot change the data
 because it cannot know what the constancy is.
What you would propose is that a delegate which takes a const/mutable/immutable implicitly translates to one which takes an inout. I agree it can be made to work, but it does not fit into the current definition of inout.
I'm not sure if you understand correctly. Is isn't a matter of implicit conversion of delegates from one type to another, but a matter of (in this case) opApply accepting a delegate with a parameter whose constancy matches that of this.
I understand the problem and the proposed solution quite well.
 It would be ideal for inout to solve this, but it's not chartered in  
 such a way to do so.
If I'm not mistaken, inout isn't chartered to do anything particular when it occurs in a function signature nested within another. The spec just leaves it ambiguous.
No, inout is not modifiable during the function execution. Given the transitivity of const and immutable, inout itself must also be transitive. Think about it this way: inout(int)* foo(inout(int)* x) { // begin here, at this point x is not modifiable // *x = 5; // not allowed! return x; // end here, at this point inout reverts back to it's original constancy (including return value). } The original definition I used for inout was "scoped const", meaning it's const within the scope and reverts back after the scope. I did not plan for having the constancy "temporarily" revert back to the original constancy. What you wish for is this to take a delegate which matches the constancy of the x parameter: inout(int)* foo(inout(int) *x, void delegate(inout(int)* p) dg) { dg(x); // valid, since the type matches return x; // oops, now x could have changed! Even through it's an inout reference! }
 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: 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. } In other words, inout is transitively not constant during the function call. I'm not saying we cannot bend the rules to allow for this, because clearly it doesn't violate the "true" constancy type of the data passed in, but I don't think it's a straightforward change conceptually. I'm not a compiler writer, so I don't know how this works in their minds, I'd like to have their input. -Steve
Mar 05 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/05/2012 11:31 PM, Steven Schveighoffer wrote:
 On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon <smjg_1998 yahoo.com>
 wrote:

 On 05/03/2012 13:49, Steven Schveighoffer wrote:
 On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr <timon.gehr gmx.ch>
 wrote:
<snip>
 inout means 'some qualifier but we don't know which one'. The call
 site on the other
 hand knows which qualifier it is. If the call is made to work there
 is no 'making it
 mutable', because it is mutable all the time. The inout function
 cannot change the data
 because it cannot know what the constancy is.
What you would propose is that a delegate which takes a const/mutable/immutable implicitly translates to one which takes an inout. I agree it can be made to work, but it does not fit into the current definition of inout.
I'm not sure if you understand correctly. Is isn't a matter of implicit conversion of delegates from one type to another, but a matter of (in this case) opApply accepting a delegate with a parameter whose constancy matches that of this.
I understand the problem and the proposed solution quite well.
 It would be ideal for inout to solve this, but it's not chartered in
 such a way to do so.
If I'm not mistaken, inout isn't chartered to do anything particular when it occurs in a function signature nested within another. The spec just leaves it ambiguous.
No, inout is not modifiable during the function execution. Given the transitivity of const and immutable, inout itself must also be transitive. Think about it this way: inout(int)* foo(inout(int)* x) { // begin here, at this point x is not modifiable // *x = 5; // not allowed! return x; // end here, at this point inout reverts back to it's original constancy (including return value). }
I don't think this is the best way to think about inout. Try to think about it as if the constancy was determined, but unknown. It does not actually change, the function just does not know what it is because it has to work in a polymorphic way.
 The original definition I used for inout was "scoped const", meaning
 it's const within the scope and reverts back after the scope. I did not
 plan for having the constancy "temporarily" revert back to the original
 constancy. What you wish for is this to take a delegate which matches
 the constancy of the x parameter:

 inout(int)* foo(inout(int) *x, void delegate(inout(int)* p) dg)
 {
 dg(x); // valid, since the type matches
 return x; // oops, now x could have changed! Even through it's an inout
 reference!
 }
Well, that can happen even for const references. What is your point?
 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: 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. } In other words, inout is transitively not constant during the function call.
Because it has been matched as *mutable*. There is no issue.
 I'm not saying we cannot bend the rules to allow for this, because
 clearly it doesn't violate the "true" constancy type of the data passed
 in, but I don't think it's a straightforward change conceptually. I'm
 not a compiler writer, so I don't know how this works in their minds,
 I'd like to have their input.
Implementation of what you propose should be quite simple. The issue is with the design, i.e. allowing both tying the inout in the delegate parameter signature to the inout in the enclosing signature and having an independent inout delegate parameter needs workable syntax.
Mar 05 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 05 Mar 2012 18:01:34 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 03/05/2012 11:31 PM, Steven Schveighoffer wrote:
 On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon <smjg_1998 yahoo.com>
 wrote:

 On 05/03/2012 13:49, Steven Schveighoffer wrote:
 On Sat, 25 Feb 2012 09:02:47 -0500, Timon Gehr <timon.gehr gmx.ch>
 wrote:
<snip>
 inout means 'some qualifier but we don't know which one'. The call
 site on the other
 hand knows which qualifier it is. If the call is made to work there
 is no 'making it
 mutable', because it is mutable all the time. The inout function
 cannot change the data
 because it cannot know what the constancy is.
What you would propose is that a delegate which takes a const/mutable/immutable implicitly translates to one which takes an inout. I agree it can be made to work, but it does not fit into the current definition of inout.
I'm not sure if you understand correctly. Is isn't a matter of implicit conversion of delegates from one type to another, but a matter of (in this case) opApply accepting a delegate with a parameter whose constancy matches that of this.
I understand the problem and the proposed solution quite well.
 It would be ideal for inout to solve this, but it's not chartered in
 such a way to do so.
If I'm not mistaken, inout isn't chartered to do anything particular when it occurs in a function signature nested within another. The spec just leaves it ambiguous.
No, inout is not modifiable during the function execution. Given the transitivity of const and immutable, inout itself must also be transitive. Think about it this way: inout(int)* foo(inout(int)* x) { // begin here, at this point x is not modifiable // *x = 5; // not allowed! return x; // end here, at this point inout reverts back to it's original constancy (including return value). }
I don't think this is the best way to think about inout. Try to think about it as if the constancy was determined, but unknown. It does not actually change, the function just does not know what it is because it has to work in a polymorphic way.
Best way or not, it was designed and accepted using these assumptions. Again, I am not against the idea, I just want to hear what Walter and company think about it.
 The original definition I used for inout was "scoped const", meaning
 it's const within the scope and reverts back after the scope. I did not
 plan for having the constancy "temporarily" revert back to the original
 constancy. What you wish for is this to take a delegate which matches
 the constancy of the x parameter:

 inout(int)* foo(inout(int) *x, void delegate(inout(int)* p) dg)
 {
 dg(x); // valid, since the type matches
 return x; // oops, now x could have changed! Even through it's an inout
 reference!
 }
Well, that can happen even for const references. What is your point?
Not via the const parameter. For example, mark the delegate and the function as pure, it cannot happen with const.
 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: 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. } In other words, inout is transitively not constant during the function call.
Because it has been matched as *mutable*. There is no issue.
There are two parts to inout, one is that it can be one function called 3 different ways, the other is that you know it's constant during function execution. Some people like that second part, even if it doesn't fully guarantee everything. I.e. there's a reason people use const in C++ besides it being trendy.
 I'm not saying we cannot bend the rules to allow for this, because
 clearly it doesn't violate the "true" constancy type of the data passed
 in, but I don't think it's a straightforward change conceptually. I'm
 not a compiler writer, so I don't know how this works in their minds,
 I'd like to have their input.
Implementation of what you propose should be quite simple. The issue is with the design, i.e. allowing both tying the inout in the delegate parameter signature to the inout in the enclosing signature and having an independent inout delegate parameter needs workable syntax.
I think it can be done: 1. determine inout match based on existing rules, excluding delegate parameters. 2. change delegate parameter inouts to matched value. 3. Use implicit delegate conversion (using contravariance) to allow passing delegates of proper type. For example: void foo(inout(int)* x, void delegate(inout(int)* y) dg); void main() { int mx; immutable int ix; const int cx; void bar1(int *mp) {} void bar2(immutable(int) *ip) {} void bar3(const(int) *cp) {} void bar4(inout(int) *iop) {} // inout matched as mutable due to mx, signature becomes void foo(int *x, void delegate(int *y) dg); foo(&mx, &bar1); // fine, direct match of both parameters foo(&mx, &bar2); // not fine, immutable delegate does not implicitly convert to mutable foo(&mx, &bar3); // fine, const delegate can implicitly convert to mutable foo(&mx, &bar4); // fine, inout delegate can implicitly convert to mutable // signature becomes void foo(immutable(int) *x, void delegate(immutable(int) *y) dg); foo(&ix, &bar1); // error foo(&ix, &bar2); // ok foo(&ix, &bar3); // fine, const delegate can implicitly convert to immutable foo(&ix, &bar4); // fine, inout delegate can implicitly convert to immutable // signature becomes void foo(const(int) *x, void delegate(const(int) *y) dg); foo(&cx, &bar1); // error foo(&cx, &bar2); // error foo(&cx, &bar3); // ok foo(&cx, &bar4); // ok // etc... } Note that Walter has explicitly rejected contravariance conversion for delegates. You have good persuasive skills, maybe you can help :) See bug http://d.puremagic.com/issues/show_bug.cgi?id=3180 and http://d.puremagic.com/issues/show_bug.cgi?id=3075 -Steve
Mar 05 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/06/2012 12:27 AM, Steven Schveighoffer wrote:
...
 There are two parts to inout, one is that it can be one function called
 3 different ways, the other is that you know it's constant during
 function execution. Some people like that second part, even if it
 doesn't fully guarantee everything. I.e. there's a reason people use
 const in C++ besides it being trendy.
By passing a delegate that changes an inout-matched argument it is made explicit that inout data may change. Technically, none of the existing guarantees are lost, we just add some expressiveness to the type system.
 I'm not saying we cannot bend the rules to allow for this, because
 clearly it doesn't violate the "true" constancy type of the data passed
 in, but I don't think it's a straightforward change conceptually. I'm
 not a compiler writer, so I don't know how this works in their minds,
 I'd like to have their input.
Implementation of what you propose should be quite simple. The issue is with the design, i.e. allowing both tying the inout in the delegate parameter signature to the inout in the enclosing signature and having an independent inout delegate parameter needs workable syntax.
I think it can be done: 1. determine inout match based on existing rules, excluding delegate parameters. 2. change delegate parameter inouts to matched value. 3. Use implicit delegate conversion (using contravariance) to allow passing delegates of proper type. For example: void foo(inout(int)* x, void delegate(inout(int)* y) dg); void main() { int mx; immutable int ix; const int cx; void bar1(int *mp) {} void bar2(immutable(int) *ip) {} void bar3(const(int) *cp) {} void bar4(inout(int) *iop) {} // inout matched as mutable due to mx, signature becomes void foo(int *x, void delegate(int *y) dg); foo(&mx, &bar1); // fine, direct match of both parameters foo(&mx, &bar2); // not fine, immutable delegate does not implicitly convert to mutable foo(&mx, &bar3); // fine, const delegate can implicitly convert to mutable foo(&mx, &bar4); // fine, inout delegate can implicitly convert to mutable // signature becomes void foo(immutable(int) *x, void delegate(immutable(int) *y) dg); foo(&ix, &bar1); // error foo(&ix, &bar2); // ok foo(&ix, &bar3); // fine, const delegate can implicitly convert to immutable foo(&ix, &bar4); // fine, inout delegate can implicitly convert to immutable // signature becomes void foo(const(int) *x, void delegate(const(int) *y) dg); foo(&cx, &bar1); // error foo(&cx, &bar2); // error foo(&cx, &bar3); // ok foo(&cx, &bar4); // ok // etc... }
I understand, but how would you support this use case?: inout(int)[] foo(inout(int)[] delegate(inout(int)[] dg), inout(int)[] arr){ int[] x = dg(new int[16]); immutable(int)[] y = dg(new immutable(int)[16]); // ... inout(int)[] z = dg(arr); return foo(z,y,z); } In essence, it should be possible to pass an inout delegate to an inout function, such that the function can use the delegate as an inout delegate.
 Note that Walter has explicitly rejected contravariance conversion for
 delegates.
That is unfortunate.
 You have good persuasive skills, maybe you can help :) See
 bug http://d.puremagic.com/issues/show_bug.cgi?id=3180 and
 http://d.puremagic.com/issues/show_bug.cgi?id=3075
IIRC Kenji Hara has already started attempts to loosen the restrictions regarding delegate implicit conversions. Hopefully Walter will reconsider.
Mar 06 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 06 Mar 2012 05:11:34 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 03/06/2012 12:27 AM, Steven Schveighoffer wrote:
 ...
 There are two parts to inout, one is that it can be one function called
 3 different ways, the other is that you know it's constant during
 function execution. Some people like that second part, even if it
 doesn't fully guarantee everything. I.e. there's a reason people use
 const in C++ besides it being trendy.
By passing a delegate that changes an inout-matched argument it is made explicit that inout data may change. Technically, none of the existing guarantees are lost, we just add some expressiveness to the type system.
Yes, I understand that it works. I know that it doesn't violate technically any const guarantees. In fact, I think this is valid D code: int i; const int *pi = &i; int *p = cast()pi; *p = 5; // legal because I know this points at i, and i is really mutable But from an API point of view, I look at at inout as guaranteeing anything the parameter points at won't change while inside the function *using that parameter*. Even though it's legal, it's disingenuous (at least as long as we define inout that way). An interesting side note is that inout (if designed in this way) can allow the above code snippit to be modularized.
 I'm not saying we cannot bend the rules to allow for this, because
 clearly it doesn't violate the "true" constancy type of the data  
 passed
 in, but I don't think it's a straightforward change conceptually. I'm
 not a compiler writer, so I don't know how this works in their minds,
 I'd like to have their input.
Implementation of what you propose should be quite simple. The issue is with the design, i.e. allowing both tying the inout in the delegate parameter signature to the inout in the enclosing signature and having an independent inout delegate parameter needs workable syntax.
I think it can be done: 1. determine inout match based on existing rules, excluding delegate parameters. 2. change delegate parameter inouts to matched value. 3. Use implicit delegate conversion (using contravariance) to allow passing delegates of proper type. For example: void foo(inout(int)* x, void delegate(inout(int)* y) dg); void main() { int mx; immutable int ix; const int cx; void bar1(int *mp) {} void bar2(immutable(int) *ip) {} void bar3(const(int) *cp) {} void bar4(inout(int) *iop) {} // inout matched as mutable due to mx, signature becomes void foo(int *x, void delegate(int *y) dg); foo(&mx, &bar1); // fine, direct match of both parameters foo(&mx, &bar2); // not fine, immutable delegate does not implicitly convert to mutable foo(&mx, &bar3); // fine, const delegate can implicitly convert to mutable foo(&mx, &bar4); // fine, inout delegate can implicitly convert to mutable // signature becomes void foo(immutable(int) *x, void delegate(immutable(int) *y) dg); foo(&ix, &bar1); // error foo(&ix, &bar2); // ok foo(&ix, &bar3); // fine, const delegate can implicitly convert to immutable foo(&ix, &bar4); // fine, inout delegate can implicitly convert to immutable // signature becomes void foo(const(int) *x, void delegate(const(int) *y) dg); foo(&cx, &bar1); // error foo(&cx, &bar2); // error foo(&cx, &bar3); // ok foo(&cx, &bar4); // ok // etc... }
I understand, but how would you support this use case?: inout(int)[] foo(inout(int)[] delegate(inout(int)[] dg), inout(int)[] arr){ int[] x = dg(new int[16]); immutable(int)[] y = dg(new immutable(int)[16]); // ... inout(int)[] z = dg(arr); return foo(z,y,z); }
As usual, you find and poke holes in all my arguments :) I'm thinking that in order to make this work we need a way to specify an inout modifier really represents the matched type rather than a full-fledged inout parameter. This is not a good thing -- inout is already pretty weird and hard to understand. Need to do some more thinking, maybe there's an easy way.
 Note that Walter has explicitly rejected contravariance conversion for
 delegates.
That is unfortunate.
 You have good persuasive skills, maybe you can help :) See
 bug http://d.puremagic.com/issues/show_bug.cgi?id=3180 and
 http://d.puremagic.com/issues/show_bug.cgi?id=3075
IIRC Kenji Hara has already started attempts to loosen the restrictions regarding delegate implicit conversions. Hopefully Walter will reconsider.
I hope so. This is a vastly awesome untapped low-hanging fruit. -Steve
Mar 07 2012
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 07/03/2012 15:41, Steven Schveighoffer wrote:
<snip>
 In fact, I think this is valid D code:

 int i;
 const int *pi = &i;
 int *p = cast()pi;
 *p = 5; // legal because I know this points at i, and i is really mutable
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.
 But from an API point of view, I look at at inout as guaranteeing anything the
parameter
 points at won't change while inside the function *using that parameter*. Even
though it's
 legal, it's disingenuous (at least as long as we define inout that way).
That's what const is for. The whole point of inout is that the caller has the choice of whether to pass in and get out again mutable, const or immutable data. Allowing the caller to pass in a delegate with a mutable, const or immutable parameter would fit right in with this. <snip>
 As usual, you find and poke holes in all my arguments :) I'm thinking that in
order to
 make this work we need a way to specify an inout modifier really represents
the matched
 type rather than a full-fledged inout parameter.
<snip> Yes, and ways of specifying this have been suggested early in this thread. Stewart.
Mar 07 2012
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 07 Mar 2012 17:37:53 -0500, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 On 07/03/2012 15:41, Steven Schveighoffer wrote:
 <snip>
 In fact, I think this is valid D code:

 int i;
 const int *pi = &i;
 int *p = cast()pi;
 *p = 5; // legal because I know this points at i, and i is really  
 mutable
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.
Sorry, it's just easier than typing cast(int*). And I believe it's legal, as long as you *know* that the underlying data is mutable. The above code snippit is legal, because it is shown as long as the first two lines are included that the actual data is mutable.
 But from an API point of view, I look at at inout as guaranteeing  
 anything the parameter
 points at won't change while inside the function *using that  
 parameter*. Even though it's
 legal, it's disingenuous (at least as long as we define inout that way).
That's what const is for.
And inout. Sorry, it was meant that way, even if you don't agree. -Steve
Mar 07 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 07/03/2012 22:48, Steven Schveighoffer wrote:
 On Wed, 07 Mar 2012 17:37:53 -0500, Stewart Gordon <smjg_1998 yahoo.com> wrote:
<snip>
 cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.
Sorry, it's just easier than typing cast(int*).
Which is another abomination. The means of casting away constancy should be explicit. <snip>
 But from an API point of view, I look at at inout as guaranteeing anything the
parameter
 points at won't change while inside the function *using that parameter*. Even
though it's
 legal, it's disingenuous (at least as long as we define inout that way).
That's what const is for.
And inout. Sorry, it was meant that way, even if you don't agree.
Maybe _you_ meant it that way, but did anyone else? Stewart.
Mar 07 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 07 Mar 2012 18:01:10 -0500, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 On 07/03/2012 22:48, Steven Schveighoffer wrote:
 On Wed, 07 Mar 2012 17:37:53 -0500, Stewart Gordon  
 <smjg_1998 yahoo.com> wrote:
<snip>
 cast() is an abomination. I'm not sure OTTOMH whether it's a bug that  
 it works.
Sorry, it's just easier than typing cast(int*).
Which is another abomination. The means of casting away constancy should be explicit.
I agree, but it doesn't make it illegal. It was just a means to show what I meant.
 <snip>
 But from an API point of view, I look at at inout as guaranteeing  
 anything the parameter
 points at won't change while inside the function *using that  
 parameter*. Even though it's
 legal, it's disingenuous (at least as long as we define inout that  
 way).
That's what const is for.
And inout. Sorry, it was meant that way, even if you don't agree.
Maybe _you_ meant it that way, but did anyone else?
I actually designed it... http://d.puremagic.com/issues/show_bug.cgi?id=1961 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2 -Steve
Mar 07 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/07/2012 11:37 PM, Stewart Gordon wrote:
 On 07/03/2012 15:41, Steven Schveighoffer wrote:
 <snip>
 In fact, I think this is valid D code:

 int i;
 const int *pi = &i;
 int *p = cast()pi;
 *p = 5; // legal because I know this points at i, and i is really mutable
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.
It is not legal code. I did not point it out because it was clear what was meant. cast() only casts away the top level of modifiers. It is perfectly safe except for class objects.
Mar 07 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 03/07/2012 11:37 PM, Stewart Gordon wrote:
 On 07/03/2012 15:41, Steven Schveighoffer wrote:
 <snip>
 In fact, I think this is valid D code:

 int i;
 const int *pi = &i;
 int *p = cast()pi;
 *p = 5; // legal because I know this points at i, and i is really  
 mutable
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.
It is not legal code. I did not point it out because it was clear what was meant. cast() only casts away the top level of modifiers. It is perfectly safe except for class objects.
If it's not legal code, then how is implicitly casting away inout during function execution legal code? Isn't this the same thing? -Steve
Mar 08 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/08/2012 12:37 PM, Steven Schveighoffer wrote:
 On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 03/07/2012 11:37 PM, Stewart Gordon wrote:
 On 07/03/2012 15:41, Steven Schveighoffer wrote:
 <snip>
 In fact, I think this is valid D code:

 int i;
 const int *pi = &i;
 int *p = cast()pi;
 *p = 5; // legal because I know this points at i, and i is really
 mutable
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.
It is not legal code. I did not point it out because it was clear what was meant. cast() only casts away the top level of modifiers. It is perfectly safe except for class objects.
If it's not legal code, then how is implicitly casting away inout during function execution legal code? Isn't this the same thing? -Steve
It is not legal code because the assignment const(int)* to int* does not succeed. The other part is up to debate. The specification does not define the semantics of casting away const and changing the data. It is also not the same as with the proposed change to inout. inout would not be 'removed' in the function body, it would be 'removed' upon inout-matching the parameters. Inout should be able to replace overloads on const, therefore I think that is the way it should work on the conceptual level.
Mar 08 2012
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 08 Mar 2012 13:17:15 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 03/08/2012 12:37 PM, Steven Schveighoffer wrote:
 On Wed, 07 Mar 2012 19:06:14 -0500, Timon Gehr <timon.gehr gmx.ch>  
 wrote:

 On 03/07/2012 11:37 PM, Stewart Gordon wrote:
 On 07/03/2012 15:41, Steven Schveighoffer wrote:
 <snip>
 In fact, I think this is valid D code:

 int i;
 const int *pi = &i;
 int *p = cast()pi;
 *p = 5; // legal because I know this points at i, and i is really
 mutable
cast() is an abomination. I'm not sure OTTOMH whether it's a bug that it works.
It is not legal code. I did not point it out because it was clear what was meant. cast() only casts away the top level of modifiers. It is perfectly safe except for class objects.
If it's not legal code, then how is implicitly casting away inout during function execution legal code? Isn't this the same thing? -Steve
It is not legal code because the assignment const(int)* to int* does not succeed.
Oh right, I forgot that casting using cast() just goes to the tail-const version. grr... We really need const_cast...
 The other part is up to debate. The specification does not define the  
 semantics of casting away const and changing the data.
Yes, I couldn't really find that. It does specifically say casting away const and then modifying is invalid, but it does not say anything about "if you know the underlying data is mutable". But again, this is the point I was trying to make, we are casting away a const-like attribute and modifying the data.
 It is also not the same as with the proposed change to inout. inout  
 would not be 'removed' in the function body, it would be 'removed' upon  
 inout-matching the parameters. Inout should be able to replace overloads  
 on const, therefore I think that is the way it should work on the  
 conceptual level.
It is essentially the same as this: void bar(const(int) * i, void delegate(const(int)* i) dg) {dg(i);} void main() { void foo(int *i) {*i = 5;} bar(&i, cast(delegate(const(int)*)) &foo); } Which I don't know if it's valid. Given that compiler enforcement of inout being *sure* that the data is actually mutable, it's much safer than what I wrote above, but it's certainly no different. It's just compiler-checked vs. manually checked. -Steve
Mar 08 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 08/03/2012 19:38, Steven Schveighoffer wrote:
<snip>
 Yes, I couldn't really find that. It does specifically say casting away const
and then
 modifying is invalid, but it does not say anything about "if you know the
underlying data
 is mutable". But again, this is the point I was trying to make, we are casting
away a
 const-like attribute and modifying the data.
<snip> No more than we are already doing with the inout return. Stewart.
Mar 08 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 08 Mar 2012 17:43:34 -0500, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 On 08/03/2012 19:38, Steven Schveighoffer wrote:
 <snip>
 Yes, I couldn't really find that. It does specifically say casting away  
 const and then
 modifying is invalid, but it does not say anything about "if you know  
 the underlying data
 is mutable". But again, this is the point I was trying to make, we are  
 casting away a
 const-like attribute and modifying the data.
<snip> No more than we are already doing with the inout return.
Except that technique has been approved by Walter and included in the language. -Steve
Mar 09 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 03/07/2012 04:41 PM, Steven Schveighoffer wrote:
 On Tue, 06 Mar 2012 05:11:34 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 03/06/2012 12:27 AM, Steven Schveighoffer wrote:
 ...
 There are two parts to inout, one is that it can be one function called
 3 different ways, the other is that you know it's constant during
 function execution. Some people like that second part, even if it
 doesn't fully guarantee everything. I.e. there's a reason people use
 const in C++ besides it being trendy.
By passing a delegate that changes an inout-matched argument it is made explicit that inout data may change. Technically, none of the existing guarantees are lost, we just add some expressiveness to the type system.
Yes, I understand that it works. I know that it doesn't violate technically any const guarantees.
Yes, that is not what I was after: void foo(inout(int)*x, void delegate(inout(int)*) dg) // both inout's denote the same wildcard { dg(x); } void main(){ int x; foo(&x, (p){*p=2;}); // this currently cannot be valid code } The function call is explicit about that may change the inout parameter. There are no guarantees lost. It is the call site who changes the parameter. Code that currently has the guarantee that the parameter won't change will keep it, because there is no valid code that could silently change semantics under the change and does not use some fancy introspection.
Mar 07 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 05/03/2012 22:31, Steven Schveighoffer wrote:
 On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon <smjg_1998 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 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. Stewart.
Mar 05 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 05 Mar 2012 20:34:09 -0500, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 On 05/03/2012 22:31, Steven Schveighoffer wrote:
 On Mon, 05 Mar 2012 11:17:41 -0500, Stewart Gordon  
 <smjg_1998 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
Mar 05 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 19/02/2012 14:27, Stewart Gordon wrote:
<snip>
 int opApply(int delegate(ref inout(T)) dg) inout;

 But then I realised a potential ambiguity:
 (a) the constancy is passed through to the delegate
 (b) the delegate has an inout parameter in its own right
<snip> Thinking about it, if we go with (a), then (b) can be achieved by defining an alias of the delegate type. Just one problem I can see: since a signature that uses (b) can't be represented in code without an alias, how would compiler messages, .stringof and TypeInfo notate the type? But if we go with (b), then there doesn't seem to be a way to achieve (a) without inventing new syntax. Stewart.
Mar 09 2012
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 09 Mar 2012 19:44:20 -0500, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 On 19/02/2012 14:27, Stewart Gordon wrote:
 <snip>
 int opApply(int delegate(ref inout(T)) dg) inout;

 But then I realised a potential ambiguity:
 (a) the constancy is passed through to the delegate
 (b) the delegate has an inout parameter in its own right
<snip> Thinking about it, if we go with (a), then (b) can be achieved by defining an alias of the delegate type. Just one problem I can see: since a signature that uses (b) can't be represented in code without an alias, how would compiler messages, .stringof and TypeInfo notate the type? But if we go with (b), then there doesn't seem to be a way to achieve (a) without inventing new syntax.
As I recently mentioned in the bug report, (b) must be the case without any additional syntax, because otherwise you have two types with identical syntax, but different underlying types. In order to do (a), we need new syntax. That's not a good thing, but not the end of the world. -Steve
Mar 09 2012