I mean clearer because extra parenthesis is clearly a hack and adds to confusion (why you would need them somewhere and not elsewhere for equivalent expressions
I mean this trailing comma as the effect (like everywhere else in a comma-separated list of expressions) to discard additional values returned by each _expression_ and reduce them to a single value or nil.
Using extra parentheses also is inconsistent: it does not work for example with the return statement:
return (1,2)
still returns the two values to the caller, and
return ('A').byte(2)
still returns nothing to the caller
using a trailing comma here would fix both:
return 1,2,
would return one value only: 1; and
return ('A').byte(1),
return ('A').byte(2),
would return one value only for each return: 65 or nil
As well in arguments of function calls:
type(('A').byte(1),)
type(('A').byte(2),)
passes one value to the type function in each case: 65 or nil
As well in table constructors:
{ [2] = 'dummy', ('A').byte(1), ('A').byte(2), }
sets the two index [1] and [2] to 65 and nil respectively (the 'dummy' value in [2] is overriden)
And for another proposal I intend to make: i.e. passing parameters by names, and declaring functions with named parameters and defaults, the named parameters and their default will be stored in the function's environment created by the function definition (which is already a key-indexed table), and not just mapped to local variables in the local closure (initialized on entry from upvalues for unnamed parameters without default: local variables in local closure for arguments passed by name would first be initialized from the function's environment to get their default value, then arguments values passed by name will overwrite this default).
Calling a function with named parameters just means passing them in a table created by the caller, except that this table is not an argument of the function itself, it will be processed by the function entry itself (that will process them with the default values stored in the function's environment.
So you could declare simply: function fun{x = 0}
--[[statements...]] end
or just: function fun{x = 0} --[[statements...]] end
This would create an environment containing: { x = 0 } for the default values
You can call it using normal parentheses: fun(x=20) -- bind named parameter to arg['x']
But not that this is not equivalent to the call: fun(20) -- argument is passed in upvalue: arg[1]
And not equivalent to the call: fun{20} -- set arg[1]={20}
As well I'd like to see "parser attributes" added to Lua for *any* block of instruction or for *any* _expression_ in parentheses, just as a litteral string constant (or several sucessive ones) just before the actual _expression_ or block of instructions.
Parser attributes have lot of uses in other languages, the semantics of these attributes could even be implemented in pure Lua. They can provide interesting things, notably metadata, debugging/tracing info, parser directives (e.g. semantics of operators or numeric expressions and rounding modes), directives for the Lua script loader, digital signatures to any script such as this at the begining of a loadable Lua module:
[[security={
SHA1 = '43eg...',
SHA256 = '...'
['microsoft.Authenticode'] = '...'
}]]
[[strict, ieee.rounding]]
Note the use of "self": it references the object representing the script being loaded in the parser, that will then assert this statement, using the source of the script to compute and check the signatures for algorithms that it supports. A parser is not required to check these signatures or support all algorithms, it can choose to check only one. If it accepts the given algorithm, it will assert it or the parser will return an error to the caller of the parser, indicating that the script is not secure or has been tampered, so it will not run the rest of the Lua script.
This attribute is not a comment, its content really parsed (using the Lua syntax), just as a comma-separated list of expressions or members of a table constructor (you may have multiple attributes in the same string), possibly indexed as key/value, and each listed attribute may also be a subtable (like in the previous example); however the "expressions" in that list may not reference external variables by name: if you give a name, it becomes a string and is stored at an numeric index in the internal table built for parsed attributes (so the 'strict' attribute above is a string in attribute[1], the 'security={}" above is a table in attribute['security']. such facility however is not used for explicity keyed attributes (notably when their value is a normal Lua table).
"Parser attributes" are then just normal Lua string constants, they are not used when running the block or evaluating the _expression_, they are only used inside the parser (and can be used to compile the Lua script if needed to native code)
Parsers could use theses attributes to allow the code to use introspection and reflexion with more hints about expected types, values, code recommendations or deprecations, or as helpers for code generators (e.g. in IDE's like Eclipse or VStudio) and info for programming models (UML or similar)...
