[strings] Consistently use shorter forms of return types

[frederick-vs-ja]

Currently, const_reference and const charT& are mixedly used in the return types of some functions in [strings] (same for non-const versions).

This PR consistently

• spells the return types in the short aliased forms, as the shorter forms are clearer, and
• aligns non-const and const overloads of basic_string::data, and
• spells the shorter form for the type of basic_string_view::data_.

[eisenwave]

We should better close this; it's not a good idea.

Note that https://eel.is/c++draft/sequence.reqmts#itemdecl:33 is worded to result in reference, and you're suggesting to make it inconsistent with the sequence container requirements by spelling it out as charT&.

[frederick-vs-ja]

Note that https://eel.is/c++draft/sequence.reqmts#itemdecl:33 is worded to result in reference, and you're suggesting to make it inconsistent with the sequence container requirements by spelling it out as charT&.

Do you mean that we should change to spell (const_)reference as the return types of basic_string's front and back?

Moreover, I don't think consistency with "sequence container requirements" applies to basic_string_view.

[eisenwave]

Do you mean that we should change to spell (const_)reference as the return types of basic_string's front and back?

Yes, that seems better than changing it the other way around. That way it would be reference and const_reference everywhere.

Moreover, I don't think consistency with "sequence container requirements" applies to basic_string_view.

basic_string_view still implements the "string protocol", so it should be consistent with basic_string, which in turn, should be consistent with sequence container requirements.

[frederick-vs-ja]

Do you mean that we should change to spell (const_)reference as the return types of basic_string's front and back?

Yes, that seems better than changing it the other way around. That way it would be reference and const_reference everywhere.

Moreover, I don't think consistency with "sequence container requirements" applies to basic_string_view.

basic_string_view still implements the "string protocol", so it should be consistent with basic_string, which in turn, should be consistent with sequence container requirements.

OK. I'll open another PR for spelling consistency and close this.