Date: Mon, 17 Feb 2025 00:21:00 -0600
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]> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
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]> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-02-17 06:21:13