Template talk:cpp/string/basic string/navbar content

Regarding LWG 534/755/850

These LWG issues claimed that the following member functions in the standard library had been missing, requested to add them to the standard:

• std::basic_string::back()
• std::basic_string::front()
• std::basic_string::pop_back()
• std::basic_string::shrink_to_fit()
• std::deque::shrink_to_fit()
• std::vector::shrink_to_fit()

All these issues became DRs and all these member functions were added to the C++0x working draft. Unfortunately, libstdc++ does not support them in C++98 mode.

My opinion is that these member functions should not be marked (C++11) or (since C++11) in the description item template, navbar template and the declaration list (for the first revision). We can add notes and footnotes to tell the readers the missing support in libstdc++ C++98 mode.

Although these member functions are widely known as 'C++11 new features', I believe that treating them in the same way as other DR resolutions would be better. If someone in 2023 is still using libstdc++ in C++98 mode for development and forgets whether these member functions are available, the worst result would just be a compile error, and he should be able to find the cause pretty easily. Xmcgcg (talk) 02:56, 31 May 2023 (PDT)

On one hand I like being consistent in the treatment of DRs. On the other hand I'm not sure how far we should go. What do you think about is_null_pointer, is_aggregate and is_final, which are similarly introduced by LWG issues? --D41D8CD98F (talk) 02:44, 1 June 2023 (PDT)

I have checked the corresponding LWG issues, and I think these type traits should all be marked (C++11). The key factor is that all these type traits are implementable (including being a compiler intrinsic) in C++11 mode, i.e. no dependency on post-C++11 language and library features. Even more, the discussion of LWG issue 2112 explicitly states that "Several existing C++11 compilers do already provide an internal __is_final intrinsic (e.g. clang and gcc) and therefore we believe that this is evidence enough that this feature is implementable today."

For most of the DR items I added to the DR lists in the past one and a half year, I determinted the target C++ version of each DR item by two factors:

1. the initial version where the defect exists;
2. the oldest version to which the resolution is applicable.

"Applicable" here means the language constructs or other library components used in the resolution is available in that version of the standard, something like "theoretically implementable". Even if compilers do not apply the resolution in the mode of that version (e.g. CWG issue 150, see here), I think the best way is still to stick to the target version, but add sufficient notes to address the compiler conformance. --Xmcgcg (talk) 09:23, 1 June 2023 (PDT)

I believe that the "target version" is vague for these type traits. Compilers could as well provide __is_final in C++98 (and they actually do).

While I prefer precision over pragmatism in general, I believe that there's no precise specification in this case. Describing these based on existing practice would both reflect the informal consensus, and be more helpful to readers (who are more likely interested in what's actually implemented than what's theoretically implementable).

Another point is that these (members and type traits) are practically new features, despite being in the form of DRs, as they introduce new names and new functionality to the standard library. --D41D8CD98F (talk) 16:17, 1 June 2023 (PDT)

I think I get your point. In the point of view of "feature addition/modification", there is no clear border to partition which of the DRs should be considered as fixes or additions. But from the methodology perspective, we can apply "patches" to the items (as notes and footnotes), while sticking to the standard.

Regarding the "target version", I can break it down further. Each of the two factors I have talked about determines a lower bound whether the resolution is applicable. The first factor determines the 'defective versions', meaning the defect exists in all these versions. The second factors determines the 'resolvable versions', meaning the resolution can be applied to all these versions. Taking the std::is_final example:

1. The 'defect' is in the metaprogramming library, which did not exist in C++98. Therefore the defect exists in all C++ versions since C++11 (if it is has not been fixed).
2. The resolution is to add std::is_final to the metaprogramming library. Therefore the resolution is applicable to all C++ versions since C++11.

The second factor seems to be redundant, while it actually is redundant in most of the cases. But I did encounter some issues which received no attention from CWG/LWG for a long time (a few years maybe), and by the time the resolution is ready, it cannot be applied to the initial defecive version. For example, the defect exists in a pre-C++20 version, and the resolution uses requires-clauses. In these cases I pushed the target version to C++20, since the older versions can never be properly fixed.

I have tried another way to note the libstdc++ conformance in the std::basic_string navbar and main page (using footnotes). My point is that for description items and navbars, we can use footnotes to draw attentions from the readers to the implementation notes, while in description pages we can simply provide the information in the 'Notes' section. --Xmcgcg (talk) 20:00, 1 June 2023 (PDT)

Library issues are tricky because LWG never adopted the idea of retroactive DRs. Compare lwg_defects and cwg_defects. Each lists "DR" as a status, but lwg_defects has zero issues in DR status. In the past, tagging LWG issues on cppreference have always been a bit contentious, except where they fix unimplementable library specs (those are obviously retroactive). For an issue that adds new functionality I'd say do what 2 out of 3 implementors did. --Cubbi (talk) 20:55, 1 June 2023 (PDT)

In fact there are retroactive LWG DRs, but it seems that LWG's favor is to merge the issues that pass the plenary vote to the working paper before a new library issue list revision is published. For example, LWG issue 3403 targets a defect in C++20, its status changed directly from 'Tentatively Ready' to 'WP' by the approval of LWG. No 'DR' state involved.

Back to LWG 534/755/850, libc++ supports all those 6 member functions listed above in C++98 mode (tested in Coliru by modifying the examples). That is why I am attempting to remove the (since C++11) marks again. My opionion is that library features added by DRs should never be unconditionally marked with the version which they start to appear in the standard or the version where most/all compilers initially support. There needs to be some notes or other kinds of marks to distinguish them from the features added by proposals. --Xmcgcg (talk) 18:39, 4 June 2023 (PDT)

libc++ maybe confusing on DR status because it heavily backports C++11 features that are clearly not DRs to C++98 mode. See also this comment. (libc++ even backports std::basic_string_view to C++98 mode (demo).)--Fruderica (talk) 17:54, 11 January 2024 (PST)

Status update

I have just applied (DR*) (hover to see the tooltip) annotations to the navbar and std::basic_string::shrink_to_fit() description item.

My opinion is:

• The (DR*) annotation is only applied to description items and navbar items of the library entities added by DRs (via papers or direct resolutions of issues) and there is a controversy due to implementation divergence or some other reason.
• The tootip information serves as the 'controversy solver', it reminds the reader that some compilers might not declare those library entities in certain C++ version modes.
• The (DR*) annotation does not have C/C++ version information on its own. It can follow the version annotations however. For example, (since C++11)(DR*) means the target version of the issue is C++11.
• The description page has a 'Notes' section to address the implementation-specific behaviors, so the annotations should not be applied to the {{dcl}} items in the overload list.

I will apply (DR*) to other member functions added by LWG 534/755/850 if no further improvement is needed. --Xmcgcg (talk) 01:53, 9 June 2023 (PDT)

I like that approach --Cubbi (talk) 09:48, 9 June 2023 (PDT)

LWG1192 is a patch to N1913

Note that libc++ has just add all member cbegin in N1913 to C++98 mode, while we shouldn't treat N1913 as a DR against C++98. --Fruderica (talk) 02:23, 10 January 2024 (PST)