Stewart Gordon <smjg_1998@yahoo.com> wrote:

[...]
> And since this particular imperfection doesn't exist in current D, this section doesn't have to influence when/where Walter admits it.

I'm giving up. I am not talking of the cast ambiguity of C(++) is existing in D, but an ambiguity on the synchronized/debug statement.

But now it seems hopeless to me, that only a gloom of understanding will enlighten your horizont.

Thanks for your patience.

-manfred

On Wed, 4 May 2005 00:19:33 +0000 (UTC), Manfred Nowak wrote:

> Stewart Gordon <smjg_1998@yahoo.com> wrote:
> 
> [...]
>> And since this particular imperfection doesn't exist in current D, this section doesn't have to influence when/where Walter admits it.
> 
> I'm giving up. I am not talking of the cast ambiguity of C(++) is existing in D, but an ambiguity on the synchronized/debug statement.
> 
> But now it seems hopeless to me, that only a gloom of understanding will enlighten your horizont.
> 
> Thanks for your patience.

If it helps, Manfred, I understood your concerns. And your proposed solutions were reasonable too. There does exist an ambiguity in the language. With the 'debug', as Walter points out, it probably doesn't matter because bad expressions could be caught at compile time. With the synchronized statement, as you point out, ambiguities can be resolved by placing the 'target' statement inside braces. So in the end, I guess it would not be a high priority need to address these ambiguities prior to v1.0

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build/ v2.05 released 02/May/2005
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
4/05/2005 10:36:58 AM

Derek Parnell wrote:
> On Wed, 4 May 2005 00:19:33 +0000 (UTC), Manfred Nowak wrote:
<snip>
>>I'm giving up. I am not talking of the cast ambiguity of C(++) is existing in D, but an ambiguity on the synchronized/debug statement.

Sorry if I misunderstood.  We must have been talking at cross purposes from the moment the C(++) cast ambiguity was mentioned on the thread.

>>But now it seems hopeless to me, that only a gloom of understanding will enlighten your horizont.
>>
>>Thanks for your patience.
> 
> If it helps, Manfred, I understood your concerns. And your proposed
> solutions were reasonable too. There does exist an ambiguity in the
> language. With the 'debug', as Walter points out, it probably doesn't
> matter because bad expressions could be caught at compile time.

I suppose it's OK for some ambiguities to be resolved by "if it's parseable as X, it's X, otherwise it's Y" rules.  In these cases, X would be

    synchronized ( Expression ) Statement
    debug ( IntegerLiteral ) Statement
    debug ( Identifier ) Statement

which would make

    synchronized (qwert) - yuiop;

equivalent to

    synchronized (qwert) { -yuiop; }

but

    synchronized (qwert) / yuiop;

equivalent to

    synchronized { (qwert) / yuiop; }

Is this how DMD behaves at the moment?  Or does it simply fail once it's tried to parse

    / yuiop;

as a statement?

> With the synchronized statement, as you point out, ambiguities can be resolved by
> placing the 'target' statement inside braces. So in the end, I guess it
> would not be a high priority need to address these ambiguities prior to
> v1.0

I still consider this case worth doing something about:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1955
(see followups for how it could be resolved)

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.