Re: A thought about <const>

[Sergey Kovalev <kovserg33@...>]

function const(c)
    return setmetatable({},{__index=c,
        __newindex=function(t,n,v) error "read only" end
    })
end

local my = const { pi=3.14, e=2.71 }
print(my.pi,my.e)
my.pi=3 -- error

пн, 10 июн. 2019 г. в 23:27, Dibyendu Majumdar <mobile@majumdar.org.uk>:
>
> On Mon, 10 Jun 2019 at 21:21, Coda Highland <chighland@gmail.com> wrote:
> >> I am not sure of the usefulness of the proposed <const> qualifier, but
> >> it got me thinking whether it might be possible to implement compile
> >> time named constants using similar annotations. That is to say the
> >> code would be equivalent to writing directly using literals.
> >
> >
> > I certainly agree that compile-time named constants would be a nice thing to have, but I'm not 100% sure if it would have a measurable impact, because upvalues are also resolved at compile-time and you still have to push the value on the stack anyway. There's also not really a good way for modules to export compile-time named constants, which puts a significant limitation on how useful they are.
> >
>
> True.
>
> > However, non-assignable variables are pretty useful. There are some compiler optimizations that can happen when you know a variable is read-only, and of course asserting that something is read-only can help avoid programming mistakes.
> >
> > There's also no real reason the same qualifier couldn't be used for both. It would just be part of the optimization: if a compiler can statically determine the value of an expression, it can replace it with the result of that expression, and being read-only and initialized with a literal is a good way to ensure that the value can be statically determined.
> >
>
> Which leads me to a second thought about the syntax.
> If you wanted to declare a bunch of constants in one go, it might be
> nicer to be able to do it with a single annotation, rather than per
> variable annotation.
>