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
<http://wg21.link/p1389#typesconst-constness>)

2.2.2. [types.const] Constness
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1389r0.html#typesconst-constness>
2.2.2.1. [types.const.constexpr] Encourage constexpr values whenever it is
possible
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1389r0.html#typesconstconstexpr-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
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1389r0.html#typesconstconst-encourage-const-whenever-you-cant-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_at_[hidden]>
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_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg20
>