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?
Nothing. Just that it could lead to a lot of surprising mistakes,
currently the following yields an error:
struct A
{
auto front(){ ...}
enum empty = false;
}
A as;
foreach (a; as) {} // ERROR: no method popFront found
with the proposed change it would compile.
