On Sunday, 29 May 2016 at 11:36:37 UTC, ZombineDev 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:
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.
Scratch that:
Another option is to make popFront return a new range, ala
slice[1..$] (like std.range.dropOne) which would have the
benefit of allowing const/immutable ranges to work.
This won't work safely, because the compiler would need to
disallow access to the previous instance of the range (sort of
Rust moved-from objects), but it's currently no possible.
I proposed that idea because I have other uses for immutable
ranges, unrelated to this discussion.
Isnt the idea to communicate "hey! You may not possibly cache
whatever value you get in an iteration"? If yes, just removing
.front seems odd as, well, I can still obviously just cache the
result of .popFront if I'm inexperienced with ranges. Maybe
instead simply rename .front to .buffer for transient ranges?
That name would more accurately convey that this is just a buffer
the range uses to dump the current front value in, but that if
you want to cache it you will need to duplicate it (because, hey,
this is the buffer of the range, not yours).
Not sure this is a great idea or a great name, but simply
removing .front and returning the current iteration value from
.popFront imho does not convey "you should not expect to be able
to simply cache this by assignment" to me - arguably this is not
a problem since how transient ranges work would be a documented
thing, but thats just my 2 cents.
