Namespaces
Variants

    Talk:cpp/string/basic string/front

    From cppreference.com

    Why not reference

    See More

    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:

    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)