lua-users home
lua-l archive

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


> Then there are two different concepts of const at play:
> 
> * Once a variable is declared const, it is beyond strongly typed: it
> can't refer to another object, even if the new object is a table.
> 
> * Once a table is declared const, it's keys may not change, and the
> keys must be known at CT.
> 
> This is, in C, the difference between: const type * and type * const,
> but for the purposes of this proposal, a lua declaration such as:
> 
> constant t = {}
> 
> sets both the variable name and the table to const

Yep, well aware of the various uses of const in C as well as static in Java etc etc.

My point throughout has not been if its POSSIBLE to do this, it's been the scope of the changes implied. My original "local … from" was nothing more than simple syntactic sugar to (a) decrease typing and (b) reduce errors caused by mis-matching of local names to a long list of table field names. By itself, this has some legs imho, and the changes made to the language are trivial and have no broad-reaching side effects beyond the (always risky) introduction of a new keyword.

What is the scope of "t" in your example? If it's global, there are all sorts of issues. Consider this:
constant t = {}
_G["t"] = 100

What you are really suggesting I think, at its root, is an immutable table (think strings) whose content is known at compile time. That is a very significant change to the language, with broad-reaching consequences, a lot of very subtle changes, and some significant additional complexity to the compiler. It is also, imho, moving Lua away from the "dynamic" model and toward a more compiler-centric declarative, strongly typed model … and I for one don't feel very comfortable with that thought.

--Tim