Why is it an anti-pattern?

I’m some-what skeptical of that.
It may be a novel concept to C++, but I would not call anything novel an anti-pattern.

You seem to be ok when Rust did
let x = x;

you even want that feature.
This could even see it as a more restrictive form of that same shadowing,
Where you can only shadow it with a const reference of the object with the same name (thus with the same type), it doesn’t even have type conversion.
Which has the added benefit that because the compiler sees the original type it doesn’t even need to store a new address it can just use the address of the original object, it can fully be handled at compile time and optimized as a no-op. (or alternatively you can see it as it is the same type so you can just re-use the same block of memory, doesn’t matter how you see it as long as the end result is the same).
It’s a 0 cost feature, that every developer at some point or another in their careers wish they could do to solve a problem, what else could you ask for?

If you are happy with:
uint32_t x =0;
uint32_t const& x = x;

(or even a much more extreme: uint64_t const x = x; )

why would all of a sudden
const x;
be an anti-pattern?


From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Jeremy Rifkin via Std-Proposals
Sent: Monday, February 17, 2025 7:21 AM
To: std-proposals_at_[hidden]
Cc: Jeremy Rifkin <rifkin.jer_at_[hidden]>
Subject: Re: [std-proposals] Delayed const declaration

Hi Tiago,
I have at times wanted to make a variable const at a later point than declaration, however, I think such a language feature would be confusing and an anti-pattern. As others have mentioned, IILEs and similar often provide sufficient solutions for cases where such a thing might be applicable.

One thing that comes to mind is how variable shadowing works in Rust. In Rust you can change the constness of something by shadowing it at a later time, e.g.:
let mut x = num;
x *= 2;
let x = x; // now const

This is a more generally useful capability as it allows you to change types in addition to just mutability. This can be useful when working with pointers or wrapper types. E.g. pseudocode:
let result = foo();
if(!result) { // handle a case like nullopt or std::expected holding an error
    return ....;
}
let result = *result; // now work with the actual value

Just my two cents, I'd be more interested in seeing something like this be added to C++ than some sort of const statement. We have precedence for this from `_`.

Cheers,
Jeremy

On Sat, Feb 15, 2025 at 4:05 PM Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Hi everyone,
I have hinted at this in another thread, what I want to propose is “delayed const declarations”. I.e. variables that are originally not declared const can be made const for the remainder of the scope.

-> Why?
We have all dealt with a case where we have an object that is awkward to initialize.
We want it to protect it with const to make sure it is no longer modified (except for its initial setup), but because of the awkward way that they start you can’t really declare const.

Ex.

errc awkward_init(uint32_t&)

uint32_t var;
awkward_init(var);
if( var == 0 )
{
 var = 1;
}
//I want it to be const here

-> Syntax
Not settled yet, I’m considering alternatives to specify this.
My current preferred way is:

const variable_name; //no type use, type of variable_name declared previously

i.e.

uint32_t var;
awkward_init(var);
if( var == 0 )
{
 var = 1;
}
const var; //delayed const declaration
var = 3; //error: var is const at this point in this scope

I don’t think is perfect, it looks a lot like a new declaration, but technically should be fine. I’m open to suggestions.

-> Corner cases
I’ve saying making it const for the “duration of the scope” instead of just “simply become const”. This is important.
Take the following case:

uint32_t var;
if(condition)
{
var =1;
const var;
}
else
{
var = 2;
}

var = 3; //Is it const here?

Because the compiler can’t know which of the paths was taken (this is runtime information), it becomes ambiguous in the example above.
So a delayed const declaration can only last for the duration of the scope in which they were declared const.

The following would be valid code:

uint32_t var;
var = 0; //ok
{
var = 1; //ok
const var;

//var = 2; //Not allowed
}

var = 3;// Ok


That’s everything.

I would welcome some feedback into the proposal before I start writing the paper.
And if would you like to help write the wording, that help would be appreciated.

Br,
Tiago


--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals