Re: Allow table.keyword rather than table['keyword']?

[Hisham <h@...>]

On 14 March 2016 at 09:13, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>> Unless I'm missing something, this wouldn't result in any ambiguous
>> syntax. An identifier, followed by a . or :, followed by a keyword, is
>> never valid syntax under current rules, so treating the keyword in
>> that sequence of tokens as an identifier shouldn't cause problems.
>>
>> So I'm +1 on this. It would be nice to have the ability to do things
>> like _G.end (or _ENV.end). Again, unless I'm missing something (which
>> I very well might be given that I'm currently recovering from a cold
>> that's screwing with my thinking a bit).
>
> If not causing ambiguity is a good enough reason,

I don't think it was ever stated as being a good enough reason, but
the converse is often argued as the show-stopper for _not_ allowing
keywords. In other words, it's not that it is a decisive pro, but its
negation is often considered a decisive con.

As for pros, not allowing keywords in these situations sometimes leads
to situations with contrived names (such as `bit32.band`...), and I
had to uglify my code in the past with `bla.["keyword"]` in situations
where all other uses of bla were nicely `bla.field`. On the other
hand, I wouldn't like the inconsistency of being able to use `x` to
write `bla.x`, `{ x = 123 }`, `function x()`, `x()`; but then being
able to use `and` to write `bla.and`, `{ and = 123 }`, `function
and()` but not `and()`.

I think a language with different whitespace rules (where `and(x)` ≠
`and (x)`) could get away with allowing keywords as identifiers
consistently, but that's not the case in Lua.

-- Hisham