catch without block/scope brackets

Jarrett Billingsley kb3ctd2 at yahoo.com
Wed Sep 5 06:49:28 PDT 2007


"Downs" <default_357-line at yahoo.de> wrote in message 
news:fblngc$egs$2 at digitalmars.com...
> I don't think this is an ambiguity. After all, catch(bar) is not a valid
> catch statement anyway, since the type is woefully missing.

I'm not saying catch(bar) _is_ valid, I'm saying that the compiler goes "oo, 
catch!  then lparen!  there must be a type and then an identifier next." 
Then it tries to parse a type and an identifier, but that fails.

I suppose it's not an ambiguity in the simple sense (two possible valid 
parse trees), but more like.. given the sequence of tokens, there's no way 
for the compiler to know what's next.  It's ambiguous, but one parse tree is 
valid and the other is not.  Having the compiler explicitly deal with these 
kinds of nasty issues ends up with a far more complex (and slower) compiler 
than simply having the grammar disallow them in the first place, like what's 
been done here. 





More information about the Digitalmars-d mailing list