Template talk:dr list begin

Which standard(s) is a defect report applied to exactly?

I.e. given any mentioned defect report, is it applied to the revision of the standard specified in the "Applied to" column or to all revisions of the standard published so far? I.o.w. if I direct my compiler to adhere to an earlier revision of the standard, should I expect the result to be as if the defect didn't exist at all? — Radix (talk) 14:45, 15 April 2020 (PDT)

I think a defect report should be applied to the revision in which its related features are introduced. Some CWG DRs are described as applied to C++14 now but they should be applied to C++98 or C++11 IMO. --Fruderica (talk) 11:13, 24 May 2020 (PDT)

---

Experimenting with wiki-media tables style

This is DR format that cppreference uses now (below is an artificial example):

Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

DR	Applied to	Behavior as published	Correct behavior
P0136R1	C++11	inheriting constructor declaration injects additional constructors in the derived class	causes base class constructors to be found by name lookup

This is what would be more preferable, IMO (only a basis, any link stuff etc. is omitted). Main motivation is to enforce auto hyphenation of long sentences to enable auto splitting of long sentences on white-spaces in Behavior and Correct behavior columns.

DR	Applied to	Behavior as published	Correct behavior
LWG 2901	C++17	allocator-aware constructors provided but variant can't properly support	allocators constructors removed
P0608R3	C++17	converting constructor blindly assembles an overload set, leading to unintended conversions	narrowing and boolean conversions not considered
P0136R1	C++11	inheriting constructor declaration injects additional constructors in the derived class	causes base class constructors to be found by name lookup

TEST #2

Defect reports

DR	Applied to	Behavior as published	Correct behavior
LWG 2901	C++17	allocator-aware constructors provided but variant can't properly support	allocators constructors removed
P0608R3	C++17	converting constructor blindly assembles an overload set, leading to unintended conversions	narrowing and boolean conversions not considered
P0136R1	C++11	inheriting constructor declaration injects additional constructors in the derived class	causes base class constructors to be found by name lookup

TEST #3

Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

DR	Applied to	Behavior as published	Correct behavior
LWG 2901	C++17	allocator-aware constructors provided but variant can't properly support	allocators constructors removed, allocators constructors removed...

• A link to the cppreference replica site
• DR tables style

--Space Mission (talk) 03:27, 15 November 2020 (PST) / --Space Mission (talk) 07:23, 11 February 2022 (PST)