Transforming a range back to the original type?

[Jonathan M Davis]

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.

You should be able to put the elements that are in the range in whatever 
container type you want (which you can currently do very easily with arrays 
thanks to std.array.array and should be able to do with std.container's 
containers with their constructors), so you can put them in whatever container 
type is appropriate for whatever you're going to do with the elements. But I 
don't see how the _original_ container type matters for any of that.

And when you consider that it's quite possible for a range to have no 
connection to a container whatsoever (e.g. anything in std.random), I just 
don't see how you could generically get at the type of the original container 
anyway (since there may not be one). Best case, you could create variable or 
alias which a range type _could_ have but doesn't necessarily have (similar to 
save or back) which could then hold the original container type (effectively 
creating yet another genre of range). But again, I don't see why that would 
actually be useful.

- Jonathan M Davis