On Friday, 27 December 2013 at 20:30:52 UTC, Ivan Kazmenko wrote:
Hmm?.. From my experience, attempting to use a range in a
wrong way usually results in a compilation error. For example,
I can't do
n.iota.map!(_ => readln).sort())
since MapResult isn't a random access range with swappable
elements. I can instead do
n.iota.map!(_ => readln).array().sort())
and it allocates an array and works as expected. So, how do I
misuse that range?
Yes, the idea is that ranges only present interfaces that make
sense, so cases of misuse will result in a compilation error.
However, hacks like using map with functions that ignore their
argument(s) throws that out of the window: `r` in `auto r =
n.iota.map!(_ => readln);` claims to support forward,
bidirectional and random access (all read-only, as the argument
function returns by value) as well as slicing, but none of these
make any sense; all access primitives do exactly the same thing,
with the result being different every time. Even the simplest
invariants fail, such as `r.front == r.front`, and `popFront`,
`popBack` and slicing only has a binary effect, whether or not
the range is empty yet.
Hmm. For example, that could be a RNG emitting (a range of)
random numbers, then "empty" is always false. But we still
want a new random number each time. Something like
n.iota.map!(_ => uniform(0, 10))
That would only provide `n` random numbers, not an infinite
number.
All the random number generator types in `std.random` are
infinite forward ranges of random numbers, which is completely
fine. For any PRNG `r`, `r.front == r.front` is true, and remains
the same number until `r.popFront()`, it correctly has no length
and is always non-empty (infinite range), and `r.save` works
correctly etc.
So, something like
n.iota.map !(_ => readln).writeln;
is bad style but
writeln (n.iota.map !(_ => readln));
better shows what's the main action? Makes sense for me.
No, it has nothing to do with syntax. The two examples are
completely equivalent, and the only problem is that it breaks the
invariant that the result of map's transformation function should
be derived from the arguments it was given. The fact that the
transformation function is impure is not in itself a problem:
pure functions can also ignore arguments, and impure functions
can return consistent results while still being necessarily
impure.
Perhaps there's a wholly different way of thinking about this
in which the first definition makes much more sense than then
second one from the start. If so, please share it.
All you have to do is look at the signature of the function,
which is the primary part of its documentation:
Repeat!T repeat(T)(T value);
It takes one value of any type T, not a function pointer or
delegate that returns T. Even if you give it a function pointer
or delegate (which your example does not), it will simply repeat
that function pointer or delegate, never calling it.
As I already explained, `readln.repeat(n)` is just a different
way of writing `readln().repeat(n)` which in turn is also
equivalent to `repeat(readln(), n)`. This should make it
perfectly clear what it does - `readln` is called and its return
value is passed to `repeat`. Barring one relatively obscure
exception[1], this is the only way to interpret the expression
regardless of the signature of the function, as a consequence of
basic languages rules common to the entire C family of
programming languages.
[1] ... in D we have something (slightly controversial) called
the `lazy` parameter storage class, but when used, it is clearly
visible in the signature of the function.
http://dlang.org/function.html#parameters
