Talk:cpp/string/basic string/front

Why not reference

Hi. Maybe this is not the proper place to ask, but does anybody know why the interface of std::string::front and std::string::back uses, as return type, the plain (const)references instead of these dedicated types:

• std::basic_string::reference,
• std::basic_string::const_reference,

as opposed to the interface of, e.g., std::string::at. Is this divergence on purpose?

An excerpt from <string>:

namespace std {
  template<class CharT, class Traits = char_traits<CharT>,
           class Allocator = allocator<CharT>>
  class basic_string {
  public:
    // types
    // ...
    using value_type             = CharT;
    // ...
    using reference              = value_type&;
    using const_reference        = const value_type&;
    // ...
 
    // element access
    constexpr const_reference operator[](size_type pos) const; // OK - const_reference
    constexpr reference       operator[](size_type pos);       // OK - reference
    constexpr const_reference at(size_type n) const;           // OK
    constexpr reference       at(size_type n);                 // OK
 
    constexpr const CharT& front() const; /* My: Wait, what? Not `const_reference`? */
    constexpr CharT&       front();       /* My: ditto, `reference`? */
    constexpr const CharT& back() const;  /* My: ditto, `const_reference`? */
    constexpr CharT&       back();        /* My: ditto, `reference`? */

In the better imaginary world it should be:

>   constexpr const_reference front() const; // happiness
    constexpr reference       front();       // happiness
    constexpr const_reference back() const;  // happiness
    constexpr reference       back();        // happiness

Most likely, this is also connected with LWG issue 534.

--Space Mission (talk) 10:26, 27 March 2023 (PDT)

There's no reason to use or to avoid the reference aliases, it's just an editorial inconsistency. Note that libstdc++, libc++ and MS stdlib all use reference. If you were to make them consistent here on cppreference, more power to you --Ybab321 (talk) 11:00, 27 March 2023 (PDT)

Yea, this was my attempt to limelight this inconsistency. Should it be DR (too much for such a smidge change) or a letter to Thomas? I just would prefer to see this is fixed in draft/ISO first, then reflect it here.) --Space Mission (talk) 11:25, 27 March 2023 (PDT)

Editorial issues are raised on the github --Ybab321 (talk) 11:44, 27 March 2023 (PDT)

CharT& and const CharT& are shorter and clearer. If the standard wording changes to say reference and const_reference, I won't follow. --Fruderica (talk) 04:24, 10 January 2024 (PST)

I've opened editorial PR #6764 for this. --Fruderica (talk) 05:23, 10 January 2024 (PST)

Hi there.)

I skimmed:

1. #6764
2. the standard headers, and
3. some implementations of the standard library,

and this is what I found:

1. All sequence-like container-like types std::array, std::list, std::forward_list, std::deque, std::queue, std::span, std::stack (for top()), std::vector, std::bitset use reference/const_reference for element access interface at()/[]/front()/back().
2. Only std::valarray uses (maybe const) T&.
3. Associative containers on the other hand prefer (maybe const) Container::mapped_type&.

But more importantly, all four vendors already use reference/const_reference as return types of at()/[]/front()/back() element access members of std::string and std::string_view!

• clang's libc++ does,
• gcc's libstdc++ does in string, string_view and even in ext::vstring.) Only their std::experimental::string_view (as of gcc-13.2) still uses (maybe const) _CharT&.)
• OpenSTL (msvc) also uses reference/const_reference (their "element type" is named _Elem).
• ESTL also uses reference/const_reference in their string and string_view.

So reference/const_reference is preferable for the following reasons:

• standardization of existing practice,
• independence from the template parameter name (which is obviously IRL, not CharT, and varies from vendor to vendor),
• consistency with existing "container-like" interfaces,
• etc...

--Space Mission (talk) 11:02, 12 January 2024 (PST)