www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - scope guard question

reply Arjan <arjan ask.me.to> writes:
```
void main()
{
   import std.stdio;
   auto f = (){
     string[] t;
     { // inner scope
       t ~= "hello";
       scope( exit ) t ~= "world";
     } // inner scope exit
     return t;
   };

   f().writeln; // ["hello", "world"]
}
```
removing the inner scope in f() gives ["hello"]

So when no inner scope is present, the scope exit 'runs' after 
the return? Is that indeed expected behavior according to the 
specification?
Jun 29 2020
next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Monday, 29 June 2020 at 22:31:12 UTC, Arjan wrote:


 So when no inner scope is present, the scope exit 'runs' after 
 the return? Is that indeed expected behavior according to the 
 specification?


Yes. A scope ends at the '}'. Destructors and scope guards 
execute then, after the return.
Jun 29 2020
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/29/20 6:31 PM, Arjan wrote:

 ```
 void main()
 {
    import std.stdio;
    auto f = (){
      string[] t;
      { // inner scope
        t ~= "hello";
        scope( exit ) t ~= "world";
      } // inner scope exit
      return t;
    };
 
    f().writeln; // ["hello", "world"]
 }
 ```
 removing the inner scope in f() gives ["hello"]
 
 So when no inner scope is present, the scope exit 'runs' after the 
 return? Is that indeed expected behavior according to the specification?


Yes. The return statement is inside the scope of the function, so it 
runs before the scope is exited. Are you saying the spec doesn't say that?

-Steve
Jun 29 2020
parent reply Arjan <arjan ask.me.to> writes:
On Monday, 29 June 2020 at 22:47:16 UTC, Steven Schveighoffer 
wrote:

 Yes. The return statement is inside the scope of the function, 
 so it runs before the scope is exited. Are you saying the spec 
 doesn't say that?


Thanks for the assurance. The spec does state it like this:
```
The ScopeGuardStatement executes NonEmptyOrScopeBlockStatement at 
the close of the current scope, rather than at the point where 
the ScopeGuardStatement appears.
```
Which is correct, but there is no single example with a return 
where the ScopeBlockStatement interferes with the return.

I started wondering about this since I hit a bug in a piece of 
code.
Jun 29 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/30/20 2:56 AM, Arjan wrote:

 On Monday, 29 June 2020 at 22:47:16 UTC, Steven Schveighoffer wrote:

 Yes. The return statement is inside the scope of the function, so it 
 runs before the scope is exited. Are you saying the spec doesn't say 
 that?


 
 Thanks for the assurance. The spec does state it like this:
 ```
 The ScopeGuardStatement executes NonEmptyOrScopeBlockStatement at the 
 close of the current scope, rather than at the point where the 
 ScopeGuardStatement appears.
 ```
 Which is correct, but there is no single example with a return where the 
 ScopeBlockStatement interferes with the return.
 
 I started wondering about this since I hit a bug in a piece of code.


I can see where it would be confusing, and it could probably contain an 
example and clarification.

-steve
Jun 30 2020
next sibling parent Arjan <arjan ask.me.to> writes:
On Tuesday, 30 June 2020 at 12:18:14 UTC, Steven Schveighoffer 
wrote:

 On 6/30/20 2:56 AM, Arjan wrote:

 On Monday, 29 June 2020 at 22:47:16 UTC, Steven Schveighoffer 
 wrote:

 [...]


 
 Thanks for the assurance. The spec does state it like this:
 ```
 The ScopeGuardStatement executes NonEmptyOrScopeBlockStatement 
 at the close of the current scope, rather than at the point 
 where the ScopeGuardStatement appears.
 ```
 Which is correct, but there is no single example with a return 
 where the ScopeBlockStatement interferes with the return.
 
 I started wondering about this since I hit a bug in a piece of 
 code.


 I can see where it would be confusing, and it could probably 
 contain an example and clarification.

 -steve


That would certainly be helpfull.
Jun 30 2020
prev sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Tuesday, 30 June 2020 at 12:18:14 UTC, Steven Schveighoffer 
wrote:

 I can see where it would be confusing, and it could probably 
 contain an example and clarification.


https://issues.dlang.org/show_bug.cgi?id=20997
Jun 30 2020