On February 16, 2025 7:36:47 PM Tiago Freire <tmiguelf_at_[hidden]> wrote:

>> I feel that if the answer is "uint32_t before const var; and const uint32_t
>> after" then this will be problematic as we're effectively changing the type
>> of an object without reconstructing it, and this is unprecedented.
>
> Yes, after const var, var would be const. So decltype(var) would be
> uint32_t const. But why would this be problematic?
> This sort of thing happens all the time in other places.
> uint32_t const& var1 = var; //var1 references the same object, but it is const
> void foo(uint32_t const& local); //can pass a non-const var and internally
> it is treated as if the object is const.
> do_something(const_cast<uint32_t const&>(var)); //perfectly valid

In all above cases you're binding a reference to var, while var itself
remains uint32_t. The proposal is different since it changes the type of
var itself. More so, it seems this change can happen in run time (e.g.
depending on a runtime condition).

> We just want the compiler to prevent us from modifying the value. How would
> there any visible side-effects for treating the object as if it was const?

I can't immediately point where changing type of an object would break the
language, but I can see it bringing surprises to users, where adding a
const declaration to an existing code changes types of expressions in the
subsequent code, including when types are deduced in template parameters.