Named parameters - double use

Named parameters. Wouldn't you just love it? Anyone who has had to suffer through using a C++0x Standard container with a custom allocator that can't be default-constructed has had to notice the abysmal repetitiveness of the other parameters you left as default.

However, there's another reason to allow named parameters- multiple variadic templates. They can be disambiguated by the use of naming the parameter they correspond to. Consider this snippet:

template<typename A, typename AArgs..., typename B, typename BArgs...> 
std::pair<A*, B*> make_heap_pair(AArgs&&... AArgsRefs, BArgs&&... BArgsRefs) {
    return std::pair<A*, B*>(
        new A(std::forward<AArgs>(AArgsRefs)...), 
        new B(std::forward<BArgs>(BArgsRefs)...)
    );
}


Of course, this is relatively contrived. What becomes not particularly contrived is a simplification of a constructor for std::set<T, CustomComparator, CustomAllocator> for example.

template<typename T, typename comparator = std::less<T>, allocator = std::allocator<T>> class set {
     comparator c;
     allocator a;
public:
    template<typename compargs..., typename allocargs...>
    set(compargs&&... compargsref, allocargs&&... allocargsref)
        : c(std::forward<compargs>(compargsref)...)
        , a(std::forward<allocargs>(allocargsref)...) {
        // Whatever
    }
};

Of course, this constructor is impossible in C++0x, because there'd be no way to know where one args list finishes and the next begins. So I sure hope that you don't need to construct your comparator or allocator in-place, because that kind of interface design is impossible. But it will be possible with named parameters. In addition, there will be flat out less overloads required, because we can insert parameters that are at the end of the list and leave the comparator as default.

In fact, and this is just a quick idea, technically, you could use it to disambiguate between two functions taking identical types as signatures.


void f(int x);
void f(int NumberOfSocketsToOpen);

int main() {
    f(
        x = 1
    ); // Not ambiguous
}

Whether or not that would actually be good, I'm not at all sure.