Thoughts on new syntax for <const>

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Thoughts on new syntax for <const>

Sean Conner

  It appears that <const> just marks a local variable as non-assignable:

        > local <const> x = 5 x = 6
        stdin:1: assignment to const variable 'x'
        >

  But the target isn't constant:

        > local <const> x = {} x.foo = 1
        >

  To get a constant table, you would still have to use a proxy table and
intercept __index and __newindex.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Thoughts on new syntax for <const>

Coda Highland


On Tue, May 21, 2019 at 10:17 PM Sean Conner <[hidden email]> wrote:

  It appears that <const> just marks a local variable as non-assignable:

        > local <const> x = 5 x = 6
        stdin:1: assignment to const variable 'x'
        >

  But the target isn't constant:

        > local <const> x = {} x.foo = 1
        >

  To get a constant table, you would still have to use a proxy table and
intercept __index and __newindex.

  -spc


As a Javascript programmer, this is familiar behavior.

As a C++ programmer, this is irritating. XD (C++ can have const pointers to non-const objects that match this behavior, but they're not often used.)

As a compiler author, I can totally understand the rationales behind both ways of doing it, and I think Lua's decision in this regard is the right one for its use case. There was already a mechanism for making an object immutable, but there was not a mechanism for making a variable non-reassignable. This addresses that shortcoming, so now you have the flexibility of choice to use whatever combination of behaviors is appropriate for your program.

/s/ Adam