Date: Mon, 23 Nov 2020 07:04:07 +0200
On Mon, 23 Nov 2020 at 04:01, Arthur O'Dwyer via SG20
<sg20_at_[hidden]> wrote:
> `constinit` is simple and regular:
> constinit int x = foo();
> means no more and no less than
> int x = foo();
> with the additional information that the initialization must happen at compile-time, not at runtime. In a perfect world, it would have been an attribute, since it has no effect on the type system. (But we're hung up on the ignorable attributes rule.)
It's not a question of being hung up on a rule. A C++17 implementation
would parse and ignore the attribute,
producing an incorrect program. It's a keyword in order to make sure
that it's not ignored by an implementation
that doesn't recognize it, and that's not a result of being "hung up",
it's a result of what the language was before
C++20, and changing that is not something that we could just do with a
DR, because implementations have already
shipped.
But hey, if your "perfect world" includes having to do a language
version (and possibly an implementation version,
because surreptitious(*) bugs) check whenever using a language facility,
then by all means, propose such a perfect world. Otherwise, I
recommend communicating the reasons for
choosing a keyword rather than an attribute correctly. C++ has enough
teaching material that has such
correctness problems, and I doubt whether that's exactly productive.
(*) bugs in different meanings of (unrecognized) attributes are
already surreptitious, based on what we've
seen in the wild; a bug in recognizing a new keyword is unlikely to be
surreptitious, based on how most
of our parsers work.
<sg20_at_[hidden]> wrote:
> `constinit` is simple and regular:
> constinit int x = foo();
> means no more and no less than
> int x = foo();
> with the additional information that the initialization must happen at compile-time, not at runtime. In a perfect world, it would have been an attribute, since it has no effect on the type system. (But we're hung up on the ignorable attributes rule.)
It's not a question of being hung up on a rule. A C++17 implementation
would parse and ignore the attribute,
producing an incorrect program. It's a keyword in order to make sure
that it's not ignored by an implementation
that doesn't recognize it, and that's not a result of being "hung up",
it's a result of what the language was before
C++20, and changing that is not something that we could just do with a
DR, because implementations have already
shipped.
But hey, if your "perfect world" includes having to do a language
version (and possibly an implementation version,
because surreptitious(*) bugs) check whenever using a language facility,
then by all means, propose such a perfect world. Otherwise, I
recommend communicating the reasons for
choosing a keyword rather than an attribute correctly. C++ has enough
teaching material that has such
correctness problems, and I doubt whether that's exactly productive.
(*) bugs in different meanings of (unrecognized) attributes are
already surreptitious, based on what we've
seen in the wild; a bug in recognizing a new keyword is unlikely to be
surreptitious, based on how most
of our parsers work.
Received on 2020-11-22 23:04:20