www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Nitpicking the D grammar

reply Jascha Wetzel <"[firstname]" mainia.de> writes:
Declaration vs. ExpressionStatement

struct S
{
     void opAdd(S s) {}
     void opMul(S s) {}
}

void main()
{
     S a, b;
     a * b;  // Error: a is used as a type
     a + b;  // compiles fine
}

The specs state that an expression is disallowed as a statement if it 
has no effect. DMD consequently allows expressions like "a + b" if they 
invoke an overloaded operator, except, and this is my point here, if the 
expression can be parsed as a declaration. In that case DMD prefers the 
declaration.

Disallowing expressions without an effect is nice, but wouldn't a 
warning suffice? After all the compiler can't find all expressions that 
have no effect. Besides, adding for example two integers and not saving 
the result (which is classified as a no-effect-expression) still has the 
effect of changing the eflags register, which may be read in an asm 
block. So it's questionable what "no effect" actually means.

Wouldn't it be more appropriate here to change the specs to
"Expressions that can be interpreted as a declaration, like (a*b), are 
illegal in expression statements. If such an expression is needed, 
casting it to void will make it legal."
(http://www.digitalmars.com/d/statement.html#ExpressionStatement)

and change the no-effect-error into a warning?
Sep 07 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Jascha Wetzel" <"[firstname]" mainia.de> wrote in message 
news:fbrk6q$1cv5$1 digitalmars.com...
<snip>

 Disallowing expressions without an effect is nice, but wouldn't a warning 
 suffice? After all the compiler can't find all expressions that have no 
 effect. Besides, adding for example two integers and not saving the result 
 (which is classified as a no-effect-expression) still has the effect of 
 changing the eflags register, which may be read in an asm block. So it's 
 questionable what "no effect" actually means.


Not if the compiler optimises it away.  As such, the contents of any 
register after such a statement would be undefined, so you can't really do 
anything with it.


 Wouldn't it be more appropriate here to change the specs to
 "Expressions that can be interpreted as a declaration, like (a*b), are 
 illegal in expression statements. If such an expression is needed, casting 
 it to void will make it legal."
 (http://www.digitalmars.com/d/statement.html#ExpressionStatement)


Such a statement in the spec would be null, because it isn't even parsed as 
an ExpressionStatement.

What the spec needs to do is properly document the disambiguation rules.

Stewart.
Sep 08 2007
parent reply Jascha Wetzel <"[firstname]" mainia.de> writes:
Stewart Gordon wrote:

 "Jascha Wetzel" <"[firstname]" mainia.de> wrote in message 
 news:fbrk6q$1cv5$1 digitalmars.com...
 <snip>

 Disallowing expressions without an effect is nice, but wouldn't a 
 warning suffice? After all the compiler can't find all expressions 
 that have no effect. Besides, adding for example two integers and not 
 saving the result (which is classified as a no-effect-expression) 
 still has the effect of changing the eflags register, which may be 
 read in an asm block. So it's questionable what "no effect" actually 
 means.


 
 Not if the compiler optimises it away.  As such, the contents of any 
 register after such a statement would be undefined, so you can't really 
 do anything with it.


you're right. the registers' contents aren't part of the language 
definition.


 Wouldn't it be more appropriate here to change the specs to
 "Expressions that can be interpreted as a declaration, like (a*b), are 
 illegal in expression statements. If such an expression is needed, 
 casting it to void will make it legal."
 (http://www.digitalmars.com/d/statement.html#ExpressionStatement)


 
 Such a statement in the spec would be null, because it isn't even parsed 
 as an ExpressionStatement.
 
 What the spec needs to do is properly document the disambiguation rules.


that was my shot at doing this. it's not very elegant, but it describes 
exactly what the parser does.
Sep 09 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Jascha Wetzel" <"[firstname]" mainia.de> wrote in message 
news:fc0qkl$1men$1 digitalmars.com...

 Stewart Gordon wrote:

 "Jascha Wetzel" <"[firstname]" mainia.de> wrote in message 
 news:fbrk6q$1cv5$1 digitalmars.com...




<snip>

 Wouldn't it be more appropriate here to change the specs to
 "Expressions that can be interpreted as a declaration, like (a*b), are 
 illegal in expression statements. If such an expression is needed, 
 casting it to void will make it legal."
 (http://www.digitalmars.com/d/statement.html#ExpressionStatement)






<snip>

 that was my shot at doing this. it's not very elegant, but it describes 
 exactly what the parser does.


But if you're talking of it in place of the current statement, then:
- it's a completely different statement, even as much as there's an overlap 
between the two
- (a*b) cannot be interpreted as a declaration.  a*b can though.

Perhaps better would be to add a statement here:
"Any statement that can be parsed as either a DeclarationStatement or an 
ExpressionStatement is treated as a DeclarationStatement, for example:
    a * b;    // declares b to be a pointer to type a
"

Stewart.
Sep 09 2007
parent Jascha Wetzel <"[firstname]" mainia.de> writes:
Stewart Gordon wrote:

 Perhaps better would be to add a statement here:
 "Any statement that can be parsed as either a DeclarationStatement or an 
 ExpressionStatement is treated as a DeclarationStatement, for example:
    a * b;    // declares b to be a pointer to type a
 "


agreed, that's nicer.
Sep 10 2007