On Saturday, 28 May 2016 at 21:32:15 UTC, Brad Roberts wrote:
On 5/28/2016 10:27 AM, Joseph Rushton Wakeling via
Digitalmars-d 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.
Um. that's wrong, just look at byLine as evidence. It is
popFront that changes the value to the 'next' one in the
iteration. Front called twice in a row does NOT change the
value, and shouldn't. I think you're misunderstanding
something.
I'm not talking about how byLine currently behaves. I'm talking
about a meaningful API that could be used for a range that (by
design) has a transient front, that would be unambiguous in its
behaviour.
