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?

On Sunday, 26 January 2014 at 12:01:18 UTC, Stanislav Blinov wrote:

> then only way to go about it is to return int by ref.

s/int/it/