Transience of .front in input vs. forward ranges

deadalnix deadalnix at gmail.com
Thu Nov 1 15:40:52 PDT 2012


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.

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.


More information about the Digitalmars-d mailing list