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

[H. S. Teoh]

On Mon, Jun 22, 2020 at 10:54:08PM +0000, Jon Degenhardt via Digitalmars-d wrote:
> On Monday, 22 June 2020 at 02:52:57 UTC, Andrei Alexandrescu wrote:
> > On 6/21/20 10:47 AM, Andrei Alexandrescu wrote:
> > One more thing before I forget - we should drop classes that are
> > ranges.  They add too much complication. The functionality would
> > still be present by wrapping a polymorphic implementation in a
> > struct.
> 
> I have used class-based ranges quite a bit to implement ranges with
> reference semantics. Classes are very convenient for this because the
> implementation is structurally very similar to a struct based
> implementation. Typically, replace 'struct' with 'final class' and
> modify a helper function constructing the range to use 'new'. It's
> amazingly easy.
[...]

Yeah, I rely on class ranges on occasion too, when runtime polymorphism
is required. They *are* cumbersome to use, though, I'll give you that.
If we're going to remove class-based ranges, then whatever replaces them
better have good support for runtime polymorphism, otherwise it's not
gonna fly.

This may be more common than people think. For example, sometimes I have
a range helper:

	auto myFunc(R)(R r, bool cond)
	{
		if (cond)
			return r.map!someFunc;
		else
			return r.filter!someFilter.map!someFunc;
	}

There is no way to make this compile (cond is only known at runtime),
because the return statements return diverse types, except to wrap it in
an InputRangeObject.

Though I only rarely need this, it's nonetheless critical functionality
because sometimes, you cannot know the exact range type until runtime,
and runtime polymorphism is unavoidable.  So this part of the current
range API cannot be just thrown out without a viable replacement.


T

-- 
Маленькие детки - маленькие бедки.