> 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

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?



-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Andrey Semashev via Std-Proposals
Sent: Sunday, February 16, 2025 4:23 PM
To: std-proposals_at_lists.isocpp.org
Cc: Andrey Semashev <andrey.semashev_at_gmail.com>
Subject: Re: [std-proposals] Delayed const declaration

On 2/16/25 01:04, Tiago Freire via Std-Proposals 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.

How would this proposal affect the type of the variable? I.e. what is
decltype(var) at different points in the program?

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. If the answer is "uint32_t in all places" then the next question is "what prevents an assignment to this object?" That is, what prevents the following from compiling:

  uint32_t& ref = var;
  ref = 10;

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