Может ли конструктор диапазона std :: vector вызывать явные преобразования?

Правильно ли сформирована следующая программа?

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

Согласно C ++ 17 [sequence.reqmts], требование для

X u(i, j);

где Xконтейнер последовательности, это:

Tдолжен быть EmplaceConstructibleв Xот *i.

Однако в предыдущем абзаце указано, что:

iи jобозначают итераторы, удовлетворяющие требованиям входных итераторов, и ссылаются на элементы, неявно преобразуемые в value_type,

Таким образом, мне кажется, что оба требования должны быть выполнены: тип значения диапазона должен быть неявно конвертируемым в тип значения контейнера и EmplaceConstructible должен быть удовлетворен (что означает, что распределитель должен быть в состоянии выполнить требуемую инициализацию) , Поскольку эта программа не может быть intпреобразована в неявно A, она должна быть некорректной.

Однако, что удивительно, похоже, что компилируется в GCC .

Для контейнеров последовательностей требуется только поддержка конструкции из итераторов, которые удовлетворяют критериям неявной конвертируемости.

Это само по себе не запрещает контейнерам последовательности поддерживать эту конструкцию от итераторов, которые не соответствуют этим критериям, насколько я могу судить ¹ . Существует явное правило об этом:

Если конструктор ... вызывается с типом InputIterator, который не квалифицируется как входной итератор , тогда конструктор не должен участвовать в разрешении перегрузки.

Неясно, что именно «квалифицировать как входной итератор» означает именно в контексте. Это неофициальный способ выражения Cpp17InputIterator, или он пытается сослаться на требования i и j? Я не знаю. Независимо от того, разрешено это или нет, стандарт не имеет строгих требований для его обнаружения:

[Container.requirements.general]

Поведение некоторых функций-членов контейнера и руководств по выводам зависит от того, относятся ли типы к входным итераторам или распределителям. Степень, в которой реализация определяет, что тип не может быть входным итератором, не определена, за исключением того, что как минимум целочисленные типы не должны квалифицироваться как входные итераторы. ...

С интерпретацией, что любой Cpp17InputIterator «квалифицируется как входной итератор», примерная программа не должна быть плохо сформированной. Но это также не гарантирует, что он будет хорошо сформирован.

¹ В таком случае это может считаться проблемой качества реализации, о которой следует предупреждать, полагаясь на нее. С другой стороны, это ограничение неявных преобразований можно считать недостатком .

PS Это компилируется без предупреждений в Clang (с libc ++) и Msvc.

PPS Эта формулировка, кажется, была добавлена ​​в C ++ 11 (что естественно, так как тогда были также введены явные конструкторы).