Transience of .front in input vs. forward ranges

Jonathan M Davis jmdavisProg at gmx.com
Sun Nov 4 23:58:18 PST 2012


On Sunday, November 04, 2012 21:07:46 H. S. Teoh wrote:
> Stop right there. You're contradicting yourself. You kept saying that
> transient ranges are rare, abnormal, etc., and now you say they are a
> potentially large number of range types? I'm sorry, you've managed to
> utterly confuse me.  Are they rare, or are they not?
> 
> If they are rare, then this thin wrapper only needs to be written in
> those few rare cases. *No other range type needs to be changed.*
> 
> If they are common, then they aren't abnormal, and we should be fixing
> Phobos to deal with them. Everywhere. In a pervasive, invasive, large
> changeset, because almost all current code is broken w.r.t. to these
> common cases -- if indeed they are common.

Base ranges with transient fronts are rare, but as soon as you have to take 
them into account with wrapper ranges, then they potentially affect almost 
every range-based function in Phobos. So, you're taking a very rare case and 
forcing _everything_ to account for it. _That_ is why it affects a 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?
> 
> [...]
> 
> As I said, by having a UFCS version of .transient that simply returns
> the original range, you don't even need to know what .transient does.
> Don't even include it in your range, and it just behaves as a normal
> non-transient range. How is that any more complicated?

You can't just return the original range from a wrapper range and have it 
work. Take filter for instance, if you got at the range that it wrapped, you'd 
be completely bypassing filter, and the range wouldn't be filtered at all. Any 
and all wrapper ranges would have to take transient into account. If they 
couldn't do transient ranges, then they just wouldn't propagate or use 
transient. But if they could, then they'd have to create their own transient 
property which returned an appropriate range type which functioned properly 
with transience. Yes, it would use the transient property of the range that it 
was wrapping, but it would have to create its own transient property which 
functioned properly with whatever it was doing.

The _only_ way that this doesn't affect a lot of ranges in Phobos is if we just 
don't bother to propagate the transient property, and if we don't bother to 
propagate it, then there was no point in having it in the first place. Such 
ranges might as well have their own functions for iterating or just use 
opApply if no wrapper ranges are going to propagate their extra properties or 
if no range-based functions take those extra properties into account.

- Jonathan M Davis


More information about the Digitalmars-d mailing list