Date: Wed, 9 Jun 2021 15:07:43 -0400
On Wed, Jun 9, 2021 at 12:31 PM Gennaro Prota via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> On Wed, Jun 9, 2021, 18:18 Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>>
>> On Wed, 9 Jun 2021 at 19:11, Gennaro Prota <gennaro.prota_at_[hidden]> wrote:
>>
>> > Oh. My. God. That the committee has serious process problems was already clear, but this is really too much.
>>
>> Too much for whom? You? Why does that matter? The implementation
>> vendors have no problem with any of this.
>
>
> The depressing part is that you don't see the problem with it, and don't know of better ways to handle the issue. Get a course on version control. Sorry, I won't reply any further, because this is just ridiculous. And since I already accused someone else, it will end up with me appearing as a troll rather than you as incompetent.
Or you could just say what the problem is:
C++ *users* need to know what a particular version of the language is
just as much as C++ implementers. But the current way defect fixes are
handled makes that difficult, *especially* for fixes that materially
affect what is and is not legal code.
The standard defines what the language is. While it is meant for
implementers, it also has to be used by users who want to know what
the current language is so that they can correctly write code against
it. Material changes to the language after standard publication makes
that difficult, if those changes are not suitably centralized.
The primary issue here is that there are a significant number of
*user-facing* defect fixes against C++20 that were accepted, but
without an easy way for a user to know what they are. This now creates
a two-tier system: people who know how to comb through the language
standard/defect fixes/etc to assemble a clear picture of what the
language is, and people who think that C++20 is what the published
C++20 standard is.
Again, these things normally aren't an issue as defect fixes
historically have been fairly small things. But quite a few of these
C++20 ones are significant "this API now has these overloads" changes
that every C++ user needs to know to write working code.
<std-discussion_at_[hidden]> wrote:
>
> On Wed, Jun 9, 2021, 18:18 Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
>>
>> On Wed, 9 Jun 2021 at 19:11, Gennaro Prota <gennaro.prota_at_[hidden]> wrote:
>>
>> > Oh. My. God. That the committee has serious process problems was already clear, but this is really too much.
>>
>> Too much for whom? You? Why does that matter? The implementation
>> vendors have no problem with any of this.
>
>
> The depressing part is that you don't see the problem with it, and don't know of better ways to handle the issue. Get a course on version control. Sorry, I won't reply any further, because this is just ridiculous. And since I already accused someone else, it will end up with me appearing as a troll rather than you as incompetent.
Or you could just say what the problem is:
C++ *users* need to know what a particular version of the language is
just as much as C++ implementers. But the current way defect fixes are
handled makes that difficult, *especially* for fixes that materially
affect what is and is not legal code.
The standard defines what the language is. While it is meant for
implementers, it also has to be used by users who want to know what
the current language is so that they can correctly write code against
it. Material changes to the language after standard publication makes
that difficult, if those changes are not suitably centralized.
The primary issue here is that there are a significant number of
*user-facing* defect fixes against C++20 that were accepted, but
without an easy way for a user to know what they are. This now creates
a two-tier system: people who know how to comb through the language
standard/defect fixes/etc to assemble a clear picture of what the
language is, and people who think that C++20 is what the published
C++20 standard is.
Again, these things normally aren't an issue as defect fixes
historically have been fairly small things. But quite a few of these
C++20 ones are significant "this API now has these overloads" changes
that every C++ user needs to know to write working code.
Received on 2021-06-09 14:07:56