void main()
{
        Object [char[]] map;

        synchronized void test(char[] key)
        {
                Object x = map[key];
        }

        test ("foo");
}

# foo.d(10): undefined identifier test
# foo.d(10): function expected before (), not test of type int

In article <dju0b3$2el5$1@digitaldaemon.com>, Kris says...
>
>void main()
>{
>        Object [char[]] map;
>
>        synchronized void test(char[] key)
>        {
>                Object x = map[key];
>        }
>
>        test ("foo");
>}
>
># foo.d(10): undefined identifier test
># foo.d(10): function expected before (), not test of type int
>
>


No, it should be


> void test(char[] key)
> {
>   synchronized {
>     Object x = map[key];
>   }
> }

see http://www.digitalmars.com/d/statement.html#synchronize

synchronized had never been doing anything the way you use it. Remember, it's D not Java.

Kind regards,
Stefan

"Kris" <fu@bar.com> wrote in message news:dju0b3$2el5$1@digitaldaemon.com...
> void main()
> {
>         Object [char[]] map;
>
>         synchronized void test(char[] key)
>         {
>                 Object x = map[key];
>         }
>
>         test ("foo");
> }
>
> # foo.d(10): undefined identifier test
> # foo.d(10): function expected before (), not test of type int

synchronized isn't supported for nested functions, because it conflicts with the SynchronizedStatement. What you can do, though, is wrap the statements inside the function in a synchronized statement:

void test(char[] key)
{
    synchronized { Object x = map[key]; }
}

In article <djucun$2r2b$1@digitaldaemon.com>, Stefan Zobel says...
>
>No, it should be
>
>
>> void test(char[] key)
>> {
>>   synchronized {
>>     Object x = map[key];
>>   }
>> }
>
>see http://www.digitalmars.com/d/statement.html#synchronize
>
>synchronized had never been doing anything the way you use it. Remember, it's D not Java.
>

Oops, forget that - my mistake, sorry! Somehow I completely missed that synchronized is also a valid storage class (http://www.digitalmars.com/d/declaration.html). I was damn' sure that the statement is the only way to do it (like lock in C#). Coming from Java I actually prefer it this way :)

Kind regards,
Stefan

> synchronized had never been doing anything the way you use it.

Au contraire. For example, the following syntactic-sugar is perfectly legal, as one would expect. It has been supported for all the time I've used D:

# class Foo
# {
#     synchronized void foo(){}
# }

yet this, at module scope, produces a clear (and recent?) error message:

# synchronized void foo() {}
#
# void main() {}

"function test.foo synchronized function foo must be a member of a class"

However the following is acceptable at module scope, as it is within class methods (previously, this particular syntax would sometimes hang the executable):

# void main()
# {
#     synchronized {/* do something */}
# }

In the first case, the synch is upon the class instance, whereas in the third case (above) the synch is effectively on an implicit module-level object. That begs the question: why the error message in case two? Shouldn't it just synch on the same implicit module-level object as case three? I think it should.

In other words, 'synchronized' within the declaration itself is simply syntactic sugar; it effectively causes a synchronized block to be placed around the function statements ~ just like the explicit code in case three. It seems odd that one cannot use the former wherever one can use the latter.

The original example below does /not/ produce an error message for the sugary declaration of the nested function. Instead, it errors on the invocation instead. As such there's a diagnostic difference from example two, above. That is, said sugary declaration is accepted without error in the case of a nested function; just as it is when declaring a class method; whereas it is not accepted on a module-level declaration. Therefore:

1) there's a diagnostic bug. Specifically with respect to nested functions outside of a class.

2) there's the question as to why the sugary syntax isn't supported outside of a class.


> Remember, it's D not Java.

Such pointless & bigoted pontificating has no value or bearing upon this topic ~ thus, Stefan, it's really not very helpful. Let's not go there, please.




"Stefan Zobel" <Stefan_member@pathlink.com> wrote in message news:djucun$2r2b$1@digitaldaemon.com...
> In article <dju0b3$2el5$1@digitaldaemon.com>, Kris says...
>>
>>void main()
>>{
>>        Object [char[]] map;
>>
>>        synchronized void test(char[] key)
>>        {
>>                Object x = map[key];
>>        }
>>
>>        test ("foo");
>>}
>>
>># foo.d(10): undefined identifier test
>># foo.d(10): function expected before (), not test of type int
>>
>>
>
>
> No, it should be
>
>
>> void test(char[] key)
>> {
>>   synchronized {
>>     Object x = map[key];
>>   }
>> }
>
> see http://www.digitalmars.com/d/statement.html#synchronize
>
> synchronized had never been doing anything the way you use it. Remember,
> it's
> D not Java.
>
> Kind regards,
> Stefan
>
> 

Thanks, Walter.

Just out of interest, can you expand upon why the declarative sugar is disallowed at module-scope, while synch{} blocks are supported?

For example:

# module x;
# void foo() {synchronized{//OK}}
# synchronized void bar() {//error}

Why is foo() OK, but bar() not? Doesn't the sugar just add a synch-block around the interior function statements?



"Walter Bright" <newshound@digitalmars.com> wrote in message news:djufq0$2ta8$3@digitaldaemon.com...
>
> "Kris" <fu@bar.com> wrote in message news:dju0b3$2el5$1@digitaldaemon.com...
>> void main()
>> {
>>         Object [char[]] map;
>>
>>         synchronized void test(char[] key)
>>         {
>>                 Object x = map[key];
>>         }
>>
>>         test ("foo");
>> }
>>
>> # foo.d(10): undefined identifier test
>> # foo.d(10): function expected before (), not test of type int
>
> synchronized isn't supported for nested functions, because it conflicts
> with
> the SynchronizedStatement. What you can do, though, is wrap the statements
> inside the function in a synchronized statement:
>
> void test(char[] key)
> {
>    synchronized { Object x = map[key]; }
> }
>
> 

In article <djui7o$2vdb$1@digitaldaemon.com>, Kris says...
>
>
>> Remember, it's D not Java.
>
>Such pointless & bigoted pontificating has no value or bearing upon this topic ~ thus, Stefan, it's really not very helpful. Let's not go there, please.
>


Sorry for spreading this guff about synchronized, Kris.

I really was under the impression that the compiler ignores it when applied to a method declaration. Someone said so on the NG, but I should have checked that before making such unjustified claims, of course!

I didn't want to engage in Java bashing but rather caution Java programmers against an imaginary (as I now know) pitfall. In fact, I've made a living from Java programming for 6 years and I actually like the language.

Kind regards,
Stefan

Didn't see your second post before replying. No worries!


"Stefan Zobel" <Stefan_member@pathlink.com> wrote in message news:djum64$q1$1@digitaldaemon.com...
> In article <djui7o$2vdb$1@digitaldaemon.com>, Kris says...
>>
>>
>>> Remember, it's D not Java.
>>
>>Such pointless & bigoted pontificating has no value or bearing upon this topic ~ thus, Stefan, it's really not very helpful. Let's not go there, please.
>>
>
>
> Sorry for spreading this guff about synchronized, Kris.
>
> I really was under the impression that the compiler ignores it when applied to a method declaration. Someone said so on the NG, but I should have checked that before making such unjustified claims, of course!
>
> I didn't want to engage in Java bashing but rather caution Java programmers against an imaginary (as I now know) pitfall. In fact, I've made a living from Java programming for 6 years and I actually like the language.
>
> Kind regards,
> Stefan
>
> 

"Kris" <fu@bar.com> wrote in message news:djuim4$2vl9$1@digitaldaemon.com...
> Thanks, Walter.
>
> Just out of interest, can you expand upon why the declarative sugar is disallowed at module-scope, while synch{} blocks are supported?
>
> For example:
>
> # module x;
> # void foo() {synchronized{//OK}}
> # synchronized void bar() {//error}
>
> Why is foo() OK, but bar() not? Doesn't the sugar just add a synch-block
> around the interior function statements?

At the moment it isn't supported because the class member function version uses the 'this' pointer as its monitor. There is no monitor for the module scope one, though it could be supported by using the global monitor.

OK ~ thank you for the clarification.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:djutjq$6tn$1@digitaldaemon.com...
>
> "Kris" <fu@bar.com> wrote in message news:djuim4$2vl9$1@digitaldaemon.com...
>> Thanks, Walter.
>>
>> Just out of interest, can you expand upon why the declarative sugar is disallowed at module-scope, while synch{} blocks are supported?
>>
>> For example:
>>
>> # module x;
>> # void foo() {synchronized{//OK}}
>> # synchronized void bar() {//error}
>>
>> Why is foo() OK, but bar() not? Doesn't the sugar just add a synch-block
>> around the interior function statements?
>
> At the moment it isn't supported because the class member function version uses the 'this' pointer as its monitor. There is no monitor for the module scope one, though it could be supported by using the global monitor.
>
>