A question about move() and a rant about shared

Stanislav Blinov stanislav.blinov at gmail.com
Sun Jan 26 04:01:17 PST 2014


On Sunday, 26 January 2014 at 07:21:15 UTC, Stanislav Blinov 
wrote:
> On Saturday, 25 January 2014 at 18:47:17 UTC, Andrei 
> Alexandrescu wrote:
>
>>
>> We plan to disallow taking address of a ref return from a 
>> function.
>>
>
> What about sneaky cases? E.g. like this:
>
> NullableRef!T nref(T)(ref T v) { return NullableRef!T(&v); }
>
> struct Container(T) {
>     //...
>     ref inout(T) front() inout { ... }
> }
>
> Container!int cnt;
>
> //...
>
> auto n = nref(cnt.front());

I believe I need to clarify the question.

If a type stored in container has @disabled this(this), then then 
only way to go about it is to return int by ref. Ranges iterating 
over this container should respect that, right?
But in that case, most of the tasty features of std.range would 
cease to work,
because they rely on an assumption that an element could be 
forwarded through the interfaces of all involved ranges during 
the front() call.

For example, std.range.lockstep: it won't compile for ranges that 
return by ref, because isInputRange expects { auto x = r.front(); 
} to compile, and it won't (copying is disabled). Currently this 
could be circumvented by using that NullableRef "trick" from 
above.

How would we go about forwarding ref through the interface of 
ranges if taking the address will not be allowed?


More information about the Digitalmars-d mailing list