Hi there, thank you for your participation. Please read this e-mail thread carefully.
We considered some examples (both passing through function parameter and assignment) where "Foo**" -> "const Foo * const * const" conversion might happen. Both of these examples are real-life use-cases. And we also discussed how introducing new default behaviour will influence them. So, coding style will suffer for sure. I am not sure about the examples you have just mentioned. I am not sure they are very rare and it looks like they (examples) are a little bit irrelevant to the subject matter being discussed within this e-mail thread. Respectfully, Aleksandr G Povaliaev. вт, 9 дек. 2025 г. в 21:12, Andrey Tarasevich <[email protected]>: > > > On 12/09/2025 4:49 AM PST Александр Поваляев via Gcc-help < > [email protected]> wrote: > > ... > > But if you skip some of "const", type naming might be less readable and > > understandable. > > > > All-CONST == CONST INVARIANT == "[IN]PARAMETER". > > > > Yep, we use 'void Func(int i)' instead of 'void Func(const int i)' cause > > this is how traditions work :) > > ... > > But here you are talking about the _function_ _parameter_. Meanwhile, in > the > previous messages we were talking about the _cast_. The cast and the > parameter > are two different things. So, leave alone the parameter for a minute and > let's > talk about the _cast_ itself. > > Since my reference to formal standard concepts seem to gain no traction > with > you, permit me to annoy you a bit more with a couple of my famous > "irrelevant" > examples instead. > > Consider this simple program in C > > int main(void) { > const const const const int a = (const const const const int) 3.14; > } > > Believe it or not, this a perectly valid C program. (C++ will give you > hell for > this, but it is 100% valid in C.) The language will simply quetly collapse > the > repetitive `const` qualifiers. > > However, if you show the above code to any competent C programmer, they > will > probably give you that "WTF?" look in return. And indeed, WTF? I hope > you'll > agree with me: even though the code is valid, the usage of `const` in it > is > somewhat... excessive. Unjustifiably excessive. > > So, let's say we decided to dial it down to something more sensible and > came up > with the following variant > > int main(void) { > const int a = (const int) 3.14; > } > > This looks a lot cleaner. But still... A competent C programmer might > reluctantly > point out the fact that the _cast_ is still somewhat nonsensical. You see, > semantically there's really no such thing as cast to `(const int)` in C. > The > result of a cast in C is always an Rvalue, and an Rvalues in C cannot be > const-qualfied. In C top-level `const` on Rvalues is always ignored. > > An excessive top-level `const` in a cast is not an error. It is simply > quietly > ignored by the compiler. The compiler immediately sees the above cast as > cast to > `(int)`. But the point is (!) that casting something to `(const int)` is > pretty > much as excessively nonsensical as casting something to `(const const > const const int)`. > > Again, formally this is not an error, so it is kinda partially drifts into > the > area of personal coding style. I don't know, maybe there are people out > there > who routinely cast things to `(const const const const int)` and believe > that it > helps them to, you know, "drive the point across". But all these variants > will > still be immeditaly reduced by the compiler to a simple cast to `(int)`. > All > top-level const-qualifiers in a cast are immediately discarded by the > compiler. > For this reason, majority of competent C programmers will probably prefer > to > implement the above [contrived] example as > > int main(void) { > const int a = (int) 3.14; > } > > Note that we do keep the `const` in the variable declaration, it is not > redundant > there. But we omit the `const` from the cast. > > This mirrors your original example: keep the top-level `const` in your > parameter > declaration, nobody's objecting that. But there's just no point in keeping > the > top-level `const` in the explicit cast. > > That's the point I was making. Nobody's trying to attack your "const > invariance" in > your parameter declaration. It was about the _cast_ and only about the > _cast_. > > -- > Best regards, > Andrey >
