Transience of .front in input vs. forward ranges

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Nov 5 20:46:06 PST 2012


On Tue, Nov 06, 2012 at 04:12:17AM +0100, Jonathan M Davis wrote:
> On Monday, November 05, 2012 18:36:53 H. S. Teoh wrote:
> > Hmm. Another idea just occurred to me. The basic problem here is
> > that we are conflating two kinds of values, transient and
> > persistent, under a single name .front. What if we explicitly name
> > them? Say, .copyFront for the non-transient value and .refFront for
> > the transient value (the names are unimportant right now, let's
> > consider the semantics of it).
> 
> I thought of this a couple days ago but threw it away fairly quickly,
> because it breaks _everything_. And it definitely affects all ranges
> for the sake of a few.
[...]

If we make .copyFront == .front, then things will still mostly work.
That is, all existing non-transient ranges and algorithms that expect
non-transient ranges will still work. Thanks to UFCS, only transient
ranges (which are "rare") need an explicit definition of .refFront.  If
nothing else is done beyond that point, then we are back to the case
where all ranges are non-transient, so everything works (just a tad
slow).

Then we can update algos that can handle transient values to call
.refFront instead of .front, and we have a similar sort of situation
with the .transient proposal, where only algorithms that can handle
transient values will get them. If indeed we want to support transient
ranges correctly, then those algorithms have to be updated anyway, so
this isn't much of an additional cost. Plus, we have reduced the amount
of code per range to just an additional member in the rare transient
range -- no extra range types are needed.

I don't know how much better we can get beyond this, as far as explicit
support of transient is concerned. No matter what we do, as long as we
acknowledge transient ranges as valid ranges, we have to, one way or
another, (1) update all transient ranges to use whichever scheme we
decide on, (2) update all transient-capable algorithms to handle
transience correctly. We can't do any less than this, from this
direction.

The alternative is either to reject all transient ranges, which
currently seems to be the least effort option, and also not ideal.


T

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton


More information about the Digitalmars-d mailing list