Why does `filterBidirectional` exist, and why isn't it called `filter`?

[Steven Schveighoffer]

On 3/9/23 4:16 PM, Paul Backus wrote:
> On Thursday, 9 March 2023 at 19:48:21 UTC, Steven Schveighoffer wrote:
>> On 3/9/23 12:07 PM, Paul Backus wrote:
>>> I think probably you have to go on a case-by-case basis. 
>>> `File.byLine`, for example, does not and should not precompute 
>>> `front`, because doing so is potentially very expensive. OTOH, `iota` 
>>> does and should precompute `front`, because doing so is essentially 
>>> free and makes the implementation much simpler.
>>
>> I disagree. If you construct a `byLine` you intend to iterate by lines.
> 
> I gave examples in my post of situations where the user may construct a 
> range before deciding whether or not to iterate it. If you find those 
> examples unconvincing, I'd be happy to hear why.

`choose(cond, a(), b())` could evaluate the parameters lazily, and then 
it doesn't matter if a() or b() precomputes. In fact, the implementation 
ignores one of them anyway.

For chain, it's more complex, because you don't know when the 
initialization will need to happen. But I'm also fine with that 
consequence in exchange for simplification of expectations.

Let's say it's `chain(File("foo.txt").byLine, File("bar.txt").byLine)`. 
It's going to be expensive to open the file, but not really any more 
expensive to read the first data into the buffer (the disk cache will 
have it ready for you). So you don't save anything significant. However, 
you lose on the congnitive load for *all* uses of byLine, and indeed all 
ranges now have a semantic parameter that you have to either "just know" 
or read the docs/implementation.

We already have very complex situations that happen because of the 
interactions between range initialization and iteration. Most of them 
happen when you expect lazy or eager, and the other is chosen. I think 
we should just pick one, and say, it's always that way, and if you want 
something different, you need wrappers.

-Steve