Transience of .front in input vs. forward ranges

[H. S. Teoh]

On Thu, Nov 01, 2012 at 11:40:52PM +0100, deadalnix wrote:
> This is up to the consumer to choose if .front can be oblitered on
> popFront, not to an intermediate algorithm.
> 
> joiner isn't a consumer, this is a « transformer ». transformer have
> to propagate the .fast (I don't like this name, but this is
> unimportant for now) to its source.

What would be a better name for it?


> Let'(s consider the following sheme :
> source -> transformer (possibly several of them) -> consumer.
> 
> Now see example below :
> 
> auto transform(R)(R range) {
>     struct Transfomer(R) {
>         // Operations . . .
> 
>         @property
>         auto fast() {
>             return transform(source.fast);
>         }
>     }
> }
> 
> So the fast is used by the consumer and bubble throw all ranges that
> support it up to the source. Or is made a NOOP in the process in one
> of the transformers or the source do not support that optimization.
> 
> As said before, this is up to the consumer to know it it accept
> .front to be obliterated. In your case, writeln don't support that,
> so .fast must not be used with writeln.

Ah, I see. That makes sense. So basically it's not the source (or any
intermediate step) that decides whether to use the optimization, but the
final consumer.

Though now we have the issue that all intermediate ranges must propagate
.fast, which is troublesome if every range has to do it manually. Can
this be handled automatically by UFCS?


T

-- 
What doesn't kill me makes me stranger.