View source for 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:
* {{l2tf std|cpp/string/basic_string/back}}
* {{l2tf std|cpp/string/basic_string/front}}
* {{l2tf std|cpp/string/basic_string/pop_back}}
* {{l2tf std|cpp/string/basic_string/shrink_to_fit}}
* {{l2tf std|cpp/container/deque/shrink_to_fit}}
* {{l2tf std|cpp/container/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 {{mark c++11}} or {{mark 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. [[User:Xmcgcg|Xmcgcg]] ([[User talk: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 <tt>is_null_pointer</tt>, <tt>is_aggregate</tt> and <tt>is_final</tt>, which are similarly introduced by LWG issues? --[[User:D41D8CD98F|D41D8CD98F]] ([[User talk: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 {{mark 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|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:
::# the initial version where the defect exists;
::# 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|150}}, see [[cpp/language/template parameters#Template template arguments|here]]), I think the best way is still to stick to the target version, but add sufficient notes to address the compiler conformance. --[[User:Xmcgcg|Xmcgcg]] ([[User talk: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 <tt>__is_final</tt> 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. --[[User:D41D8CD98F|D41D8CD98F]] ([[User talk: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 {{tt|std::is_final}} example:
::::# 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).
::::# The resolution is to add {{tt|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 {{lc|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. --[[User:Xmcgcg|Xmcgcg]] ([[User talk:Xmcgcg|talk]]) 20:00, 1 June 2023 (PDT)

::::: Library issues are tricky because LWG never adopted the idea of retroactive DRs. Compare [https://cplusplus.github.io/LWG/lwg-defects.html lwg_defects] and [https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html 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. --[[User:Cubbi|Cubbi]] ([[User talk: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|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 {{mark 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. --[[User:Xmcgcg|Xmcgcg]] ([[User talk: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 [https://github.com/llvm/llvm-project/issues/60597#issuecomment-1422287755 this comment]. (libc++ even backports {{lc|std::basic_string_view}} to C++98 mode ([https://godbolt.org/z/rxvT8fWvz demo]).)--[[User:Fruderica|Fruderica]] ([[User talk:Fruderica|talk]]) 17:54, 11 January 2024 (PST)

===Status update===
I have just applied {{mark tooltip|DR|not available in libstdc++ C++98 mode}} (hover to see the tooltip) annotations to the navbar and {{l2tf std|cpp/string/basic_string/shrink_to_fit}} description item.

My opinion is:
* The {{mark|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 {{mark|DR*}} annotation does not have C/C++ version information on its own. It can follow the version annotations however. For example, {{mark since c++11}}{{mark|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 {{tl|dcl}} items in the overload list.

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

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

== LWG1192 is a patch to N1913 ==

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