[lib] Extend exception propagation to cover the initialization LWG3640

[JohelEGP]

Problem and solution

The wording for the specification of facilities that propagate exceptions inadvertently exclude some cases of thrown exceptions. The ones I've identified have the form "any exception thrown by the {(selected) constructor,construction} of {T,some object}". This formulation excludes exceptions thrown by the initialization of the constructor's parameters ([expr.call] p7). These are not thrown by the constructor nor during the construction of the object (after its construction has begun ([class.cdtor] p1)).

Implying that the initialization of the constructor's parameter are part of the effects for which exceptions are propagated can be done with these changes:

• "Any exception thrown by calling the (selected) constructor of T.
• "Any exception thrown by the constructioninitialization of {T,some object}".

The former is already present in the standard, as exemplified below. As for the latter (emphasis mine),

The process of initialization described in [dcl.init] applies to all initializations regardless of syntactic context, including the initialization of a function parameter ([expr.call]), the initialization of a return value ([stmt.return]), or when an initializer follows a declarator.
-- https://eel.is/c++draft/dcl.init p1

Examples

Example, good

Constructors and member functions of pair do not throw exceptions unless one of the element-wise operations specified to be called for that operation throws an exception. -- https://eel.is/c++draft/pairs.pair#1

Talking in terms of operations includes initialization.

Example, bad

For each tuple constructor, an exception is thrown only if the construction of one of the types in Types throws an exception. -- https://eel.is/c++draft/tuple.cnstr#2

We can make a tuple constructor throw an exception other than by constructing one of the specified types: https://godbolt.org/z/enGThMq4P.

#include <tuple>
struct X { X(int) { } };
struct Y { operator int() { throw 0; } };
int main() { std::tuple<X>(Y{}); }

As described at the top, this throws before beginning the construction of an X subobject.

Do note that the constructor above is described to initialize:

Effects: Initializes the elements in the tuple with the corresponding value in std​::​forward(u). -- https://eel.is/c++draft/tuple.cnstr#13

One could argue that [tuple.cnstr] doesn't say "if and only if". That just leaves in the air what happens in this case.

Example, good

Throws: Any exception thrown by the initialization of the selected alternative Tj. -- https://eel.is/c++draft/variant.ctor#18
Throws: Any exception thrown by calling the selected constructor of T. -- https://eel.is/c++draft/variant.ctor#23

[jensmaurer]

I agree with the problem statement.

Regarding the solutions offered, phrasing this in terms of initialization seems preferable, because it also covers the case where there is no constructor (e.g. for built-in types).

Is there a full list of offending wording somewhere?

[JohelEGP]

I, too, prefer initialization, if at least for uniformity. But I believe the change is big enough, so inserting "calling" could be a first step. Unless the initialization of fundamental types are allowed to throw exceptions, this would not be wrong. But it would require saying "if any" to account for when there's no actual constructor involved (which can also apply to class types).

There's no full list. I found this problem while searching for "exception" in the library. But for the case of exception propagation, the actual suspects (so far) are uses of "constructor" and "construction". More generally, it's the reference to particular steps of initialization, when the intention is to refer to the initialization itself.

Feel free to assign this to me.

[JohelEGP]

If an exception is thrown during the call to \tcode{T}'s copy assignment,
the state of its contained value is as defined by the exception safety guarantee of \tcode{T}'s copy assignment. -- https://eel.is/c++draft/optional#assign-7.sentence-3
This operator is defined as deleted unless
\tcode{is_copy_constructible_v} is \tcode{true} and
\tcode{is_copy_assignable_v} is \tcode{true}. -- https://eel.is/c++draft/optional#assign-7.sentence-4

This does not require T to meet the Cpp17CopyAssignable requirements. So the assignment as specified can return something other than T&. Particularly a prvalue whose destruction throws. Only T's destructor is required to not throw.

\tcode{T} shall be a type
other than \cv{} \tcode{in_place_t} or \cv{} \tcode{nullopt_t}
that meets the \oldconcept{Destructible} requirements (\tref{cpp17.destructible}). -- https://eel.is/c++draft/full#optional.optional.general-3.sentence-1
| u.~T() | All resources owned by u are reclaimed, no exception is propagated. -- https://eel.is/c++draft/utility.arg.requirements#tab:cpp17.destructible-row-2

This seems defective to me. How I word this issue's resolution depends on whether the named requirements corresponding to the type traits requirements should have been preconditions on such potentially-throwing operations.

Unless any one of you is absolutely sure that this is not a defect, I will proceed by adding those corresponding Preconditions: alongside the other changes. Meanwhile, I'll submit a LWG issue with the hopes of confirming that there's a defect and that my chosen resolution is the right one.

[JohelEGP]

Unless any one of you

Me included.

On further analysis of sibling vocabulary types, all of them use type traits instead of named requirements for these operations. So I will proceed on the assumption there's no such defect.

[JohelEGP]

Even "initialization" doesn't encompass enough. An exception thrown by the destruction of a temporary created as part of the initialization of a constructor's parameter is not part of the initialization (https://eel.is/c++draft/expr.call#7.sentence-9, https://eel.is/c++draft/full#class.temporary-4.sentence-5).
See https://godbolt.org/z/3MYod6za7:

#include <tuple>
struct Z { ~Z() noexcept(false) { throw 0; } };
struct X { X(const Z&) noexcept { } };
struct Y { operator Z() { return {}; } };
int main() try { std::tuple<X>(Y{}); } catch(...) { throw 0ull; }
// Terminate on thrown int means throw within noexcept

Exceptions thrown by destructors of returned prvalues seem to have the same problem: https://godbolt.org/z/xeaaEToMq.

For each \tcode{tuple} assignment operator, an exception is thrown only if the
assignment of one of the types in \tcode{Types} throws an exception. -- https://eel.is/c++draft/tuple#assign-1.sentence-1

#include <tuple>
struct Y { ~Y() noexcept(false) { throw 0; } };
struct X { Y operator=(const X&) noexcept { return {}; } };
int main()
try {
  std::tuple<X> x{};
  x = x;
  throw '0';
}
catch(int) {
  throw 0ull; // Terminate on thrown int means throw within noexcept
}

I propose the following amendment to the proposed solution:

Implying that the side effects of the initialization of a constructor's parameter are part of the effects for which exceptions are propagated can be done with these changes:

• "Any exception thrown by propagated from a side effect of calling the (selected) constructor of T.
• "Any exception thrown by the construction propagated from a side effect of the initialization of {T,some object}".

The use of "propagated" was taken from https://eel.is/c++draft/futures.async#3. This use of side effect is novel.

[jensmaurer]

@jwakely , there seems to be material for at least two library issues here.

The first one is for optional.assign p7 and vicinity:

"This does not require T to meet the Cpp17CopyAssignable requirements. So the assignment as specified can return something other than T&. Particularly a prvalue whose destruction throws. Only T's destructor is required to not throw."

A type traits check (e.g. is_copy_assignable) does not replace a semantic precondition, e.g. Cpp17CopyAssignable.

The second one is bad phrasing around "thrown by the construction", because it ignores exceptions thrown by the destruction of temporaries and by the destruction of prvalue results. LWG should form an opinion what the appropriate phrasing should be (possibly in conjunction with a front-matter explanation), and apply that uniformly (or have it editorially applied uniformly).

And no, "side effects" is a defined term in [intro.execution]; we can't use that here. "full-expression" might help, though.

[JohelEGP]

I did notice that std::tuple<T> didn't even require T to meet the Cpp17Destructible requirements, as opposed to std::optional. Now, a quick test shows that implementations do not swallow exceptions in the destructor, suggesting a defect as it fails to meet its own requirements. It doesn't define a destructor, so this is fine. std::any, on the other hand, does define a destructor yet doesn't impose the named requirement. Here's a proof of implementation divergence: https://godbolt.org/z/Yrszd3d4f.

[JohelEGP]

And no, "side effects" is a defined term in [intro.execution]; we can't use that here. "full-expression" might help, though.

I propose amending the proposed solution to the following:

Let E be the construction of {T,some object}. Implying that the full expression E is a subexpression of propagates exceptions as a result of evaluating E can be done with this change:

• "Any exception propagated from the full expression that evaluates E".

[JohelEGP]

That could even be defined as exception-propagating.

+3.21 [defns.exception-propagating]
+exception-propagating
+an effect whose exceptions thrown due to the evaluation of its implementing expression are propagated

-Constructors and member functions of pair do not throw exceptions unless one of the element-wise
-operations specified to be called for that operation throws an exception.
+For constructors and member functions of pair, each element-wise
+operation specified to be called for that operation is exception-propagating.

-For each \tcode{tuple} constructor, an exception is thrown only if the construction of
-one of the types in \tcode{Types} throws an exception.
+For each \tcode{tuple} constructor, the construction of each type in \tcode{Types} is exception-propagating.

 \item
 \throws
-any exceptions thrown by the function, and the conditions that would cause the exception.
+any exceptions thrown by the function and the conditions that would cause the exception, and
+effects specified as exception-propagating.

-Throws: Any exception thrown by the initialization of the selected alternative Tj.
+Throws: The initialization of the selected alternative Tj is exception-propagating.

-Throws: Any exception thrown by the selected constructor of T.
+Throws: Calling the selected constructor of T is exception-propagating.

[JohelEGP]

@jwakely , there seems to be material for at least two library issues here.

The first one is for optional.assign p7 and vicinity:

"This does not require T to meet the Cpp17CopyAssignable requirements. So the assignment as specified can return something other than T&. Particularly a prvalue whose destruction throws. Only T's destructor is required to not throw."

A type traits check (e.g. is_copy_assignable) does not replace a semantic precondition, e.g. Cpp17CopyAssignable.

All uses of type traits are suspects. For these siblings vocabulary types,

besides std::any, the matches when searching for Cpp17 with corresponding type trait constraints are ~3, yet matches for _v are ever present.

[JohelEGP]

I did notice that std::tuple<T> didn't even require T to meet the Cpp17Destructible requirements, as opposed to std::optional. Now, a quick test shows that implementations do not swallow exceptions in the destructor, suggesting a defect as it fails to meet its own requirements. It doesn't define a destructor, so this is fine. std::any, on the other hand, does define a destructor yet doesn't impose the named requirement. Here's a proof of implementation divergence: https://godbolt.org/z/Yrszd3d4f.

Amended that. It seems that libstdc++ is more conforming here as it behaves as if it had a non-throwing exception specification. Whereas libc++ lets the exception propagate (opened https://bugs.llvm.org/show_bug.cgi?id=51758).