Is it possible to invoke a user-defined conversion function via list-initialization?

by

The original intent of 13.3.3.1p4 is to describe how to apply the requirement in 12.3p4 that:

4 – At most one user-defined conversion (constructor or conversion function) is implicitly applied to a single value.

Before defect 84, 13.3.3.1p4 was almost purely informative:

4 – In the context of an initialization by user-defined conversion (i.e., when considering the argument of a user-defined conversion function; see 13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv]), only standard conversion sequences and ellipsis conversion sequences are allowed.

This is because 13.3.1.4 paragraph 1 bullet 2 and 13.3.1.5p1b1 restrict the candidate functions to those on class S yielding type T, where S is the class type of the initializer expression and T is the type of the object being initialized, so there is no latitude for another user-defined conversion conversion sequence to be inserted. (13.3.1.4p1b1 is another matter; see below).

Defect 84 repaired the auto_ptr loophole (i.e. auto_ptr<Derived> -> auto_ptr<Base> -> auto_ptr_ref<Base> -> auto_ptr<Base>, via two conversion functions and a converting constructor) by restricting the conversion sequences allowable for the single parameter of the constructor in the second step of class copy-initialization (here the constructor of auto_ptr<Base> taking auto_ptr_ref<Base>, disallowing the use of a conversion function to convert its argument from auto_ptr<Base>):

4 – However, when considering the argument of a user-defined conversion function that is a candidate by 13.3.1.3 [over.match.ctor] when invoked for the copying of the temporary in the second step of a class copy-initialization, or by 13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] in all cases, only standard conversion sequences and ellipsis conversion sequences are allowed.

n2672 then adds:

[…] by 13.3.1.7 [over.match.list] when passing the initializer list as a single argument or when the initializer list has exactly one element and a conversion to some class X or reference to (possibly cv-qualified) X is considered for the first parameter of a constructor of X, […]

This is clearly confused, as the only conversions that are a candidate by 13.3.1.3 and 13.3.1.7 are constructors, not conversion functions. Defect 978 corrects this:

4 – However, when considering the argument of a constructor or user-defined conversion function […]

This also makes 13.3.1.4p1b1 consistent with 12.3p4, as it otherwise would allow unlimited application of converting constructors in copy-initialization:

struct S { S(int); };
struct T { T(S); };
void f(T);
f(0);   // copy-construct T by (convert int to S); error by 12.3p4

The issue is then what the language referring to 13.3.1.7 means. X is being copy or move constructed so the language is excluding applying a user-defined conversion to arrive at its X argument. std::initializer_list has no conversion functions so the language must be intended to apply to something else; if it isn’t intended to exclude conversion functions, it must exclude converting constructors:

struct R {};
struct S { S(R); };
struct T { T(const T &); T(S); };
void f(T);
void g(R r) {
    f({r});
}

There are two available constructors for the list-initialization; T::T(const T &) and T::T(S). By excluding the copy constructor from consideration (as its argument would need to be converted via a user-defined conversion sequence) we ensure that only the correct T::T(S) constructor is considered. In the absence of this language the list-initialization would be ambiguous. Passing the initializer list as a single argument works similarly:

struct U { U(std::initializer_list<int>); };
struct V { V(const V &); V(U); };
void h(V);
h({{1, 2, 3}});

Edit: and having gone through all that, I’ve found a discussion by Johannes Schaub that confirms this analysis:

This is intended to factor out the copy constructor for list initialization
because since we are allowed to use nested user defined conversions, we
could always produce an ambiguous second conversion path by first invoking
the copy constructor and then doing the same as we did for the other
conversions.

OK, off to submit a defect report. I’m going to propose splitting up 13.3.3.1p4:

4 – However, when considering the argument of a constructor or user-defined conversion function that is a candidate:

  • by 13.3.1.3 [over.match.ctor] when invoked for the copying of the temporary in the second step of a class copy-initialization, or
  • by 13.3.1.4 [over.match.copy], 13.3.1.5 [over.match.conv], or 13.3.1.6 [over.match.ref] in all cases,

only standard conversion sequences and ellipsis conversion sequences are considered; when considering the first argument of a constructor of a class X that is a candidate by 13.3.1.7 [over.match.list] when passing the initializer list as a single argument or when the initializer list has exactly one element, a user-defined conversion to X or reference to (possibly cv-qualified) X is only considered if its user-defined conversion is specified by a conversion function. [Note: because more than one user-defined conversion is allowed in an implicit conversion sequence in the context of list-initialization, this restriction is necessary to ensure that a converting constructor of X, called with a single argument a that is not of type X or a type derived from X, is not ambiguous against a constructor of X called with a temporary X object itself constructed from a. — end note]

More Related Contents:

  1. Why is list initialization (using curly braces) better than the alternatives?
  2. What are the advantages of list initialization (using curly braces)?
  3. lifetime of a std::initializer_list return value
  4. Why can I not brace initialize a struct derived from another struct?
  5. Why does the standard differentiate between direct-list-initialization and copy-list-initialization?
  6. Why do auto and template type deduction differ for braced initializers?
  7. lvalue to rvalue implicit conversion
  8. Classes with both template and non-template conversion operators in the condition of switch statement
  9. When is explicit move needed for a return statement?
  10. Which greedy initializer-list examples are lurking in the Standard Library?
  11. Difference in make_shared and normal shared_ptr in C++
  12. What does auto&& tell us?
  13. Difference between std::regex_match & std::regex_search?
  14. What does the standard library guarantee about self move assignment?
  15. What is a raw string?
  16. Why should I avoid std::enable_if in function signatures
  17. C++ unordered_set of vectors
  18. Can returning a local variable by value in C++11/14 result in the return value being constructed by rvalue when no copy/move is involved?
  19. std::optional specialization for reference types
  20. What is decltype with two arguments?
  21. Do built-in types have move semantics?
  22. Variadic function template with pack expansion not in last parameter
  23. Portable way of setting std::thread priority in C++11
  24. Is 1.0 a valid output from std::generate_canonical?
  25. Is std::array movable?
  26. Is writing to &str[0] buffer (of a std:string) well-defined behaviour in C++11?
  27. Why can’t I initialize a reference in an initializer list with uniform initialization?
  28. How to iterate over a std::tuple in C++ 11 [duplicate]
  29. C++ Linker Error With Class static constexpr
  30. Is it safe to reinterpret_cast an enum class variable to a reference of the underlying type?

Leave a Comment