On Friday 04 March 2011 19:10:35 uri wrote: > Jonathan M Davis Wrote: > > On Friday 04 March 2011 17:05:57 Simon Buerger wrote: > > > It is often said that D's grammar is easier to parse than C++, i.e. it > > > should be possible to seperate syntactic and semantic analysis, which > > > is not possible in C++ with the template-"< >" and so on. But I found > > > following example: > > > > > > The Line "a * b = c;" can be interpreted in two ways: > > > -> Declaration of variable b of type a* > > > -> (a*b) is itself a lvalue which is assigned to. > > > > > > Current D (gdc 2.051) interprets it always in the first way and yields > > > an error if the second is meant. The Workaround is simply to use > > > parens like "(a*b)=c", so it's not a real issue. But at the same time, > > > C++ (gcc 4.5) has no problem to distinguish it even without parens. > > > > > > So, is the advertising as "context-free grammar" wrong? > > > > Umm. How could a * b be assigned to? It's definitely not an lvalue. Do > > you mean that an overloaded opBinary!"*" is used which returns a ref? It > > certainly can't be done normally. > > Explain why (a*b) is lvalue in bearophile's second example. This is one of > the weird things in D. The language is too complex. It takes years to find > out about the corner cases. I wouldn't use it for anything reliable
I'd argue that it's a bug related to operator overloading. = is converted to opAssign, which is then essentially a normal function. And because the result of * is a Foo which has an overloaded opAssign, the call to opAssign succeeds like any other function call would, because = was lowered to opAssign. I don't see what else could possibly be happening here. And since this violates the fact that opAssign is supposed to operate on lvalues, and the result of a * b is an rvalue, not an lvalue, this is a bug. - Jonathan M Davis