Czy konstruktor zakresu std :: vector może wywoływać jawne konwersje?

Czy następujący program jest dobrze sformułowany?

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

Zgodnie z C ++ 17 [sekwencja.reqmts] wymóg dotyczący

X u(i, j);

gdzie Xjest kontenerem sekwencji, jest:

Tbędzie EmplaceConstructibledo Xz *i.

Jednak w poprzednim akapicie stwierdzono, że:

ii joznaczają iteratory spełniające wymagania iteratora wejściowego i odnoszą się do elementów domyślnie konwertowalnych value_type,

Wydaje mi się zatem, że oba wymagania musiałyby zostać spełnione: typ wartości zakresu musi być domyślnie konwertowany na typ wartości kontenera i EmplaceConstructible musi być spełniony (co oznacza, że ​​alokator musi być w stanie wykonać wymaganą inicjalizację) . Ponieważ intnie można go domyślnie przekonwertować A, ten program powinien być źle sformułowany.

Jednak, co zaskakujące, wydaje się , że kompiluje się w GCC .

Jest to tylko wymóg, aby kontenery sekwencji wspierały konstrukcję z iteratorów, które spełniają kryteria niejawnej wymienialności.

To samo w sobie nie uniemożliwia kontenerom sekwencji wspierania tej konstrukcji z iteratorów, które nie spełniają tych kryteriów, o ile mogę powiedzieć ¹ . Istnieje wyraźna zasada:

Jeśli konstruktor ... zostanie wywołany z typem InputIterator, który nie kwalifikuje się jako iterator wejściowy , wówczas konstruktor nie będzie uczestniczył w rozwiązywaniu problemów z przeciążeniem.

Nie jest jasne, co „kwalifikować się jako iterator wejściowy” oznacza dokładnie w kontekście. Czy to nieformalny sposób wyrażenia Cpp17InputIterator, czy też próbuje odwoływać się do wymagań i i j? Nie wiem Niezależnie od tego, czy jest to dozwolone, czy nie, standard nie ma ścisłego wymogu wykrywania:

[container.requirements.general]

Zachowanie niektórych funkcji członka kontenera i przewodników dedukcyjnych zależy od tego, czy typy kwalifikują się jako iteratory wejściowe, czy alokatory. Zakres, w jakim implementacja określa, że ​​typ nie może być iteratorem wejściowym, jest nieokreślony, z tym wyjątkiem, że jako minimum całkowe typy nie kwalifikują się jako iteratory wejściowe. ...

Przy interpretacji, że jakikolwiek Cpp17InputIterator „kwalifikuje się jako iterator wejściowy”, przykładowy program nie wymagałby nieprawidłowego kształtowania. Ale nie ma też gwarancji, że będzie dobrze uformowany.

¹ W takim przypadku można uznać za problem z jakością wdrożenia ostrzeżenie, gdy się na nim opiera. Z drugiej strony to ograniczenie do konwersji niejawnych można uznać za wadę .

PS Kompiluje się bez ostrzeżeń w Clang (z libc ++) i Msvc.

PPS Wydaje się, że to sformułowanie zostało dodane w C ++ 11 (co jest naturalne, ponieważ wprowadzono także jawne konstruktory).