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.
I don't think that should be a huge problem, but after having
looked at the compiler code [1]: we should name it neither front
nor popFront, because how would the compiler know that it is
supposed to be transient and not a normal InputRange without
front or popFront for which it should throw an error?
Idea 1: New name that will make it easier to distinguish that
transient ranges are something completly different to normal
ranges.
How about next?
Problem 1: One can't use algorithms that work on transient ranges
(map, reduce) anymore
Idea 2: Help the compiler with @Transient or `enum transient =
true`
Problem 2: How would the "transientivity" be automatically
forwarded to ranges that work on it.
Btw thinking longer about it - transient ranges aren't bad per
se. They objey the InputRange contract and e.g. the following
works just fine. It's just impossible to distinguish between a
transient and a non-transient InputRange.
```
// input: 1\n2\n\3\n4\n...
void main()
{
import std.stdio, std.conv, std.algorithm;
stdin
.byLine
.map!((a) => a.to!int)
.sum
.writeln;
}
```
https://github.com/dlang/dmd/blob/master/src/statement.d#L2596
