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;