On 5/29/16 7:28 AM, ZombineDev wrote:
On Sunday, 29 May 2016 at 11:15:19 UTC, Dicebot wrote:
On 05/28/2016 08:27 PM, 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.
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.
This doesn't help at all. I can still make a "transient" range with all
three range primitives.
There seems to be a misunderstanding about what a transient range is.
byLine is a transient range that requires the front element be cacheable
(I have to build the line somewhere, and reusing that buffer provides
performance). Shoehorning into a popFront-only style "range" does not
solve the problem. Not only that, but now I would have to cache BOTH the
front element and the next one.
-Steve
