Problem with using struct ranges with @disabled this(this) with some range functions

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 2 September 2015 at 06:28:52 UTC, Uranuz wrote:
> As far as I understand to save current cursor of forward range 
> I should always use *save* property. But sometimes range struct 
> is just copied using postblit without using save (it happens 
> even in Phobos). Is it correct behaviour to *pass ownership* 
> for range structs via just copying of range or not. As I think 
> for at least *forward* ranges that are structs we must always 
> use save methot to store new cursor. But for *input* ranges it 
> is not possible, so there maybe plain copying could be allowed. 
> I thing that we should work out some descision on this problem, 
> provide some unittests for different types of ranges with and 
> without postblit for standard Phobos functions and fix them 
> accordingly.
>
> I have problem with std.range.take function and forward range 
> with disabled postblit and I don't understand is it my or 
> library bug?

My understanding is that one underlying assumption in Phobos 
about ranges is that they are lightweight and single-minded -- 
they should carry no state other than what is necessary to 
fulfill the range interface they provide. This follows from the 
idea that, given a container, you do not slap a range interface 
on the container type and pass container instances to range-based 
functions, but instead implement a range type separate from the 
container that knows where the elements of the container begin 
and end and nothing else. They do not carry the elements of the 
container around with them.

Looking at ranges from that angle, the need to disable postblit 
on a range type would be a special case. That raises the 
question, for what reason have you disabled postblit on your 
range type? Is it not possible for you to create a lightweight 
range from your data?