RE: Shorthand for appending to a table (was Re: 5.2 feature list?)

["Dave Nichols" <dave.nichols@...>]

:-)
The first rule of optimisation is: "don't".
The second rule, and this is for experts only, is: "not yet".
How much difference would it make?
a[] = b would need to be treated differently to a[nil] = b otherwise there
is scope for subtle bugs
what about a metamethod that is triggered by a nil index assign instead?
then you could code whatever behaviour you like

Regards,

Dave Nichols
Match-IT Limited
Tel: 0845 1300 510
Fax: 0845 1300 610
mailto:dave.nichols@make247.co.uk
http://www.make247.co.uk

Email Disclaimer: The contents of this electronic mail message and any
attachments (collectively "this message") are confidential, possibly
privileged and intended only for its addressee ("the addressee"). If
received in error, please delete immediately without disclosing its contents
to anyone. Neither the sender nor its management or employees will in any
way be responsible for any advice, opinion, conclusion or other information
contained in this message or arising from it's disclosure.


-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Eric Scouten
Sent: 11 September 2006 18:59
To: Lua list
Subject: Re: Shorthand for appending to a table (was Re: 5.2 feature
list?)


On 11 Sep 2006, at 10:50, Dave Nichols wrote:

> I disagree, why should an integer index be any more significant
> than a name?
> I think a missing index should be a syntax error as it is now.
> Use table.insert instead, it defaults to #+1

The problem with this is that table.insert means a function call (*),
whereas the syntax I proposed would be inline. In tight loops, this
makes a significant difference.

* It also means an extra table lookup unless you do something like


local tinsert = table.insert

     -- Inside the loop
tinsert( table, key, value )


-Eric