Proposal to deprecate "retro.source"

[Jonathan M Davis]

On Tuesday, November 06, 2012 18:05:27 monarch_dodra wrote:
> Thoughts?

We need to figure out how we want to handle source in general. There are some 
cases where it's really useful to be able to get at the original range - the 
prime example of this being functions like remove in std.container. The 
problem is that in most (all?) cases, you can't really use source without 
understanding how the wrapper range works, because the source doesn't 
necessarily have the same number or order of elements as the wrapper (e.g. if 
filter had source, the elements that source had could be very different from 
what the filtered range had, or in the case of retro, the order is completely 
different). In some cases, like retro and take, it's quite easy for the 
function accessing source to know how to handle it properly. In others, it 
gets far more complicated.

Andrei has expressed a desire to expose source in general. I don't know how 
wise that is or isn't, but it's something that needs to be explored.

In the case of retro, I think that it would good to have source exposed for 
std.container's use. It's easy for std.container to understand what retro's 
supposed to do, and use it accordingly, and I think that it would be silly for 
it have to call retro on the retroed range to do that. I do agree however that 
in general, it doesn't make sense to access source.

As for

> The problem though is in the way the documentation "The original 
> range can be accessed by using the source property" and "Applying 
> retro twice to the same range yields the original range": Looks 
> like we forgot to notice these two sentences are contradicting.

I don't see anything contradictory at all. If you call retro on a retroed 
range, you get the original. If you access source, you get the original. 
Where's the contradiction? In both cases, you get the original range.

So, I see no reason to deprecate retro's source.

- Jonathan M Davis