Re: [boost] Re: container design (Was: std::complex design (Was: N-Dimensional array))

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-03-11 13:07:57

On Monday, March 11, 2002, at 12:22  PM, Rainer Deyke wrote:

> ----- Original Message -----
> From: "Howard Hinnant" <hinnant_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Monday, March 11, 2002 7:12 AM
> Subject: Re: [boost] Re: container design (Was: std::complex design
> (Was: N-Dimensional array))
>
>
>>> The way I approach these things is by being explicit:
>>>
>>> template<class F> vector::vector(size_type n, init_tag, F f);
>>
>> If that's not an iron clad argument in favor of restricted templates
>> then I don't know what is. ;-)
>
> Restricted templates won't necessarily do the right thing.
>
> class initializer {
> public:
>   template<class T> void operator()(T *, size_t);
> };
>
> std::vector initializers(100, initializer());

Quite true.  But in this case, neither will manual implementation of the 
"do-the-right-thing" clause.  At least with restricted templates, the 
requirements on the template argument become part of the method's 
interface, instead of buried in the code (or buried in the 
documentation ... standard in this case).

We already have the problem today with the iterator template members.  
Consider:

struct BigNum
{
     operator std::size_t() const;
};

std::vector<BigNum> v(BigNum(), BigNum());

I'll bet this won't compile on your platform today (it won't compile on 
mine either).  And actually, according to the "do-the-right-thing" 
clause in the standard, it doesn't have to because BigNum is not an 
integral type.  But there's nothing in vector's interface that says that 
the above example should not compile while this example should:

std::vector<int> v(10, 0);

Both of these constructors bind to:

template <class InputIterator>
vector(InputIterator f, InputIterator l, const Allocator& a = 
Allocator());

But under the covers (somehow) the implementor must make v(10, 0) behave 
as if it bound to:

vector(size_type n, const value_type& x);

It would be so much more understandable, readable and predictable if the 
signature for the member template constructor could have been written:

template <class InputIterator : 
!numeric_limits<InputIterator>::is_integer>
vector(InputIterator f, InputIterator l, const Allocator& a = 
Allocator());

Then we can read right out of vector's interface, ok InputIterator can't 
be an integer according to numeric_limits.  The effect is the same as 
23.1.1/9, just more clearly defined.

Now that we have is_convertible, a better constraint might be to make 
sure that InputIterator can not convert both to a size_type and to a 
value_type.  That would allow the BigNum example above to work as well.  
With restricted templates, it is quite straight forward to change the 
constraint, now that we know of a better one.  Without restricted 
templates, changing the template constraint is much less straight 
forward.  So much so that seasoned C++ programmers either aren't sure 
how to do it, and/or resort to augmenting the function signature with 
tags to disambiguate the situation.

Assuming that part of the standard library's role is to display design 
worthy of emulation by Joe Programmer (the STL has certainly done 
this!), it seems clear to me that this is not just a problem in 
implementing the std::lib.  Dealing with this problem is something any 
programmer might face.  I think we can give the programmer better tools 
for this problem with minimal effort and no backwards compatibility hit.

-Howard