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