On Saturday, 28 May 2016 at 19:09:09 UTC, Stefan Koch wrote:
On Saturday, 28 May 2016 at 17:27:17 UTC, Joseph Rushton
Wakeling wrote:
On Saturday, 28 May 2016 at 01:48:08 UTC, Jonathan M Davis
wrote:
On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
So what about the convention to explicitely declare a
`.transient` enum member on a range, if the front element
value can change?
Honestly, I don't think that supporting transient ranges is
worth it.
I have personally wondered if there was a case for a
TransientRange concept where the only primitives defined are
`empty` and `front`.
`popFront()` is not defined because the whole point is that
every single call to `front` will produce a different value.
That is a rather sound idea.
I like this idea too!
`opApply` implies passing in a delegate which (if I am not
mistaken) implies the use of GC at the moment and isn't as easy
to optimize as `while (!file.empty) { writeln(file.front) }`