Transience of .front in input vs. forward ranges

[Jonathan M Davis]

On Sunday, November 04, 2012 20:36:32 H. S. Teoh wrote:
> No code duplication is actually necessary, even when the range is
> transient-capable. For example:
> 
> 	// New version of byLine
> 	struct ByLine {
> 		char[] buffer;
> 
> 		@property bool empty() {
> 			...
> 		}
> 
> 		@property char[] front() {
> 			// NOTE: non-transient by default
> 			return buffer.dup;
> 		}
> 
> 		void popFront() {
> 			...
> 		}
> 
> 		auto transient() {
> 			struct TransientByLine {
> 				ByLine innerRange;
> 
> 				// This is the only code that needs to
> 				// be "duplicated". Because it's
> 				// actually different!
> 				@property char[] front() {
> 					return innerRange.buffer;
> 				}
> 
> 				// empty, popFront, etc., just "inherit"
> 				// from the inner range. No code
> 				// duplication needed.
> 				alias innerRange this;
> 			}
> 			return TransientByLine(this);
> 		}
> 	}

How is that not duplicated? You have to create a second range type to support 
the transience. Sure, it's a thin wrapper, but it's yet more code that has to 
be put in a potentially large number of range types. It's yet one more thing 
that has to been maintained and tested. We need to be simplifying ranges, not 
complicating them yet further. They're already seriously pushing it in terms 
of how complicated they are. How many people outside of this newsgroup 
actually, properly understand ranges as it is?

The fact that we lack good articles and tutorials on ranges is obviously a 
major factor in making it so that many D users or potential D users don't 
understand ranges and std.algorithm. But if they're too complicated, even 
explaining them won't get us there. How many people do you know who fully 
understand how to properly use iterators in C++? A lot of C++ programmers 
understand them just well enough to get by and end up in trouble pretty fast 
if they try and do anything complicated with them. And ranges are arguably 
more complicated than iterators. We need them to be usable and understandable 
by the average programmer as much as possible, and that means trying to 
simplify them, not complicate them, especially when that complication is for 
an uncommon use case.

- Jonathan M Davis