std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]

[H. S. Teoh]

On Wed, Jun 24, 2020 at 12:29:13PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 6/24/20 12:25 PM, Adam D. Ruppe wrote:
> > I'm barely reading this thread, but could @live be useful with input
> > ranges too?
> 
> I'm not sure, but with a no-quarter-given approach to copying input
> ranges, simple tasks like "feed input from this file, or from stdin,
> and output to this other file or to stdout" mutate from trivial into
> little research projects (btw by the same (misguded imho) arguments
> "pure" output ranges ought to also be noncopyable).

I second this.  Whatever we decide to do about the input range / forward
range distinction, it should absolutely not cripple input ranges or make
them so different that you have to write two versions of the same
algorithm just to handle both cases.

For all of its flaws, the current range API does a beautiful job of
unifying the two (to the extent possible, modulo well-known bugs /
design limitations) so that, for the most part, you can ignore the
difference.  As long as .save isn't required, you could freely feed
either an input range or a forward range to any range algorithm, and
freely compose such algorithms, and it all Just Works(tm).

I propose that whatever new design we settle on for input ranges, it
should preserve this user-facing simplicity.  What we want is a design
where simple things are simple, and hard things are possible, not a
design where simple things are hard and hard things are nigh impossible.
To the extent possible, we should try to preserve symmetry between input
and forward ranges. (By "symmetry" I mean that as long as the equivalent
of .save isn't required, an input range and an output range ought to be
transparently interchangeable. A kind of Liskov Substitution like
principle applied to ranges.)


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy