Andrei Alexandrescu napisał: > > I know about Steven's proposal but it applies only to user types not > > primitives. Either way std.conv.to would need a buffered output range as > > integers are written from the right. Any chance for an abstraction > > analogous to buffered input ranges discussed recently? > > Generally I found it more difficult to define a solid output buffer > abstraction. This is a great motivating example though. > > To my surprise, an API of the same form seems to be what the doctor > prescribed. Here's a semi-formal definition: > > A buffered output range R is defined as such: > > R.front returns the currently uncommitted buffer of type T[] > > R.moreFront(n) makes n more elements available for writing > > R.commitFront(n) writes the first n elements in front() > > R.flushFront() writes the buffer currently held in front() and makes > another buffer available (initially empty).
I was thinking along the same lines. There's one missing: R.skipFront(n) skips the first n elements without outputting Why? Look at integral conversions in std.conv.to. It first calculates maximum string size, then writes numbers to the char array back to front, then returns result[$ - ndigits .. $] where ndigits is how long the string turned out. Returning to Steven's DIP, I think writeTo should take the above rather than void delegate(char[]). With the latter you still have to allocate the pieces. Our buffered output range is friends with polymorphism too. If you set T=char, its API is devoid of generics. Such interface can be placed in object.d with an official blessing. -- Tomek
