lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Jun 10, 2009, at 3:02 AM, Olivier Hamel wrote:

* (VM?) + Lexer: Have an explicitly defined handling of cases like {[3] = 3, 1, 2, 3} and do not adjust the return codes to one unless an operation is directly performed on it. Example: local tbl = {ReturnSixIncrementalValuesFromZeroToSix(), 7, 8, 9} -- this would equate to doing {1, 2, 3, 4, 5, 6, 7, 8, 9} local tbl = {ReturnSixIncrementalValuesFromZeroToSix() + 10, 7, 8, 9} -- this would equate to doing {11, 7, 8, 9} The alternate suggestion of using ';' to elaborate when to use multiple returns might be better (feedback on this please?)?

I'll let others discuss the pros and cons -- one of the big cons being compatibility -- but I will concur that it would be nice to have some sort of splicing construction for tables if only to allow for functions that returned nothing and didn't then insert a nil into the table which then tells ipairs that it's the end of the table:

ViewList = {
	Button( "I'm always here" ),
	Optional( TestCondition(), Button( "Condition Was True" ) )
	Button( "I'm always here too" )

The current work around for this is to have Optional return a "should not be here value" and have a post-process remove such values. One can also address splicing that way. But that doesn't feel quite as natural when building structures.

On the other hand, I don't know what syntax I would propose for this. It probably needs to stand out, but the more it stands out the more it risks not being used properly.