Bitwise ranges

[Stanislav Blinov]

Hello,

I'm working on range adapters that should allow reading and writing 
individual bits from/to other ranges. Right now for simplicity I only 
allow that for ranges that have numerics as ElementType.

Making an input bitwise range is pretty straightforward: popFront on 
original range is called as soon as all bits from it's 'front' have been 
read.

What I'm stuck with is an output bitwise range. If the adapted output 
range works via mutable front/popFront mechanism, implementing bitwise 
output is almost identical to bitwise input. But when adapted range 
provides output interface via put() method, I have no possible way to 
output data bit-by-bit. What I can do is a deferred put(), e.g. store a 
buffer in the bitwise range which I would fill with bits and put() it 
into adapted range as soon as all its bits have been written.
This may expose additional interface for clients: when bitwise range is 
'done' with adapted range, there may be a remaining partially filled 
buffer, which must also be put() into adapted range. This, in turn, may 
be done either implicitly (via destructor) or explicitly (via, e.g. 
complete() method of bitwise range).

Now I have a feeling that this somewhat falls out from standard range 
mechanisms. Consider:

ubyte[] input = [ 1, 2, 3 ];
uint[] output = new uint[1];

copy(bitwiseRead(input), bitwiseWrite(output));

Let's assume that output would only allow put() method. Now what copy() 
does is call popFront() on bitwiseRead and put() on bitwiseWrite. But no 
data would actually be written into output during copy(). Instead, there 
would be bits accumulated inside bitwise adapter when copy() returns, 
and they would be put() into output 'silently', without copy() 
explicitly asking for it.

Are such 'deferred popFront/deferred put' approaches a 'good' way to go 
with ranges? Or should bitwise adapter's popFront()/put() method always 
call popFront()/put() on adapted range?