Transforming a range back to the original type?

Jacob Carlborg doob at me.com
Fri May 4 04:46:33 PDT 2012


On 2012-05-04 11:38, Jonathan M Davis wrote:
> On Friday, May 04, 2012 11:20:58 Jacob Carlborg wrote:
>> On 2012-05-04 09:01, Jonathan M Davis wrote:
>>> Something like that could probably only be done if every range in the
>>> potentially large chain of wrapped ranges provided a means of getting at
>>> what type the previous one in the chain was, and very few ranges - if any
>>> - do that.
>>>
>>> However, I'm not quite sure what toCollection would buy you. Why does it
>>> really matter what type of container the range comes from originally given
>>> that you have to create a new container to put the elements of the range
>>> into such a container? And if you're putting the elements of a range in a
>>> new container, you can pick whatever container type you'd like, and since
>>> it has no real connection to the original container, I don't see why it
>>> would matter whether it was the same type of container. All you really
>>> need is the equivalent of std.array.array for whatever container you want
>>> to construct, and the container's constructor should provide that.
>>
>> It's just like with the whole range idea, providing a common interface
>> for iterating over a collection (and some other stuff). Here the idea is
>> to have a common interface to transform the range back to a collection.
>
> But what's special about the original container type? Once the range has been
> wrapped, it doesn't really have any connection to the container - particuarly
> when elements are likely to have been transformed and/or skipped or added such
> that they're no longer strongly linked with the original elements. As far as I
> can tell, the original container type becomes pretty much meaningless at that
> point.

I give up. Apparently you don't think it's useful.

-- 
/Jacob Carlborg


More information about the Digitalmars-d-learn mailing list