Stl: <stdexcept>: exception constructor overloads with rvalue string parameters?

[marzer]

Describe the bug
This is more of a question than a bug report, really. I'm writing a TOML parsing lib and using exceptions to notify users when the parser encounters malformed syntax by throwing a subclass of std::runtime_error. For the sake of convenience I'm invoking this via a string-building 'concatenator' function that sequentially appends to a string. Since the <stdexcept> family of exceptions take string arguments by const std::string&, this string is going to get copied into the exception constructor then immediately destroyed when the function exits. Clearly it would make more sense for this string to be handed off to the exception constructor directly by std::string&& and avoid the copy altogether.

I realize we're talking about exceptions so the perf difference is going to be negligible compared with the exception machinery, but doing a copy when I could do a move just feels dirty.

So, my question is this: Does it violate the standard if an implementation adds an _additional_ constructor overload here to take std::string&&?

My read of things is that implementations are allowed to add additional overloads in situations like this as long as API surface area remains semantically the same as if the overload wasn't there, but I'd be the first to admit to suffering some pretty extreme standardese dyslexia at times.

Expected behavior
Well, I'd like to see this:

explicit runtime_error( std::string&& what_arg );
//and likewise for the rest of the standard exception types

Additional context
I ask here because MSVC is my daily driver and personal weapon-of-choice, and you guys seem very helpful and knowledgeable. Please let me know if I'm barking up the wrong tree and should instead be sticking this in a proposal paper.

[marzer]

I should also add that _if_ it's not a violation of the standard to add this, and _if_ you'd be happy with the addition, I'd be eager to contribute the implementation myself.

[StephanTLavavej]

My reading of the Standard is that such an extension is technically not permitted. WG21-N4842
16.5.5.5 [member.functions]/2:

For a non-virtual member function described in the C++ standard library, an implementation may declare a different set of member function signatures, provided that any call to the member function that would select an overload from the set of declarations described in this document behaves as if that overload were selected. [Note: For instance, an implementation may add parameters with default values, or replace a member function with default arguments with two or more member functions with equivalent behavior, or add additional signatures for a member function name. -end note]

The const string& constructor doesn't modify the source, so adding a string&& overload would be observable.

I think that you should submit this as a proposal to WG21 (since several exception classes are affected).

[marzer]

Ah, the old "behaves as if that overload were selected" chestnut. Makes sense. Thanks for the clarification @StephanTLavavej.

If I can find the time after the christmas break I might look at putting together a proposal.