On Wed, Jun 12, 2019 at 12:46 PM David Heiko Kolf <
david@dkolf.de> wrote:
Coda Highland wrote:
> Can you write correct software without const locals? Of course you can.
> Is this a game-changing feature that's going to impact how everyone
> writes Lua code? No, it's not. You can still use Lua 5.4 without ever
> touching <const>. But since it's a feature that needed to be introduced
> to support <toclose>, there's no reason NOT to expose it to other uses
> as well, for the people who do want to make use of it.
I do see a reason not to expose it: to keep the core language as plain
as possible.
If constant variables are desired, I would wish for a language feature
specifically designed for them and not just some by-product of another
feature.
As Egor Skriptunoff already wrote in a separate thread, what would be
really useful would be constant global variables and table entries.
If I mess up a local variable the error would probably be rather local,
too. If I mess up a global variable (e.g. math.pi = 4) I create an error
in some random module.
So I got the impression that a new language feature is added just
because it appears to be "cheap" but in this case it reminds me of the
sentence "you've caught the kitten and let the cat escape".
Best regards,
David
That's a fair enough argument. However, in this case, it really IS cheap, in every sense. Not only does it require minimal effort to provide it, but it requires no additional cognitive effort on the user's part, it has no impact on the syntax of the language, and its semantic impact is wholly contained within its scope of use.
If this were C++-style const, where constness is a first-class element of the type system, then that would be different. Introducing it would have far-reaching repercussions that would require everyone to pay attention if it's used anywhere.
If it required introducing a new reserved word or new syntax, that would have had a cost. But because <toclose> was already committed to, <const> doesn't add any new syntactic requirements, and the annotation syntax is unambiguous existing structures and allows for additional annotation types to be added without introducing new limitations on user code.
So it really is a trivial thing to add with no drawbacks that I can see.
/s/ Adam
