Should DRs be considered applied retroactively to then-current standard?

[Sergey Zubkov]

Hello, std-discussion

This question is due to an ongoing effort to shift the way DR resolutions are documented on cppreference.com.

At first, cppreference tagged behavior-changing DRs with the first published standard they appear in. For example, the wording introduced by CWG 1301 was tagged C++14, leading to multiple discussions about value-initialization in C++11 on Stackoverflow and elsewhere since this disagreed with compilers: my reasoning was that an implementation of the defective C++11 wording could have possibly existed and claimed to fully support C++11. After multiple discussions on StackOverflow as well as occasional clang and gcc bugzillas, it appears that the vendors (at least commonly discussed vendors) treat defect reports as applied retroactively to the standard revision that was in force when the DR resolution was accepted (and sometimes even ahead of the vote, as gcc did with LWG 2048.). In fact, gcc documents their -std=c++11 and -std=c++14 modes as "standard plus amendments"

CWG issues appear to fit this model well: new core functionality appears to come in n-numbered proposals and cwg-defects also has a clear label "Moved to DR", distinct from "Voted into WP",

LWG issues however aren't so clearly marked, and have in fact been used to implement new functionality, such as LWG 2285's make_reverse_iterator.

The specific question that brings the discussion here is the status of LWG 630 which changed the behavior of valarray::operator= between C++03 and C++11 (discussed on SO). Is it appropriate to say that it amended the wording of C++03? Or is it a new C++11 feature? Should this reasoning be applied to all defect reports?

[Ville Voutilainen]

It is usually safe to assume that a DR applies to the previously
released standard.
Sometimes it applies to earlier ones as well, in which case the
designation is sometimes
not quite clear. I don't know how to characterize LWG 630.

[Alisdair Meredith]

The library working group has not traditionally used the DR resolution, applying issues only to succeeding standards.  There have been some muted suggestions that they might pick up this practice from Core, but I am not aware of any such resolutions yet.

Often, an issue is a clarification or resolves a contradiction.  In those cases, it is often possible for a library to apply an issue to an older standard while still conforming, or at least, being no more broken.  However, there is currently no requirement to do so.

AlisdairM

Sent from my iPad

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussio...@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/.

[Richard Smith]

On Fri, Aug 7, 2015 at 4:39 PM, Alisdair Meredith <alis...@me.com> wrote:

The library working group has not traditionally used the DR resolution, applying issues only to succeeding standards.  There have been some muted suggestions that they might pick up this practice from Core, but I am not aware of any such resolutions yet.

Often, an issue is a clarification or resolves a contradiction.  In those cases, it is often possible for a library to apply an issue to an older standard while still conforming, or at least, being no more broken.  However, there is currently no requirement to do so.

The LWG issues list's description of the various issue statuses says:

"C++11 - (C++ Standard, as revised for 2011) - The full WG21/PL22.16 committee has voted to accept the Defect Report's Proposed Resolution into the published 2011 revision to the C++ standard, ISO/IEC IS 14882:2011(E)."

... which could be read as implying that issues with status C++11 are DRs. (In the core issues list, issues with status C++11 are explicitly marked as being DRs: "C++11: A DR issue not resolved in CD2 but included in ISO/IEC 14882:2011.")

As the intent of the library issues list is that most of the issues are not to be treated as DRs, it'd probably be helpful to change the definition of the various statuses to use a word like "issue" instead of "Defect Report".

[Ville Voutilainen]

On 8 August 2015 at 02:52, Richard Smith <ric...@metafoo.co.uk> wrote:
> On Fri, Aug 7, 2015 at 4:39 PM, Alisdair Meredith <alis...@me.com> wrote:
>>
>> The library working group has not traditionally used the DR resolution,
>> applying issues only to succeeding standards. There have been some muted
>> suggestions that they might pick up this practice from Core, but I am not
>> aware of any such resolutions yet.
>>
>> Often, an issue is a clarification or resolves a contradiction. In those
>> cases, it is often possible for a library to apply an issue to an older
>> standard while still conforming, or at least, being no more broken.
>> However, there is currently no requirement to do so.
>
>
> The LWG issues list's description of the various issue statuses says:
>
> "C++11 - (C++ Standard, as revised for 2011) - The full WG21/PL22.16
> committee has voted to accept the Defect Report's Proposed Resolution into
> the published 2011 revision to the C++ standard, ISO/IEC IS 14882:2011(E)."
>
> ... which could be read as implying that issues with status C++11 are DRs.
> (In the core issues list, issues with status C++11 are explicitly marked as
> being DRs: "C++11: A DR issue not resolved in CD2 but included in ISO/IEC
> 14882:2011.")
>
> As the intent of the library issues list is that most of the issues are not
> to be treated as DRs, it'd probably be helpful to change the definition of
> the various statuses to use a word like "issue" instead of "Defect Report".

For what it's worth, we have papers such as

N4387 Improving pair and tuple, revision 3
N4089 Safe conversions in unique_ptr<T[]>
N4366 LWG 2228: Missing SFINAE rule in unique_ptr templated assignment

that are designated as C++17 papers in libstdc++ status page, but I
have implemented
them as applying to C++11 as well, and even though they are not yet committed,
I certainly plan to commit them as C++11 fixes, even though the guidance
from LWG is not entirely clear with regards to how they should be applied.

Some of the issues in N4387 certainly were intended to be C++11 fixes by
the issue submitter. I see no reason to apply any of those papers into
C++17 only.

[Jonathan Wakely]

On Saturday, 8 August 2015 09:57:03 UTC+1, Ville Voutilainen wrote:

For what it's worth, we have papers such as

N4387 Improving pair and tuple, revision 3
N4089 Safe conversions in unique_ptr<T[]>
N4366 LWG 2228: Missing SFINAE rule in unique_ptr templated assignment

that are designated as C++17 papers in libstdc++ status page, but I
have implemented
them as applying to C++11 as well, and even though they are not yet committed,
I certainly plan to commit them as C++11 fixes, even though the guidance
from LWG is not entirely clear with regards to how they should be applied.

They're documented in the C++17 status table because they're N-numbered papers, but a better place to document the would probably be https://gcc.gnu.org/onlinedocs/libstdc++/manual/bugs.html#manual.intro.status.bugs.iso where we list issue resolutions implemented in the library, whether they are official DRs or not.

Some of the issues in N4387 certainly were intended to be C++11 fixes by
the issue submitter. I see no reason to apply any of those papers into
C++17 only.

Agreed.

[Marshall Clow]

On Fri, Aug 7, 2015 at 4:39 PM, Alisdair Meredith <alis...@me.com> wrote:

The library working group has not traditionally used the DR resolution, applying issues only to succeeding standards.  There have been some muted suggestions that they might pick up this practice from Core, but I am not aware of any such resolutions yet.

Often, an issue is a clarification or resolves a contradiction.  In those cases, it is often possible for a library to apply an issue to an older standard while still conforming, or at least, being no more broken.  However, there is currently no requirement to do so.

The general policy of libc++ is that issues are resolved w/o concern for the language level, but new features are constrained to the "next standard".

That's the general policy; there have been (and will be) exceptions.

--- Marshall

 

[FrankHB1989]

As a user, I don't like the policy to apply most of these changes to old mode (-std=c++xx) of the implementations, since it is difficult to test and work around the probable different behavior for many versions of the implementation I used. The list of issues is too subtle and not clear to most people, even the language (but not, necessarily, standardization) experts.


This is more annoying for core issues, because the users usually cannot work around them easily as the library implementation, e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890. Though it comes to be not a bug eventually as per the "plus amendments" wording, I cannot easily found the list of these amendments and figure out which sets of versions are effected (and expect how they behave). I can ensure the steady behavior on possible code+implementation combinations only if I read all the related implementation issues lists (at least bugzilla issues for GCC) or even the source of implementations, otherwise I can never make sure *which difference can show a bug of the implementation* even I have read *all the published standards and issues*. (In fact, I personally do something like that, i.e. https://bitbucket.org/FrankHB/yslib/wiki/StandardUsing.en-US.md, but that is not viable for most projects in reality.) Since there are no totally bug-free implementations, that's absurd.

[Nemo Capt]

Things always change.

void foo1(void) {}

void foo2(void) {}

int main(void) { foo1(foo2()); return 1; }

On Mon, Aug 17, 2015 at 10:29 AM, FrankHB1989 <frank...@gmail.com> wrote:

As a user, I don't like the policy to apply most of these changes to old mode (-std=c++xx) of the implementations, since it is difficult to test and work around the probable different behavior for many versions of the implementation I used. The list of issues is too subtle and not clear to most people, even the language (but not, necessarily, standardization) experts.


This is more annoying for core issues, because the users usually cannot work around them easily as the library implementation, e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890. Though it comes to be not a bug eventually as per the "plus amendments" wording, I cannot easily found the list of these amendments and figure out which sets of versions are effected (and expect how they behave). I can ensure the steady behavior on possible code+implementation combinations only if I read all the related implementation issues lists (at least bugzilla issues for GCC) or even the source of implementations, otherwise I can never make sure *which difference can show a bug of the implementation* even I have read *all the published standards and issues*. (In fact, I personally do something like that, i.e. https://bitbucket.org/FrankHB/yslib/wiki/StandardUsing.en-US.md, but that is not viable for most projects in reality.) Since there are no totally bug-free implementations, that's absurd.

[FrankHB1989]

在 2015年8月17日星期一 UTC+8下午1:34:59，math0写道：

The key is, whether I can expect what have been changed, by spec rather than by implementations.
I can find the amendment for the latest spec in the working draft. However, I cannot find one elsewhere for old standards.

[math0]

so do you think we need a lite version of cpp?

[math0]

can you show how do the spec impact on your projects?

[FrankHB1989]

在 2015年8月18日星期二 UTC+8下午12:21:04，math0写道：

No. One up-to-date edition is sufficient (to most users).
 

[FrankHB1989]

在 2015年8月18日星期二 UTC+8下午12:24:54，math0写道：

Nothing can't be resolved in theory (eventually), more work to do in reality.
I have no problems to read all these issues and find ways to fix/work around them, except time. For hobby projects without deadline, that does not matter much. However, this also means, due to the feasibility(cost), the standard is not as important/useful to help the programs being portable in more serious projects as it ought to be. This is certainly not a good sign.

[math0]

I cannot agree with you. Advancing is more important than repairing for cpp. No one will use cpp if it stops there, just fixing around some bugs, issues, undefined behaviors, that's not C plus plus language but C language. In my opinion Cpp is always new, extremely new. If you want a stable one, you can choose C language, or create a new language named Stable Cpp or Cpp Lite or something else. I am looking forward for new features like RTTI support and, fixing those issues, is just what compiler producer did. 

[FrankHB1989]

在 2015年8月19日星期三 UTC+8下午2:54:43，math0写道：

Then why not just use the latest standard + DRs?
When old ones are used, compatibility should always be concerned.

[FrankHB1989]

在 2015年8月19日星期三 UTC+8下午2:54:43，math0写道：

I cannot agree with you. Advancing is more important than repairing for cpp. No one will use cpp if it stops there, just fixing around some bugs, issues, undefined behaviors, that's not C plus plus language but C language. In my opinion Cpp is always new, extremely new. If you want a stable one, you can choose C language, or create a new language named Stable Cpp or Cpp Lite or something else. I am looking forward for new features like RTTI support and, fixing those issues, is just what compiler producer did. 

And just as C, C++ would (always) be used. There have been too many C++ projects that cannot be rewritten easily. Sadly, most of them are written in C++ 98. Many of them are substandard and they even may need bug-to-bug compatibility (e.g. MSVC6 specific)...
If no one will use them, I'd be relaxed.
 

[math0]

But I do not think we should use MSVC6 next since, you know, we do not fix an antique as usual. But, in fact, many people use old standard, I know, and the same problem happened in other program languages, not only cpp. It is sad talking about this......We usually call it "the legacy" to describe some programs made from several years ago.

I think the true problem is "undefined behavior" like something happens in macro definition (B.J. wrote an article for it but I cannot paste the link at once).

But I still love to talk with you about some old programs because it is rare for me to work with some "antiques".

[FrankHB1989]

在 2015年8月21日星期五 UTC+8下午12:43:49，math0写道：

Yes. MSVC6 should not be here any longer. (Sigh... there are still VC8/VC9...) And no, things are not so easy here. Even newest versions of VC++ can make problems of portability, e.g. it still does not support 2-phase name lookup (which should be there since C++98) as 2015; VC++ 2013 would ignore some 'enable_if' on constructor templates and cause infinite recursive calls of copy constructor in the generated code. What standard do they conform to? Totally a mess. There are even no sufficient macros to test these features reliably ...

This problem is certainly not related to the standard itself, but it is the fact nowadays. Please keep it simple.

[math0]

MSVC always has bugs. See the link below.

https://stackoverflow.com/questions/31711356/visual-studio-2015-using-a-lambda-in-constexpr

The latest MSVC 2015 also fails in expression SFINAE in some situations. I am angry with MSVC. I think though enable_if is a good feature but it is also a little difficult for compiler to support enable_if totally(many people discuss about it). I do not use enble_if for its ugly form, and I often use expression SFINAE, or some nesting classes instead.

[FrankHB1989]

在 2015年8月21日星期五 UTC+8下午8:53:25，math0写道：

 Yes. Regardless of the effort of MS people, as a fact, the compiler of VC++ is always contemporarily poor.
VC++ 2015 even does not accept this: static_assert(std::is_void<void>(), "");, due to obviously compiler bug, despite Mr. STL proudly announced they have support constexpr for std::integral_types ...
So... I avoid to use it as I can. But there are still some project cannot be easily migrated to MinGW, and anyway, VS has some other awesome tools depending on the toolchain.