Re: [Boost-users] [Boost.Assign] list_of::range without an initial (single) element?

Subject: Re: [Boost-users] [Boost.Assign] list_of::range without an initial (single) element?
From: Michael McNeil Forbes (michael.forbes_at_[hidden])
Date: 2010-06-16 14:49:53

Thorsten Ottosen wrote:
> Nat Goodspeed skrev:
>>
>>>>> However, list_of<int>() inserts a default value (so that
>>>>> list_of<int>().range(a).range(b) == {0,1,2,3,4}).
>>>
>>> Maybe we should add
>>>
>>>   empty_list_of<int>()
>>>
>>> ? It's quite trivial to add.
...
>> Maybe introduce no-params list_of<T>() to produce an empty list,  
>> while list_of<T>(const T&) keeps its current implementation? That  
>> would seem to behave intuitively in both cases...
>
> Just to be clear, you want list_of() to be empty_list_of<*any  
> type*>(), and for the type of the list to be deduced by the first  
> argument:
>
>  list_of()(42);
>
> would be a list of ints with one value (42).

This is what I was expecting when I first started.  Semantically this  
behaviour seems to make sense, but I have not thought too deeply about  
it.

> If so, I think this syntax is possible, but I am worried that the  
> difference between list_of() and list_of<T>() is too subtle.

What exactly would be the subtle difference between these two?   Would  
they not both be forms of empty lists, except the second form would  
only accept arguments of type T?

The other thing I was expecting was perhaps an exposed range()  
function so that one can just go:

... = range(a).range(b)

(I also thought that the exposed repeat() functions would also allow  
for this:

boost::array<int, 4> c = boost::assign::repeat(4, 5);

use but I apparently do not understand yet how the exposed repeat is  
intended to be used.)

I have to look more deeply into the new proposal for operator&&(), but  
it seems a little specific.  Is there no way that the ideas discussed  
here could be made as efficient, requiring a separate operator&&() for  
chaining?  As a user, I would not mind being steered towards the  
efficient usage if documented properly.

Michael.