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