refRange with non copyable struct

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, April 17, 2017 17:23:32 Jerry via Digitalmars-d-learn wrote:
> Hello guys, so I wanted to have a noncopyable range on the stack.
> So my thoughts was to make it non copyable and use refRange
> whenever I want to use it with map and others.
>
> But I got a compiler warning when doing so like this:
>
> import std.range;
>
> void main() {
>   NonCopyable v;
>
>   refRange(&v);
> }
>
> struct NonCopyable
> {
>   @disable this(this);
>
>   int data;
>
>   enum empty = false;
>   void popFront() {}
>   int front() { return data; }
> }
>
>
>
>
>
> With the error message:
>
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(8941):
> Error: struct reproduction.NonCopyable is not copyable because it
> is annotated with @disable
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(8982):
> Error: mutable method reproduction.NonCopyable.front is not
> callable using a const object
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(9649):
> Error: template instance std.range.RefRange!(NonCopyable) error
> instantiating
> reproduction.d(6):        instantiated from here:
> refRange!(NonCopyable)
>
>
>
>
> Is there any workaround?
> Is this a bug?

Well, I don't think that much range-based code in general is going to work
with a disabled postblit constructor, and it's not something that's
generally tested for unless someone is specifically trying to use such a
type with a specific piece of code. Non-copyable types tend to wreak havoc
with things - not that they shouldn't necessarily work, but most stuff tends
to assume that types are copyable, and supporting non-copyable often
complicates things quite a bit. Most of Phobos simply hasn't been tested
with non-copyable types even if the functionality in question should
arguably work with them.

In this particular case, it looks like the main problem is RefRange's
opAssign. For it to work, the type needs to be copyable. It might be
reasonable for RefRange to be enhanced so that it doesn't compile in
opAssign if the range isn't copyable, but I'd have to study RefRange in
depth to know what the exact consequences of that would be, since it's been
quite a while since I did anything with it. My guess is that such a change
would be reasonable, but I don't know without studying it.

- Jonathan M Davis