Transient ranges

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Tue May 31 08:45:58 PDT 2016


On Monday, May 30, 2016 09:57:29 H. S. Teoh via Digitalmars-d wrote:
> I'd argue that range-based generic code that assumes non-transience is
> inherently buggy, because generic code ought not to make any
> assumptions beyond what the range API guarantees. Currently, the range
> API does not guarantee non-transience, therefore code that assumes so is
> broken by definition.  Just because they happen to work most of the time
> does not change the fact that they're written wrongly.

Technically, the range API doesn't even require that front return the same
value every time that it's called, because isInputRange can't possibly test
for it. That doesn't mean that we don't expect that ranges behave that way.
It's never been the case that we agreed that transient ranges were
acceptable. In fact, it's pretty much the opposite. There was some
discussion that maybe we'd consider it legitimate for basic input ranges
given that we already had byLine doing it, and we didn't want to require
that it copy its buffer, but previous discussions on it made it quite clear
that most of us (Andrei included) thought that it should not be allowed for
forward ranges.

It's been the case for ages now that ranges with a transient front are not
explicitly supported. They happen to work with some algorithms (and you made
changes to Phobos to make them work with more algorithms there), but they're
not checked for, and there are algorithms that they don't and can't work
with. The simple fact that std.array.array doesn't work with them is pretty
damning IMHO.

We already have too many problems with unspecified behavior in ranges
without adding transient front into the mix. It should be killed with fire
IMHO.

- Jonathan M Davis



More information about the Digitalmars-d mailing list