Date: Wed, 19 Jun 2019 12:43:30 +0300
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
>
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
>
Received on 2019-06-19 04:45:39