https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |INVALID
--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Geoff Romer from comment #14)
> But see [sequence.reqmts]/p3: "i and j denote iterators satisfying input
> iterator requirements and refer to elements implicitly convertible to
> value_type". So this is not "intended to work" per se; a conforming library
> could disallow it. However, the notes on LWG 536 say "Some support, not
> universal, for respecting the explicit qualifier", so it looks like the
> standard intentionally permits this as a conforming extension.
Which makes the original testcase invalid, so it's a bug in the user's code,
not a bug in libstdc++ to accept it.
> In principle, I think "perfect initialization" is what's called for here:
> the range ctor should be explicit if and only if it uses an explicit
> constructor for value_type.
I don't think that would be a good idea. I don't think it follows that X(int)
being explicit should mean deque<X>(int*, int*) should be explicit. By that
logic shared_ptr(unique_ptr<T>&&) should be explicit, because unique_ptr(T*) is
explicit.
int* is not int, and deque<X> is not X.
