4 ms·
If you look at the GopherCon talk I gave (linked at the beginning of the post), it is about reading the spec. So yes, I did read the spec, and I realize that th
by typesanitizer 4y ago
If you look at the GopherCon talk I gave (linked at the beginning of the post), it is about reading the spec. So yes, I did read the spec, and I realize that this is not syntactically valid (it would be a very basic compiler bug if this were valid syntax and it was diagnosed as a syntax error).
However, the spec only states what _is_ but not _why_ it is that way. Sure, I could look at the git blame of the spec for every odd thing I run into, but there is only so much time in the day...
- masklinn 4y ago> However, the spec only states what _is_ but not _why_ it is that way. Sure, I could look at the git blame of the spec for every odd thing I run into, but there is only so much time in the day... Parsing simplicity and disambiguity (and thus speed) is a pretty obvious reason: if you allow `{}` to be an expression, then you have to look ahead any time you encounter an unprefixed `{` to try and figure out whether it's an expression or a block opening brace. Or you have to make your grammar into an unholy mess such that {} is an Expression but not an ExpressionStmt.