Generality creep

[H. S. Teoh]

On Thu, Mar 28, 2019 at 05:33:33PM +0000, Luís Marques via Digitalmars-d wrote:
> On Thursday, 28 March 2019 at 17:04:58 UTC, Andrei Alexandrescu wrote:
> > The overall message is we got bogged down on the "wrong" side of
> > generality - cross-cutting and nonscalable code additions to support
> > unprincipled and low-impact corner cases.
> 
> Having a document that formally specifies what a range is and what its
> properties are might have helped with that and a lot more. It would
> still help with all of the issues yet to come.

Yes, the range API needs a formal, precise spec that leaves no holes.
Currently, the semantics of .save is one such issue.

Another issue is what we used to call "transience": is the return value
of .front required to persist past the next invocation of popFront?
std.stdio.File.byLine is a big example that does *not* respect this, and
as a result several Phobos algorithms cannot be used with it without
incurring buggy behaviour.  OTOH, supporting transience means code like
the following won't work:

	auto e = r.front;
	r.popFront;
	if (r.front == e) ...

because e becomes invalid after .popFront.  Last time I checked, several
Phobos algorithms freely use this kind of construct (saving the value of
.front and checking it later), which means it doesn't work with
transient ranges.

We need a clear decision as to whether transient ranges are supported.
If not, std.stdio.File.byLine needs to be deprecated. Or if they should
be supported, then the range spec should clearly state that it is
illegal to save the value of .front and expect it to remain valid after
.popFront is called. (Personally, I lean towards the latter option, but
either way, this needs to be stated clearly and explicitly in the range
spec.)


T

-- 
Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln