Is there a reason why popFront doesn't automatically return what
front does?
If so I'm still missing a combined variant of pop and popFront in
std.range.
Why isn't such a common operation in Phobos already?
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Moved here:
https://github.com/nordlow/phobos-next/blob/master/src/range_ex.d#L66
On Saturday, 20 September 2014 at 18:59:03 UTC, Nordlöw wrote:
Is there a reason why popFront doesn't automatically return
what front does?
If so I'm still missing a combined variant of pop and popFront
in std.range.
Why isn't such a common operation in Phobos already?
Sometimes after poppi
On Saturday, 20 September 2014 at 18:59:03 UTC, Nordlöw wrote:
Is there a reason why popFront doesn't automatically return
what front does?
If so I'm still missing a combined variant of pop and popFront
in std.range.
Why isn't such a common operation in Phobos already?
So far I know isn't c
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
be careful about promoting using a previously read `front`
after `popFront` until we figure out what we wa
On 09/20/2014 11:59 AM, "Nordlöw" wrote:
Is there a reason why popFront doesn't automatically return what front
does?
If so I'm still missing a combined variant of pop and popFront in
std.range.
Why isn't such a common operation in Phobos already?
It is also related to exception safety. It too
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.
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 fron
On Saturday, 1 November 2014 at 11:43:28 UTC, Nordlöw wrote:
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.
Forgot my explicit question:
So
On Saturday, 20 September 2014 at 19:40:02 UTC, AsmMan wrote:
Is this function part of phobos library? if so, where?
It's in std.range.
On Saturday, 1 November 2014 at 11:45:25 UTC, Nordlöw wrote:
So why isn't something like x.stealFront already in Phobos?
First try here:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
What's the recommended way of making stealFront and stealBack
inout here? Can I somehow use auto ref together with inout?
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 11:45:25 UTC, Nordlöw wrote:
So why isn't something like x.stealFront already in Phobos?
First try here:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
That is:
auto
On Saturday, 1 November 2014 at 13:25:03 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
What's the recommended way of making stealFront and stealBack
inout here? Can I somehow use au
On Saturday, 1 November 2014 at 13:30:16 UTC, anonymous wrote:
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 11:45:25 UTC, Nordlöw wrote:
So why isn't something like x.stealFront already in Phobos?
First try here:
https://github.com/nordlow/just
On Saturday, 1 November 2014 at 13:36:05 UTC, Marc Schütz wrote:
On Saturday, 1 November 2014 at 13:30:16 UTC, anonymous wrote:
[...]
auto ref stealFront(R)(ref R r)
{
import std.range: moveFront, popFront;
auto e = r.moveFront;
r.popFront;
return e;
}
[...]
It's probably intended to mean `aut
On Saturday, 1 November 2014 at 13:25:03 UTC, Nordlöw wrote:
On Saturday, 1 November 2014 at 13:22:34 UTC, Nordlöw wrote:
https://github.com/nordlow/justd/blob/master/range_ex.d#L14
Please comment!
What's the recommended way of making stealFront and stealBack
inout here? Can I somehow use au
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?
On Saturday, 1 November 2014 at 13:30:16 UTC, anonymous wrote:
`auto ref` is nonsense here. You can't return a reference to `e`
as
it's a local variable.
My mistake. Thanks.
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
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;
Nice solution anyhow! Thanks!
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 ha
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/
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
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
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 the
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, 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/onibkzepudfisxtri...@forum.dlang.org#post-o
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.moveF
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 d
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 jus
On Sunday, 2 November 2014 at 12:29:14 UTC, Nordlöw wrote:
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 th
32 matches
Mail list logo
