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.
