On Wed, 19 Jun 2019 at 10:43, Yehezkel Bernat via SG20 <
sg20_at_[hidden]> wrote:

>
> On Wed, Jun 19, 2019 at 11:17 AM Tomas p via SG20 <sg20_at_[hidden]>
> wrote:
>
>> Thanks for your comments on this subject. The biggest issue I have here
>> is that there are already too many C++ keywords allocated just for this
>> topic. I don't feel anything wrong with is_constant_evaluated since that
>> is a function and so similarly to other functions it can be ignored unless
>> needed.
>>
>> But to allocate a new C++ keyword that should be only for something
>> fundamental. For example in many programming books and courses list of
>> keywords is something presented very early. It is something even average
>> programmers are expected to know and understand. But these new keywords
>> (consteval, constinit) are not.
>>
>
> Well, I don't agree with the approach of showing a list of keywords to the
> students. Probably not in any phase. Maybe in the very advanced one, when
> they already know most of the keywords anyway.
> Similarly, our guidelines document recommend presenting only a small
> subset of C++ types to the beginner. Again, I know that some teachers just
> throw a table full of types on the confused student. Seems like here, as a
> group, we think this is the wrong approach.
>

+1
I would encourage newer books and classes to introduce keywords as they
become necessary. There's no need to spam students with a bunch of words
that have no place in a relevant class. For example, I'd like to see
reinterpret_cast, const_cast, and union no longer show up in introductory
material. Not mentioning consteval and co there is also a good idea.


>
>
>
>> Everybody wants a reflection facilities in the language but to me that's
>> not enough of a reason to include consteval in the keywords list. I have
>> never heard of someone complaining of missing consteval functionality. So
>> for that reason these functions could be made special by other means (they
>> are built in). And it's okay without this keyword user won't be able to
>> create similar facility on his own because there was never a need for that.
>>
>
It seems as though we move in different circles. I've seen non-committee
developers express excitement for the opportunities these keywords offer.
My own emulation of contracts would greatly benefit from both consteval and
is_constant_evaluated.


>
> As I mentioned in the previous message, we probably have to read better
> the relevant proposals to understand why it's needed, but I believe the
> `consteval` paper when it claims that it was requested by reflection group.
> If everybody wants reflection, they have to accept that some steps are
> needed to get to this target :)
>
>
>
>> As for constinit it seems that it solves a niche area problem. As you are
>> saying it's meant for constant initialization which is not constexpr.
>> Probably used in some embedded area software. Well C++ is used by so many
>> industries but even if we say this particular usage in embedded is
>> important from my experience C++ standard adoption in embedded is always
>> far behind. Currently they are catching on C++11. Does it really make sense
>> to allocate new keyword then? I wish there could be an attribute for this
>> purpose something along [[no_unique_address]].
>>
>
I believe the decision to make consteval and constinit keywords over
attributes was because a program should be able to compile as if the
attribute wasn't present, and these new keywords would break this.

Eric Fiselier talks about this on CppCast.
<http://cppcast.com/2019/01/eric-fiselier/>


>
> 1. Please note, embedded was mentioned just as a wild guess of mine. It
> isn't mentioned in the rational of the paper or something like this. Maybe
> there are enough use-cases that I'm not aware of.
> 2. Adoption of C++ in embedded is getting better. See Odin Holmes talks,
> for example. But this isn't the point here anyway.
> 3. It's interesting note that the original paper actually suggested it as
> an attribute. It was in the discussions of the first revision that the
> decision was made to "promote" it to a real keyword.
> See http://wg21.link/p1143r0 (the original proposal) and
> http://wg21.link/p1143r1 (especially the Previous Discussions section).
>
>
>
>> Seeing keyword explosion of keywords only for constant initialization
>> definitely contributes to a feeling that C++ is expert only language. I
>> wish it would get more thinking in the committee before it's cast in stone.
>> I feel like although there are numerous papers from B.Stroustrup and others
>> about getting more focus on novice and average programmers in the end it
>> always goes the opposite direction. Keeping the core language additions
>> minimal is important goal at this point imho.
>>
>
> Again, I can't share your feeling here, sorry. I think it's wrong to
> expect everyone to know and understand all the keywords, especially as a
> beginner.
> Wait a minute, I don't expect them to know even all the operators!
> Does anyone think it's wise to teach beginners (or even intermediate
> students) operators like `.*` and `->*`? (BTW, I had to look them up in
> cppreference to make sure I write them correctly. :) )
> (BTW, if beginners should know all the keywords, why shouldn't they know
> all the standard attributes? I think they should learn pretty early about
> `[[fallthrough]]` attribute, for example.
> So making it an attribute wouldn't help there anyway.)
>

+10


>
> For the general question about adding new things to the standard:
> The points that Stroustrup and others are making about making the language
> more approachable aren't against adding things to the language, but about
> adding things that will make it easier to teach and safer to use. And this
> continuously happening. For example, adding std::ranges complicates the
> library very much, it's a huge new library (people used to call it STL2).
> But hopefully, at some point we'll be able to teach only the usage of this
> library, almost forgetting about the old way to write thing, unless you
> have to maintain a very old legacy code.
> Herb Sutter has a repeating theme in his talks over the last few years
> about how adding things to the language makes it simpler. I really
> recommend watching those talks if someone hadn't a chance for it before.
>
> The whole point of the teaching guidelines we are writing is that we
> believe that students don't have to learn all the language, definitely not
> at once, and we try to find the right subset that is useful and can be
> taught gradually.
>
>
>
>> On Tue, Jun 18, 2019 at 6:07 PM chuck.allison via SG20 <
>> sg20_at_[hidden]> wrote:
>>
>>> Well said, Tomas. I think const is sufficient in most instances for
>>> newcomers, with constexpr presented as needed. Going beyond this can be
>>> overwhelming and contribute to the belief that C++ is an experts-only
>>> language. Concepts should presented when they can be understood.
>>>
>>> Much of C++ exists to support implementers of systems and libraries.
>>> Such people are not newcomers to programming, and usually not newcomers to
>>> C++.
>>>
>>> Chuck
>>>
>>>
>>>
>>> Sent from my Samsung Galaxy smartphone.
>>>
>>> -------- Original message --------
>>> From: Tomas p via SG20 <sg20_at_[hidden]>
>>> Date: 6/18/19 12:47 AM (GMT-07:00)
>>> To: sg20_at_[hidden]
>>> Cc: Tomas p <pecholt_at_[hidden]>
>>> Subject: [SG20] Constant initialization in C++20
>>>
>>> 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?
>>>
>>
Yes, I do think this is the right direction, so that non-experts have
stronger library capabilities.


> Most c++ programmers I know are using only pre-c++11 const keyword. Few
>>> understand constexpr variables and functions.
>>>
>>
This can be due to many factors, including sample size, when the
programmers you know learnt C++, when they last refreshed their knowledge,
which standard they are building against, and whether or not they
understand the differences between the two. For example, I worked with a
team that were stuck on GCC 4.4 (in 2017!), and so they were tied to C++03,
hence the best that they could use is const. When they to move to GCC 4.9
and can turn on C++11, I imagine that there will be a lot of using old
features out of habit.


> 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.
>>>
>>
I foresee constinit being used in intermediate classes. There are
situations where one can guarantee constant initialisation, but nothing
else.

consteval and is_constant_evaluated are advanced or even expert features,
but are nonetheless important for library developers to make high-quality
production libraries. I can also foresee them being used to partially
emulate new language features. These *do not* need to be introduced into
beginner or intermediate classes, and can be left until specialist library
dev classes IMO.

Chris


> --
>>> SG20 mailing list
>>> SG20_at_[hidden]
>>> http://lists.isocpp.org/mailman/listinfo.cgi/sg20
>>>
>> --
>> SG20 mailing list
>> SG20_at_[hidden]
>> http://lists.isocpp.org/mailman/listinfo.cgi/sg20
>>
> --
> SG20 mailing list
> SG20_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg20
>

On Wed, 19 Jun 2019 at 10:43, Yehezkel Bernat via SG20 <
sg20_at_[hidden]> wrote:

>
> On Wed, Jun 19, 2019 at 11:17 AM Tomas p via SG20 <sg20_at_[hidden]>
> wrote:
>
>> Thanks for your comments on this subject. The biggest issue I have here
>> is that there are already too many C++ keywords allocated just for this
>> topic. I don't feel anything wrong with is_constant_evaluated since that
>> is a function and so similarly to other functions it can be ignored unless
>> needed.
>>
>> But to allocate a new C++ keyword that should be only for something
>> fundamental. For example in many programming books and courses list of
>> keywords is something presented very early. It is something even average
>> programmers are expected to know and understand. But these new keywords
>> (consteval, constinit) are not.
>>
>
> Well, I don't agree with the approach of showing a list of keywords to the
> students. Probably not in any phase. Maybe in the very advanced one, when
> they already know most of the keywords anyway.
> Similarly, our guidelines document recommend presenting only a small
> subset of C++ types to the beginner. Again, I know that some teachers just
> throw a table full of types on the confused student. Seems like here, as a
> group, we think this is the wrong approach.
>
>
>
>> Everybody wants a reflection facilities in the language but to me that's
>> not enough of a reason to include consteval in the keywords list. I have
>> never heard of someone complaining of missing consteval functionality. So
>> for that reason these functions could be made special by other means (they
>> are built in). And it's okay without this keyword user won't be able to
>> create similar facility on his own because there was never a need for that.
>>
>
> As I mentioned in the previous message, we probably have to read better
> the relevant proposals to understand why it's needed, but I believe the
> `consteval` paper when it claims that it was requested by reflection group.
> If everybody wants reflection, they have to accept that some steps are
> needed to get to this target :)
>
>
>
>> As for constinit it seems that it solves a niche area problem. As you are
>> saying it's meant for constant initialization which is not constexpr.
>> Probably used in some embedded area software. Well C++ is used by so many
>> industries but even if we say this particular usage in embedded is
>> important from my experience C++ standard adoption in embedded is always
>> far behind. Currently they are catching on C++11. Does it really make sense
>> to allocate new keyword then? I wish there could be an attribute for this
>> purpose something along [[no_unique_address]].
>>
>
> 1. Please note, embedded was mentioned just as a wild guess of mine. It
> isn't mentioned in the rational of the paper or something like this. Maybe
> there are enough use-cases that I'm not aware of.
> 2. Adoption of C++ in embedded is getting better. See Odin Holmes talks,
> for example. But this isn't the point here anyway.
> 3. It's interesting note that the original paper actually suggested it as
> an attribute. It was in the discussions of the first revision that the
> decision was made to "promote" it to a real keyword.
> See http://wg21.link/p1143r0 (the original proposal) and
> http://wg21.link/p1143r1 (especially the Previous Discussions section).
>
>
>
>> Seeing keyword explosion of keywords only for constant initialization
>> definitely contributes to a feeling that C++ is expert only language. I
>> wish it would get more thinking in the committee before it's cast in stone.
>> I feel like although there are numerous papers from B.Stroustrup and others
>> about getting more focus on novice and average programmers in the end it
>> always goes the opposite direction. Keeping the core language additions
>> minimal is important goal at this point imho.
>>
>
> Again, I can't share your feeling here, sorry. I think it's wrong to
> expect everyone to know and understand all the keywords, especially as a
> beginner.
> Wait a minute, I don't expect them to know even all the operators!
> Does anyone think it's wise to teach beginners (or even intermediate
> students) operators like `.*` and `->*`? (BTW, I had to look them up in
> cppreference to make sure I write them correctly. :) )
> (BTW, if beginners should know all the keywords, why shouldn't they know
> all the standard attributes? I think they should learn pretty early about
> `[[fallthrough]]` attribute, for example.
> So making it an attribute wouldn't help there anyway.)
>
> For the general question about adding new things to the standard:
> The points that Stroustrup and others are making about making the language
> more approachable aren't against adding things to the language, but about
> adding things that will make it easier to teach and safer to use. And this
> continuously happening. For example, adding std::ranges complicates the
> library very much, it's a huge new library (people used to call it STL2).
> But hopefully, at some point we'll be able to teach only the usage of this
> library, almost forgetting about the old way to write thing, unless you
> have to maintain a very old legacy code.
> Herb Sutter has a repeating theme in his talks over the last few years
> about how adding things to the language makes it simpler. I really
> recommend watching those talks if someone hadn't a chance for it before.
>
> The whole point of the teaching guidelines we are writing is that we
> believe that students don't have to learn all the language, definitely not
> at once, and we try to find the right subset that is useful and can be
> taught gradually.
>
>
>
>> On Tue, Jun 18, 2019 at 6:07 PM chuck.allison via SG20 <
>> sg20_at_[hidden]> wrote:
>>
>>> Well said, Tomas. I think const is sufficient in most instances for
>>> newcomers, with constexpr presented as needed. Going beyond this can be
>>> overwhelming and contribute to the belief that C++ is an experts-only
>>> language. Concepts should presented when they can be understood.
>>>
>>> Much of C++ exists to support implementers of systems and libraries.
>>> Such people are not newcomers to programming, and usually not newcomers to
>>> C++.
>>>
>>> Chuck
>>>
>>>
>>>
>>> Sent from my Samsung Galaxy smartphone.
>>>
>>> -------- Original message --------
>>> From: Tomas p via SG20 <sg20_at_[hidden]>
>>> Date: 6/18/19 12:47 AM (GMT-07:00)
>>> To: sg20_at_[hidden]
>>> Cc: Tomas p <pecholt_at_[hidden]>
>>> Subject: [SG20] Constant initialization in C++20
>>>
>>> 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
>>>
>> --
>> SG20 mailing list
>> SG20_at_[hidden]
>> http://lists.isocpp.org/mailman/listinfo.cgi/sg20
>>
> --
> SG20 mailing list
> SG20_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg20
>