Tony, but that example is not valid code - you need to specify vector type, at which point the purported ambiguity would disappear..?

On Fri, Sep 6, 2019, 12:57 PM Tony V E via Std-Discussion <std-discussion@lists.isocpp.org> wrote:


On Fri, Sep 6, 2019 at 1:06 PM Lyberta via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
Eduard Antonyan via Std-Discussion:
> Every single time I've used the InputIterator constructors of various
> containers (e.g. vector or set), it's been to convert an existing container
> from one type to another (e.g. set to a vector). As such my code could've
> been simpler and more concise if the constructors simply took a container
> as an argument and did the begin/end internally.
>
> Any reasons to not have such constructors? These are trivial to write and
> I'm happy to provide the code, but perhaps I'm missing something.
>
> Thanks.
>
>

Yes, every function that takes a pair of iterators should have an
overload that takes std::ranges::input_range (or similar). This should
be easy to add in C++23.


"should be easy"
hahaha, are you new here? :-)

Given the number of constructors and overloads already in place, it might not be too easy.  In fact, it never is.
The first example that comes to mind is:

std::set<int> s = ...;
std::vector v {s};  // is this a vector of ints, or a vector of sets???

That's using CTAD, but I suspect someone can come up with other examples that either break existing code, or will look inconsistent with new code.

You could somehow disambiguate, however:

std::vector v(std::something(s));
or
std::vector v(std::something, s);
etc

where 'something' is some specific type that vector recognizes (ie somewhat similar to how new is specialized for std::nothrow)


--
Be seeing you,
Tony
--
Std-Discussion mailing list
Std-Discussion@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion