On Sunday, 29 May 2016 at 15:45:14 UTC, Joseph Rushton Wakeling
wrote:
On Sunday, 29 May 2016 at 11:28:11 UTC, ZombineDev wrote:
On Sunday, 29 May 2016 at 11:15:19 UTC, Dicebot wrote:
I would prefer such ranges to not have `front` and return new
item from `popFront` instead but yes, I would much prefer it
to existing form, transient or not. It is impossible to
correctly define input range without caching front which may
not be always possible and may have negative performance
impact. Because of that, a lot of Phobos ranges compromise
`front` consistency in favor of speed up - which only seems
to work because most algorithms need to access `front` once.
I believe this is biggest issue in D ranges design right now,
by large margin.
+1
I think making popFront return a value for transient ranges is
a sound idea. It would allow to easily distinguish between
InputRange and TransientRange with very simple CT
introspection. The biggest blocker is to teach the compiler to
recognize TransientRange types in foreach.
I don't follow your reasoning here. In the proposal I put
forward, if a range doesn't define `popFront()`, it's not an
InputRange, it's a TransientRange.
Conversely, if it _does_ define `popFront()`, it _is_ an
InputRange.
What's the problem with introspecting that?
Yes it can be introspected in library, but it breaks the
expectations of the unsuspecting user. For example:
auto r = getSomeRange();
assert (r.front == r.front);
So, under your suggestion, the above could fail just because an
implementation detail was changed like modifying some input range
to become a transient range and somehow the code still compiled.
Now I'm leaning more towards the buffer + popFront + empty trio,
because it's harder to misuse.
An alternative would be tagging such ranges with an enum or UDA,
but we would need to verify/change too many places in phobos for
this to work.
