Le constructeur de la plage std :: vector peut-il invoquer des conversions explicites?

Le programme suivant est-il bien formé?

#include <vector>
struct A {
    explicit A(int) {}
};
int main() {
    std::vector<int> vi = {1, 2, 3, 4, 5};
    std::vector<A> va(vi.begin(), vi.end());
}

Selon C ++ 17 [sequence.reqmts], l'exigence de

X u(i, j);

où Xest un conteneur de séquence, est:

Tdoit être EmplaceConstructibleà Xpartir de *i.

Cependant, au paragraphe précédent, il est indiqué que:

iet jdésignent des itérateurs satisfaisant aux exigences des itérateurs d'entrée et font référence à des éléments implicitement convertibles en value_type,

Ainsi, il me semble que les deux exigences devraient être remplies: le type de valeur de la plage doit être implicitement convertible en type de valeur du conteneur, et EmplaceConstructible doit être satisfait (ce qui signifie que l'allocateur doit pouvoir effectuer l'initialisation requise) . Puisqu'il intn'est pas implicitement convertible en A, ce programme devrait être mal formé.

Cependant, étonnamment, il semble compiler sous GCC .

Il suffit que les conteneurs de séquences prennent en charge la construction à partir d'itérateurs qui satisfont aux critères de convertibilité implicite.

Cela ne permet pas en soi d'interdire aux conteneurs de séquence de soutenir cette construction à partir d'itérateurs qui ne satisfont pas à ces critères pour autant que je sache ¹ . Il y a une règle explicite à ce sujet:

Si le constructeur ... est appelé avec un type InputIterator qui ne se qualifie pas en tant qu'itérateur d'entrée , le constructeur ne doit pas participer à la résolution de surcharge.

On ne sait pas exactement ce que "qualifier d'itérateur d'entrée" signifie exactement dans le contexte. Est-ce un moyen informel d'exprimer Cpp17InputIterator ou tente-t-il de se référer aux exigences de i et j? Je ne sais pas. Qu'elle soit autorisée ou non, la norme n'a pas d'exigence stricte pour la détecter:

[container.requirements.general]

Le comportement de certaines fonctions de membre de conteneur et guides de déduction dépend de la qualification des types d'itérateurs d'entrée ou d'allocateurs. La mesure dans laquelle une implémentation détermine qu'un type ne peut pas être un itérateur d'entrée n'est pas spécifiée, sauf que, au minimum, les types intégraux ne doivent pas être qualifiés d'itérateurs d'entrée. ...

Avec l'interprétation que tout Cpp17InputIterator "se qualifie comme un itérateur d'entrée", le programme d'exemple n'aurait pas besoin d'être mal formé. Mais il n'est pas non plus garanti d'être bien formé.

¹ Dans ce cas, il peut être considéré comme un problème de qualité de mise en œuvre d'avertir lorsque vous vous y fiez. En revanche, cette limitation aux conversions implicites peut être considérée comme un défaut .

PS Cela compile sans avertissements dans Clang (avec libc ++) et Msvc également.

PPS Cette formulation semble avoir été ajoutée en C ++ 11 (ce qui est naturel, tout comme les constructeurs explicites ont également été introduits).