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