I think it would make the syntax more consistent.
a = function () end is equivalent to function a() end.
Now how shall a beginner understand that this is not applicable to { a = function () end }?
Inside that function's body it again would be ok to use the syntactic sugar.
To make things worse you get a syntax error that is as helpful as: '(' expected near 'a'
I think that’s a terrible idea, if only because of the visual and grammatical ambiguity it introduces.
...
When I see { function..., function... } my natural inclination is to see
those as array items 1 and 2, which they would be in the current
syntax.
Why? This does not resolve to a value. So why would it be assigned to [1] and [2] ? You cannot simply ignore the provided names.
I don't see any ambiguity here.
For any key that is not a name you have to use the old syntax. function a() end never worked for anything but valid names, so why not use it
instead of {a = function () end } where a needs to be a name as well.
Most arguments against it so far were "that's ugly". We already have this "ugly" syntax, so why not allow to make consistently ugly code :)
Nobody has to use that syntax and it does not break existing code.
Either that or an update to the manual and a proper error message to emphasize that this syntax may not be used to create table fields.
