www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Using inout in delegates

reply Jacob Carlborg <doob me.com> writes:
void foo (inout int[] arr)
{
     auto a = { auto b = arr[0]; };
}

void main ()
{
     auto a = [3, 4, 5];
     foo(a);
}

Compiling the above code with DMD 2.060 results in the following error 
message:

Error: variable main.foo.__lambda1.b inout variables can only be 
declared inside inout functions
Failed: /Users/jacob/.dvm/bin/dvm-current-dc  -v -o- 
'/Users/jacob/development/d/main.d' -I'/Users/jacob/development/d' 
/Users/jacob/development/d/main.d.deps

Is this a bug, a limitation of inout/delegate or am I doing something else wrong? -- /Jacob Carlborg
Oct 04 2012
next sibling parent reply "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Thursday, 4 October 2012 at 13:55:39 UTC, Jacob Carlborg wrote:
 void foo (inout int[] arr)
 {
     auto a = { auto b = arr[0]; };
 }

 void main ()
 {
     auto a = [3, 4, 5];
     foo(a);
 }

 Compiling the above code with DMD 2.060 results in the 
 following error message:

 Error: variable main.foo.__lambda1.b inout variables can only 
 be declared inside inout functions
 Failed: /Users/jacob/.dvm/bin/dvm-current-dc  -v -o- 
 '/Users/jacob/development/d/main.d' 
 -I'/Users/jacob/development/d'
/Users/jacob/development/d/main.d.deps

Is this a bug, a limitation of inout/delegate or am I doing something else wrong?

IIRC, inout must be applied to the return type too, and it only works in templates.
Oct 04 2012
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/04/2012 07:09 AM, Jesse Phillips wrote:
 On Thursday, 4 October 2012 at 13:55:39 UTC, Jacob Carlborg wrote:
 void foo (inout int[] arr)
 {
 auto a = { auto b = arr[0]; };
 }

 void main ()
 {
 auto a = [3, 4, 5];
 foo(a);
 }

 Compiling the above code with DMD 2.060 results in the following error
 message:

 Error: variable main.foo.__lambda1.b inout variables can only be
 declared inside inout functions
 Failed: /Users/jacob/.dvm/bin/dvm-current-dc -v -o-
 '/Users/jacob/development/d/main.d' -I'/Users/jacob/development/d'
/Users/jacob/development/d/main.d.deps

Is this a bug, a limitation of inout/delegate or am I doing something else wrong?

IIRC, inout must be applied to the return type too, and it only works in templates.

inout is like a template on 'mutable', const, and immutable; but it need not be applied to templates. Here is a simple example that transfers the mutability to the return type: http://ddili.org/ders/d.en/function_parameters.html inout(int)[] trimmed(inout(int)[] slice) { if (slice.length) { --slice.length; // trim from the end if (slice.length) { slice = slice[1 .. $]; // trim from the beginning } } return slice; } All three blocks below compile: { int[] numbers = [ 5, 6, 7, 8, 9 ]; // The return type is slice of mutable elements int[] middle = trimmed(numbers); middle[] *= 10; writeln(middle); } { immutable int[] numbers = [ 10, 11, 12 ]; // The return type is slice of immutable elements immutable int[] middle = trimmed(numbers); writeln(middle); } { const int[] numbers = [ 13, 14, 15, 16 ]; // The return type is slice of const elements const int[] middle = trimmed(numbers); writeln(middle); } inout can also be applied to member functions where the 'this' reference takes the mutability of a parameter and all of the member accesses becomes mutable, const, or immutable. Ali
Oct 04 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-04 16:18, Ali Çehreli wrote:

 inout is like a template on 'mutable', const, and immutable; but it need
 not be applied to templates. Here is a simple example that transfers the
 mutability to the return type:

I do think I understand how "inout" works, or at least I thought. I don't understand how the delegate affects anything. If I remove the delegate to this code it compiles: void foo (inout int[] arr) { auto a = arr[0]; } My actual problem is that I want to be able to pass both mutable, const and immutable to a function. In that function I want the "mutability" to persist. I first used const for my function and that works, kind of. The problem if I do like this: void foo (const int[] arr) { auto s = typeid(typeof(arr)).toString; // here "s" will be something like "const(const(int)[])" } I doesn't matter if I pass immutable or mutable, "s" will always be "const(const(int)[]". So I thought, "hey, that's what inout is for, I use that", then everything blows up. I'm using "typeid(typeof(arr))" in my serialization library to get a string representation of a type. I would prefer that the mutability was correct. -- /Jacob Carlborg
Oct 04 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 10/04/2012 11:30 PM, Jacob Carlborg wrote:
 On 2012-10-04 16:18, Ali Çehreli wrote:

 inout is like a template on 'mutable', const, and immutable; but it need
 not be applied to templates. Here is a simple example that transfers the
 mutability to the return type:

I do think I understand how "inout" works, or at least I thought. I don't understand how the delegate affects anything. If I remove the delegate to this code it compiles: void foo (inout int[] arr) { auto a = arr[0]; } My actual problem is that I want to be able to pass both mutable, const and immutable to a function. In that function I want the "mutability" to persist. I first used const for my function and that works, kind of. The problem if I do like this: void foo (const int[] arr) { auto s = typeid(typeof(arr)).toString; // here "s" will be something like "const(const(int)[])" } I doesn't matter if I pass immutable or mutable, "s" will always be "const(const(int)[]". So I thought, "hey, that's what inout is for, I use that", then everything blows up. I'm using "typeid(typeof(arr))" in my serialization library to get a string representation of a type. I would prefer that the mutability was correct.

This workaround makes the compiler happy: void foo (inout(int)[] arr) { auto a = (inout int) { auto b = arr[0]; }; } But probably not what you want. :/ IIRC, inout has bugs and incomplete implementation. I think this should be in the bug database. Ali
Oct 05 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-05 16:09, Ali Çehreli wrote:

 This workaround makes the compiler happy:

 void foo (inout(int)[] arr)
 {
      auto a = (inout int) { auto b = arr[0]; };
 }

 But probably not what you want. :/

 IIRC, inout has bugs and incomplete implementation. I think this should
 be in the bug database.

Hmm, I'll see if I can use that, thanks. -- /Jacob Carlborg
Oct 06 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-05 16:09, Ali Çehreli wrote:

 This workaround makes the compiler happy:

 void foo (inout(int)[] arr)
 {
      auto a = (inout int) { auto b = arr[0]; };
 }

 But probably not what you want. :/

 IIRC, inout has bugs and incomplete implementation. I think this should
 be in the bug database.

Using the above workaround did make it compile. But using typeid it now contains "inout" instead. It turns out I didn't need neither "const" or "inout", don't know why I added it in the first place. Thanks anyway. -- /Jacob Carlborg
Oct 07 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10/05/2012 04:09 PM, Ali Çehreli wrote:
 ...

 This workaround makes the compiler happy:

 void foo (inout(int)[] arr)
 {
      auto a = (inout int) { auto b = arr[0]; };
 }

 But probably not what you want. :/

 IIRC, inout has bugs and incomplete implementation. I think this should
 be in the bug database.

 Ali

The original behaviour is to be expected and the workaround exploits a compiler bug. The correct way to get rid of the compile error is: void foo(inout(int)[] arr){ auto a = { const b = arr[0]; } // or int b = arr[0]; }
Oct 08 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-08 21:40, Timon Gehr wrote:

 The original behaviour is to be expected and the workaround exploits a
 compiler bug.

 The correct way to get rid of the compile error is:

 void foo(inout(int)[] arr){
      auto a = { const b = arr[0]; } // or int b = arr[0];
 }

Why can't "auto" work there? BTW, this doesn't work: void foo (inout(int)[] arr) { auto a = { foreach (int e ; arr) {} }; } -- /Jacob Carlborg
Oct 08 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-04 16:09, Jesse Phillips wrote:

 IIRC, inout must be applied to the return type too, and it only works in
 templates.

What? The whole point of "inout" is to NOT have to use templates since the compiler will generate the same code anyway. http://dlang.org/function.html#inout-functions I also tried to make it a template but I get the same result. Actually in my original code it's a template. -- /Jacob Carlborg
Oct 04 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 04 Oct 2012 09:49:48 -0400, Jacob Carlborg <doob me.com> wrote:

 void foo (inout int[] arr)
 {
      auto a = { auto b = arr[0]; };
 }

 void main ()
 {
      auto a = [3, 4, 5];
      foo(a);
 }

 Compiling the above code with DMD 2.060 results in the following error  
 message:

 Error: variable main.foo.__lambda1.b inout variables can only be  
 declared inside inout functions
 Failed: /Users/jacob/.dvm/bin/dvm-current-dc  -v -o-  
 '/Users/jacob/development/d/main.d' -I'/Users/jacob/development/d'  
  >/Users/jacob/development/d/main.d.deps

 Is this a bug, a limitation of inout/delegate or am I doing something  
 else wrong?

It is a quirk of how inout is implemented. There are definitely some very tricky situations that inout has uncovered, and I think not all of them are handled gracefully. In my first vision for inout, I posited that inout variables should only be valid within inout functions. No point in declaring inout variables if you don't have inout parameters or return values, right? I mean the point of "in out" means what you get in is what you put out. So if you aren't using a wildcard on an input or output, there is no point of having an inout variable that can't be transferred anywhere. But logically, inout is simply another form of const. One that acts like immutable, but could refer to mutable data. Declaring something inout inside a non-inout function is useless, but not harmful. I think now, it should be allowed, because it's more useful to use auto in these situations, and IFTI goes into fits if you don't allow it. However, your case is interesting. A delegate is a function, and functions which are inout have the special feature of transferring const. In this case, you are pulling the data from the context pointer, not from a parameter. But the inout for your delegate may be a *different* inout than the one in your parameter. Here is a more demonstratable case: void foo(inout int* a) { int x; inout(int) * foosub(inout(int) * b) { inout(int) *result = a > b ? a : b; return result; } int *n = foosub(&x); } Note that n could end up being equal to a! Which means we have effectively removed the inout qualifier from it (very bad). I don't even know if the above compiles, but I suspect it does. There is a very confusing aspect of inout. When inout is inside a function, it's actual type is based solely on the function call itself. It actually should be that a and b above have *different* unassignable types. But it is very difficult and confusing thing to understand and implement, much less explain. I think at some point, inout needs another overhaul before it is truly a complete feature. -Steve
Oct 05 2012