Meson: RFE: native support for const objects

[robEllenberg]

I'd like to be able to create a constant object (file, include path, etc.), and have meson throw an error if a later operation tries to redefine it.

This would make it possible to ensure that objects defined in subdir files aren't accidentally redefined, as in this example:

# Top-level meson.build
subdir('src/abc')
# assigns a new array to 'my_files':
subdir('src/def')
...

# src/abc/meson.build
my_files=files('1.c','2.c')



md5-cf99f61d66dcdc109aed681ecb010fd6



# src/def/meson.build
my_files=files('3.c','4.c')

As suggested here, a workaround exists (assert variable doesn't exist before defining it), but it's quite verbose, and vulnerable to the same kinds of mistakes that it's designed to fix (e.g. typos, copy / paste errors).

[nirbheek]

This seems useful, if somewhat limited. It might also be useful to be able to define an existing variable as const after a certain point, f.ex., to generate an array dynamically and then never change it again.

[xclaesse]

Nitpicking: I agree with the idea, however const commonly means immutable, and almost all objects are already immutable. Maybe protected ?

[jpakkane]

Or freeze('foo', 'bar')?

[robEllenberg]

@jpakkane "freeze" as a name makes sense, especially for the case that @nirbheek suggested (building a variable dynamically then making it const later).

What do you think of a function that takes an object argument and return a "frozen" version of it? Something like this:

# Wrap existing function calls
my_frozen_foo = freeze(foo_generator())

# Convert an existing variable
var_array = []
var_array += ...
frozen_array = freeze(var_array)



md5-cf99f61d66dcdc109aed681ecb010fd6



# Replace an existing value (not as clear but maybe less name clutter)
my_foo = foo_generator()
my_foo = freeze(my_foo)

I don't know how difficult this is to implement, since python doesn't allow assignment overloading.

[nirbheek]

I don't know how difficult this is to implement, since python doesn't allow assignment overloading.

We don't use the Python interpreter at all, so that doesn't matter.

This sounds like a good idea, we can create a wrapper type that supports all other objects and ensures that operations such as assignment don't work, and that read-only operations get proxied to the real object. Something similar to the Mapping Proxy type in Python.

[jpakkane]

The simpler option is to keep a list of frozen variable names and then check for that in the assignment method in interpreter.

[pmod]

Adding new function or keyword e.g. const will break meson.build backward compatibility. Would it be better to solve this with the help of adding new build option (e.g. along with b_asneeded, b_bitcode) with the name, say, b_cassign, e.g. const assignments.
This is both considering that this is not common case, but rather specific, and that this is more like precaution that can be switched off by default and turned on when assignments need to be checked.

[robEllenberg]

@pmod That's a good point, though adding a new function seems like a smaller breakage than a new keyword like const, especially if the function name is a verb like "freeze()".

The build option seems like a great idea, especially if many objects need to be const. It would both save typing and be one less thing to forget when writing subdir files. Either approach would solve my problem, though the build option would make it harder to build up variables dynamically as @nirbheek suggested.