> This seems even more strange; instead of giving a “missing type in composite literal” error, it gives a syntax error.
That's a syntactic limitation (wilful I assume): `{1, 2}` is not a valid expression in general, however it is specifically allowed as an item within an existing composite literal:
The "LiteralValue" item occurs only as a sub-item of the CompositeLit rule, which means it's not valid as a function parameter (or as a value to set on a variable, or as a return value).
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...
> 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.
That's a syntactic limitation (wilful I assume): `{1, 2}` is not a valid expression in general, however it is specifically allowed as an item within an existing composite literal:
The "LiteralValue" item occurs only as a sub-item of the CompositeLit rule, which means it's not valid as a function parameter (or as a value to set on a variable, or as a return value).