Transient ranges

[Steven Schveighoffer via Digitalmars-d]

On 6/12/16 4:46 AM, Dicebot wrote:
> On Friday, 3 June 2016 at 12:03:26 UTC, Steven Schveighoffer wrote:

>> Yes, I can see good reason why you would want this. Hm... a set of
>> adapters which reduce a range to its lesser API would be useful here:
>>
>> array.asInput.map
>>
>> But an expectation for map should be that you want it to be exactly
>> the same as the original, but with a transformation applied to each
>> fetch of an element. I think it needs to provide random access if
>> random access is provided to it.
>
> That is matter of design philosophy. For me such basic library
> primitives warrant C++ attitude of "don't pay for what you don't ask
> for" - and everything else, including actual feature completeness, is of
> negligible importance compared to that. If keeping random access for map
> requires either caching or multiple evaluations of predicate, I want it
> to be banned by default and enabled explicitly (not sure what could be
> good API for that though).

So what it seems like you want is somerange.map(...).front to evaluate 
the lambda only once, without caching. This doesn't fit into the 
definition of ranges, which require the ability to access the same front 
more than once.

What you really want is a new kind of construct. It's not a range.

Given that front must be accessible more than once, map has to make a 
choice, caching or reevaluating. Not doing one of those two things is 
not an option for ranges.

Note that this has nothing to do with random access.

> Phobos indeed doesn't seem to make such priorities right now and that is
> one of reasons I am growing increasingly unhappy with it.

It's not so much that Phobos attempts to give you kitchen sink support 
at all costs, it's that if the sink being passed in has all the faucets, 
it'll forward them for free if possible.

>>>> Then it's not a bug? It's going to work just fine how you specified
>>>> it. I just don't consider it a valid "range" for general purposes.
>>>>
>>>> You can do this if you want caching:
>>>>
>>>> only(0).map!(x => uniform(0, 10)).cache
>>>
>>> Good advice. Don't want bugs with non-stable results and accidental
>>> double I/O in your long idiomatic range pipeline? Just put "cache" calls
>>> everywhere just to be safe, defensive programming for the win!
>>
>> Strawman, not what I said.
>
> But that is what your answer meant in context of my original question :)
> My complaint was about existing semantics are being error-prone and hard
> to spot - you proposed it by adding more _manual_ fixup, which kills the
> whole point.

No, it's not. My advice is to understand the limitations and 
expectations of the range wrappers you are using (i.e. read the docs 
[1]). If you need caching for your purposes, then do that by plopping 
cache at the end of your use case. The user must have to understand that 
providing a mapping function that does random things (or even varying 
things on each call) is going to result in unexpected behavior. The 
compiler cannot foresee the purpose of your lambda code.

You just said only pay for what you ask for. I don't want to pay for 
caching for map if I don't need it. I'd be pissed if map cached for 
something like map!(x => x * 2). If you want caching, then ask for it.

There was a talk by Herb Sutter on atomic operations on various 
platforms. His general rule was, as long as you don't write race 
conditions, and use only provided atomics, your code will do what you 
think. We can apply a similar rule here: as long as you write a lambda 
which for a given input will provide the same result, map will do what 
you expect. When you try odd things like your random call, we don't 
guarantee things will work like you expect. You may utilize the 
knowledge of how map works, and how the things that are using the map 
work to write something clever that breaks the rules. But no guarantees.

-Steve

[1] I admit, the map docs aren't explicit about this, and should be.