`<string>`: Should `string::substr` forward the allocator to the newly created `string`?

[fsb4000]

The C++ Standard doesn't say that: https://eel.is/c++draft/string.substr

STL/stl/inc/xstring

Lines 4673 to 4676 in 5aae678

	_NODISCARD _CONSTEXPR20 basic_string substr(const size_type _Off = 0, const size_type _Count = npos) const {
	// return [_Off, _Off + _Count) as new string
	return basic_string{*this, _Off, _Count, get_allocator()};
	}

Casey Carter (@CaseyCarter) agreed. He also assumed that we'll fix this when implementing WG21-P2438 but I still decided to create an issue to not forget about it.

[frederick-vs-ja]

I think copying or moving from another allocator-aware basic_string object should SOCCC or copy the resulted allocator from the source respectively, instead of default-constructing it.

The requirements for constructors performing partial copy/move and substr are a bit unreasonable to me. But we may need a particular paper to change this.

[fsb4000]

A. Jiang (@frederick-vs-ja) I also sent an email to lwgchair@gmail.com asking for clarification.

[StephanTLavavej]

Casey Carter (@CaseyCarter) notes that there's implementation divergence here, so we need LWG to confirm what we should do here.

[fsb4000]

They replied 😊
https://cplusplus.github.io/LWG/issue3752

[CaseyCarter]

Discussion in the prioritization thread on the Library reflector is leaning very strongly toward closing LWG-3752 as Not A Defect. [string.substr]/1 is quite clear that the effects are equivalent to the "substring constructor" basic_string(const basic_string&, size_type, size_type, Allocator = Allocator()) which LWG-2420 revalidated should default construct an Allocator back in early 2016.

I think we should implement this - and the new rvalue overload introduced in WG21-P2438 - as specified.

[frederick-vs-ja]

I'm fixing this. But I feel that I'm "unfixing" something. (Although this is making the implementation conforming!)

These substring constructors do not follow the convention of allocator-aware containers, so I think they are defective now. Given the source is already an allocator-aware basic_string, in the IMO reasonable specification,

• the const basic_string& overloads (and the const/const& overload of substr) should use SOCCC to obtain the allocator from the source, and
• the newly added basic_string&& overloads (and the && overload of substr) should copy (which is equivalent to move for allocators) the allocator from the source, however,
• default arguments are no longer possible, so each existing constructor overload should be split into two overloads.

---

Oh, this is just the failed PR of LWG-2402 (with extensions).