Scott Michaud via Std-Proposals:
> Do the library maintainers have any established opinion about strongly typing parameters that can be ambiguous?

I was thinking about making size_type and difference_type strong types. Perhaps with a shallow semantics. As in

std::vector<Foo>::size_type is std::allocator_traits<std::allocator<Foo>>::size_type but it is simply a class with raw integer
template parameter. For example std::containers::size_type<unsigned long long>.

Deep semantics would actually encode the whole container as template parameter like so:

std::containers::size_type<std::vector<Foo>>

This will make the following code ill-formed:

std::vector<Foo> a;
std::vector<Bar> b;
auto c = a.size() + b.size();

Because the containers are unrelated so their sizes are unrelated too. Of course, going this route is maybe too much.

>
> I'll illustrate what I mean with a concrete use case: std::vector.
>
> In C++, there is a constructor that takes a single size_type and creates a vector with n default-constructed elements.

This is definitely one of the worst blunders in standard library.

std::vector<int> v1(42, 42);
std::vector<int> v2{42, 42};

Produce completely different things. Have we had something like

std::vector<int> v1(std::containers::size_type{42}, 42);

Results would be slightly better, but it would produce problems with std::vector<std::containers::size_type<...>>. Initializer
list ctors really need different syntax.