¿Puede el constructor de rango std :: vector invocar conversiones explícitas?

¿El siguiente programa está bien formado?

#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());
}

Según C ++ 17 [secuencia.reqmts], el requisito para

X u(i, j);

donde Xes un contenedor de secuencia, es:

Tserá EmplaceConstructibleen Xde *i.

Sin embargo, en el párrafo anterior se afirma que:

iy jdenotan iteradores que satisfacen los requisitos de iterador de entrada y hacen referencia a elementos implícitamente convertibles a value_type,

Por lo tanto, me parece que ambos requisitos tendrían que cumplirse: el tipo de valor del rango debe ser implícitamente convertible al tipo de valor del contenedor y EmplaceConstructible debe cumplirse (lo que significa que el asignador debe poder realizar la inicialización requerida) . Como intno es implícitamente convertible a A, este programa debe estar mal formado.

Sin embargo, sorprendentemente, parece compilarse bajo GCC .

Es solo un requisito que los contenedores de secuencia admitan la construcción a partir de iteradores que satisfacen los criterios de convertibilidad implícita.

Esto por sí solo no permite que los contenedores de secuencias apoyen esa construcción desde iteradores que no satisfacen ese criterio hasta donde puedo decir ¹ . Hay una regla explícita sobre eso:

Si se llama al constructor ... con un tipo InputIterator que no califica como iterador de entrada , entonces el constructor no participará en la resolución de sobrecarga.

No está claro qué significa "calificar como iterador de entrada" exactamente en el contexto. ¿Es una forma informal de expresar Cpp17InputIterator o intenta referirse a los requisitos de i y j? No lo sé. Ya sea que esté permitido o no, el estándar no tiene un requisito estricto para detectarlo:

[contenedor.requirements.general]

El comportamiento de ciertas funciones miembro de contenedor y guías de deducción depende de si los tipos califican como iteradores o asignadores de entrada. El grado en que una implementación determina que un tipo no puede ser un iterador de entrada no está especificado, excepto que, como mínimo, los tipos integrales no califican como iteradores de entrada. ...

Con la interpretación de que cualquier Cpp17InputIterator "califica como un iterador de entrada", no se requerirá que el programa de ejemplo esté mal formado. Pero tampoco se garantiza que esté bien formado.

¹ En tal caso, podría considerarse un problema de calidad de implementación para advertir al confiar en él. Por otro lado, esta limitación a las conversiones implícitas puede considerarse un defecto .

PD: esto también se compila sin advertencias en Clang (con libc ++) y Msvc.

PPS Esta redacción parece haberse agregado en C ++ 11 (lo cual es natural, ya que también se introdujeron los constructores explícitos).