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

[Jonathan Goble <jcgoble3@...>]

On Mon, Mar 14, 2016 at 10:41 AM, Hisham <h@hisham.hm> wrote:
> 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.

That was precisely the intent of my argument: that a common argument
against a change is not present in this case. The +1 vote was not
purely for a lack of ambiguity.

> 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()`.

This is the main reason I support this change: because some keywords
would otherwise be natural field names in a data table or object.
"end" is one that I ran into while developing something for my
matchext library, and instead of using "start" and "end" as fields for
the start and end positions of a match, I ended up having to use
"startpos" and "endpos". The ability to use "end" as a field name
would be nice.