• mw (33/33) Aug 26 2022 (orig post on learn
• Paul Backus (16/29) Aug 26 2022 I think the easiest way to do this is with a nested function:
• mw (5/7) Aug 26 2022 Yes, it's the same solution I end up with.
• Paul Backus (13/20) Aug 26 2022 I guess another possibility is something like this:
• mw (7/31) Aug 26 2022 Thanks.
• Paul Backus (4/11) Aug 26 2022 It's documented in the language spec, here:

mw <mingwu gmail.com> writes:

(orig post on learn 
https://forum.dlang.org/post/qzevyxtmksiximcxqgmn forum.dlang.org)

I just tried:

```
import std;

void main()
{
     writeln("Hello D");
     Object obj = null;
synchronized (obj) {
     writeln("Synchronized on null");
}
}
```
output:
Hello D
Error: program killed by signal 11


The following is the usage pattern I want:

```
void foo(lots of params) {
   Object lock = (a particular condition) ? realLock : null;

   synchronized(lock) {
     // lots of complex code block here
   }

}
```

i.e depending on a a particular condition, the complex code block 
either need to be sync-protected, or not needed.

Method foo() has lots of params, I try to avoid refactor the 
inner code block into a separate method.

Since it's not currently supported, can we add such feature? 
synchronized(null) ==> essentially means NO-OP, instead of NPE?

Thanks.

Paul Backus <snarwin gmail.com> writes:

On Friday, 26 August 2022 at 17:33:16 UTC, mw wrote:
 The following is the usage pattern I want:

 ```
 void foo(lots of params) {
   Object lock = (a particular condition) ? realLock : null;

   synchronized(lock) {
     // lots of complex code block here
   }

 }
 ```

 i.e depending on a a particular condition, the complex code 
 block either need to be sync-protected, or not needed.

 Method foo() has lots of params, I try to avoid refactor the 
 inner code block into a separate method.

I think the easiest way to do this is with a nested function:

```d
void foo(/* lots of params */) {
     Object lock = /* condition */ ? realLock : null;

     void innerBlock() {
         // lots of complex code here
     }

     if (lock)
         synchronized(lock) innerBlock();
     else
         innerBlock();
}
```

Since `innerBlock` has access to `foo`'s parameters via its 
context, you should not need to do any complicated refactoring.

mw <mingwu gmail.com> writes:

On Friday, 26 August 2022 at 18:51:06 UTC, Paul Backus wrote:
 Since `innerBlock` has access to `foo`'s parameters via its 
 context, you should not need to do any complicated refactoring.

Yes, it's the same solution I end up with.

However, I still think synchronized(null) ==> NOOP is a better 
semantics than NPE.

Then I don't even need such innerBlock(), and the if-else.

Paul Backus <snarwin gmail.com> writes:

On Friday, 26 August 2022 at 19:26:12 UTC, mw wrote:
 On Friday, 26 August 2022 at 18:51:06 UTC, Paul Backus wrote:
 Since `innerBlock` has access to `foo`'s parameters via its 
 context, you should not need to do any complicated refactoring.

 Yes, it's the same solution I end up with.

 However, I still think synchronized(null) ==> NOOP is a better 
 semantics than NPE.

 Then I don't even need such innerBlock(), and the if-else.

I guess another possibility is something like this:

```d
void foo(...) {
     scope Object fakeLock = new Object; // allocated on stack
     Object lock = condition ? realLock : fakeLock

     synchronized (lock) {
         // code here
     }
}
```

Since `fakeLock` is local to the function, synchronizing on it 
should be effectively a no-op.

mw <mingwu gmail.com> writes:

On Friday, 26 August 2022 at 19:47:18 UTC, Paul Backus wrote:
 On Friday, 26 August 2022 at 19:26:12 UTC, mw wrote:
 On Friday, 26 August 2022 at 18:51:06 UTC, Paul Backus wrote:
 Since `innerBlock` has access to `foo`'s parameters via its 
 context, you should not need to do any complicated 
 refactoring.

 Yes, it's the same solution I end up with.

 However, I still think synchronized(null) ==> NOOP is a better 
 semantics than NPE.

 Then I don't even need such innerBlock(), and the if-else.

 I guess another possibility is something like this:

 ```d
 void foo(...) {
     scope Object fakeLock = new Object; // allocated on stack
     Object lock = condition ? realLock : fakeLock

     synchronized (lock) {
         // code here
     }
 }
 ```

 Since `fakeLock` is local to the function, synchronizing on it 
 should be effectively a no-op.


Thanks.

Is there any documentation for creating class object on the stack?

I only found this discussion:

https://forum.dlang.org/thread/srbzvjezicpuhxhzzoyb forum.dlang.org?page=2


Also I want confirmation that this scope usage will not be 
deprecated in the future.

Paul Backus <snarwin gmail.com> writes:

On Friday, 26 August 2022 at 20:49:52 UTC, mw wrote:
 Thanks.

 Is there any documentation for creating class object on the 
 stack?

 I only found this discussion:

 https://forum.dlang.org/thread/srbzvjezicpuhxhzzoyb forum.dlang.org?page=2


 Also I want confirmation that this scope usage will not be 
 deprecated in the future.

It's documented in the language spec, here:

https://dlang.org/spec/attribute.html#scope-class-var

As far as I am aware there is no plan to deprecate this usage.