Hi,

First, this is an excellent topic and I hope for a good discussion to follow. Thanks for bringing it up here!

Here is my perspective:

`const`, both for objects and functions, is pretty easy to teach and understand.
It's mainly about asking the compiler "don't let me change this object (or change `*this` object, in case of a function).
When the initialization of the object is done? Usually, the beginner student doesn't care at all.

`constinit` is for making sure the (non-`constexpr`) object is statically initialized, to make sure it doesn't vulnerable to "static initialization order fiasco".
This is again something that I wouldn't expect a beginner, or even the average, programmer to care about.
In most cases, we recommend different design patterns or different programming techniques to avoid the counting an static initiation in first place.
Seems to me like this is relevant only for specific environments (embedded?) or advanced optimization usages.

`is_constant_evaluated` is relevant when we want to implement the same function in two different ways depending on the evaluation time.
This is again an advanced optimization technique and most programmers will never need it.

`consteval` is for compile-time-only functions. Again something that is probably less useful in usual code.
The main motivation is reflection, so let's wait for more reflection tools to be available before we decide if it has common use-cases.

Last, but not least, is `constexpr`.
This one is more useful in common code and there is more to talk about it than a short sentence but this email is already too long.
For now, I'd like to quote what our teaching guidelines (draft) document has to say about the topic: (link)

2.2.2. [types.const] Constness

2.2.2.1. [types.const.constexpr] Encourage constexpr values whenever it is possible

constexpr is a good way to ensure that values remain constant, and variables that are constexpr are constant expressions*.

As a general rule, default to constexpr unless something can only be known at run-time. vector and string always require run-time knowledge, so they cannot be const.

*Recommending constexpr does not mean explaining what a constant expression is. This is a separate discussion. For now, we can say "known at compile time".

2.2.2.2. [types.const.const] Encourage const whenever you can’t use constexpr

const lets us reason about our programs with security and helps us produce more declarative code. Rather than suggesting that const is applied when you know that a value won’t (or can’t) change, offer const as the default, and suggest students remove const when they encounter a reason to mutate the variable.

Editor’s note: [types.const.const] does not suggest introducing lambda-initialisation (IILE).

Editor’s note: [types.const.const] becomes more and more easy-to-use when ranges are incorporated into a program.



On Tue, Jun 18, 2019 at 9:47 AM Tomas p via SG20 <sg20@lists.isocpp.org> wrote:
Hi,

this post is inspired by a presentation of one committee member posted recently on reddit.
https://www.reddit.com/r/cpp/comments/c06908/cnow_2019_daveed_vandevoorde_c_constants/

I have no doubts there is a lot of good thoughts and engineering behind the works. But this group should discuss suitability for teaching or approaching students and other c++ programmers. I would say discussing new proposals from teach-ability perspective should be one of the most important things for this group. It's arguably more important than new guidelines and material - that can be done any time and people do it already - but once a new complicated or difficult to teach feature is included in the standard there is no way to remove it and so we should better get it right.

So I have a question. Do you really think constant variables/functions/initialization is going in the right direction? Most c++ programmers I know are using only pre-c++11 const keyword. Few understand constexpr variables and functions. How many of them do you think will be using new keywords in this area - consteval, constinit, is_constant_evaluated when it becomes available? Doesn't this work solve niche problem? Do you think so many new keywords for constant initialization will not be a burden to newcomers and average c++ programmers?

I am really interested in what this group thinks of it.
--
SG20 mailing list
SG20@lists.isocpp.org
http://lists.isocpp.org/mailman/listinfo.cgi/sg20