On Saturday, 1 November 2014 at 14:01:42 UTC, Nordlöw wrote:
> On Saturday, 1 November 2014 at 13:36:05 UTC, anonymous wrote:
>> I don't see what you'd need inout for here. stealFront/stealBack are not methods.
>
> inout can be used on free functions aswell. See for example
>
> https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L674

Sure, but it doesn't buy you anything in these cases, does it? You can just drop inout from overlapInOrder. It's fully templated. T can be const/immutable and you get a const/immutable result. Works fine.

On Saturday, 1 November 2014 at 11:43:28 UTC, Nordlöw wrote:
> On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum wrote:
>> If you want move semantics, use `moveFront`.
>
> But x.moveFront doesn't modify x.

It does modify `x` as it leaves `front` in a destroyed and default-initialized state, as required by move semantics.

> What I want is to transform my uses of std.range from
>
> if (!x.empty)
> {
>     x.front.doStuff;
>     x.popFront;
> }
>
> into
>
> if (!x.empty)
>     if (auto front = x.stealFront)
>     {
>         front.doStuff;
>     }
>
> This is more functional/atomic, that is it reduces the risk of accidentally forgetting to call popFront at the end.
>
> Destroy!

The other half of my post explained why such a `stealFront` is problematic.

On Saturday, 1 November 2014 at 16:10:17 UTC, Jakob Ovrum wrote:
> The other half of my post explained why such a `stealFront` is problematic.

Got it. Thanks!

On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum wrote:
> Sometimes after popping, the previous `front` is no longer valid, such as in the case of a buffer being reused. We should

This seems like a error-prone design to me.

I guess performance is the motivation right?

Maybe a future data-flow analysis á lá Rust could come to the rescue here ;)

On Saturday, 1 November 2014 at 16:10:17 UTC, Jakob Ovrum wrote:
> problematic.

What about turning stealFront and stealBack at

https://github.com/nordlow/justd/blob/master/range_ex.d

into mixins?

On Saturday, 20 September 2014 at 19:23:46 UTC, Jakob Ovrum wrote:
> Sometimes after popping, the previous `front` is no longer valid, such as in the case of a buffer being reused.

Is there a suitable trait we can use to detect this and in turn use to disallow stealFront() and stealBack() in these cases?

 We should
> be careful about promoting using a previously read `front` after `popFront` until we figure out what we want to do about these "transient ranges".

On Saturday, 1 November 2014 at 20:48:45 UTC, Nordlöw wrote:
> Is there a suitable trait we can use to detect this and in turn use to disallow stealFront() and stealBack() in these cases?

Made it a separate new question at

http://forum.dlang.org/thread/onibkzepudfisxtrigsi@forum.dlang.org#post-onibkzepudfisxtrigsi:40forum.dlang.org

On Saturday, 1 November 2014 at 13:54:31 UTC, Nordlöw wrote:
> On Saturday, 1 November 2014 at 13:38:22 UTC, Marc Schütz wrote:
>> If you want to avoid the temporary variable, you could write:
>>
>>    scope(success) r.popFront;
>>    return r.moveFront;
>
> Does this solution cost performance?

I think DMD doesn't generate good code for it; IIRC it lowers scope(success) to a strange construct with an invisible variable and a try/catch. Don't know the reasons for this, maybe it has changed by now. Theoretically it would just need to move the contents of the scope(success) after the evaluation of the returned expression, which is cheap.

On Saturday, 1 November 2014 at 14:19:56 UTC, Nordlöw wrote:
> On Saturday, 1 November 2014 at 13:54:31 UTC, Nordlöw wrote:
>> On Saturday, 1 November 2014 at 13:38:22 UTC, Marc Schütz wrote:
>>> If you want to avoid the temporary variable, you could write:
>>>
>>>   scope(success) r.popFront;
>>>   return r.moveFront;
>>
>> Does this solution cost performance?
>
> I guess we have to look at the assembler output to be sure. Is there a convenient way to do this in LDC?

ldc2 -O3 -output-s -c test.d

Generates test.s.

On Sunday, 2 November 2014 at 11:46:19 UTC, Marc Schütz wrote:
> I think DMD doesn't generate good code for it; IIRC it lowers scope(success) to a strange construct with an invisible variable and a try/catch. Don't know the reasons for this, maybe it has changed by now. Theoretically it would just need to move the contents of the scope(success) after the evaluation of the returned expression, which is cheap.

Are there cases in LDC where

    auto e = r.moveFront;
    r.popFront;
    return e;

generates code less efficient than

    scope(success) r.popFront;
    return r.moveFront;

because of the extra assignment?