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