toString refactor in druntime

[Walter Bright via Digitalmars-d]

On 10/31/2014 12:07 PM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Oct 31, 2014 at 12:04:24PM -0700, Walter Bright via Digitalmars-d wrote:
>> On 10/27/2014 12:42 AM, Benjamin Thaut wrote:
>>> I'm planning on doing a pull request for druntime which rewrites
>>> every toString function within druntime to use the new sink
>>> signature. That way druntime would cause a lot less allocations which
>>> end up beeing garbage right away. Are there any objections against
>>> doing so? Any reasons why such a pull request would not get accepted?
>>
>> Why a sink version instead of an Output Range?
>
> To allow toString to be a virtual function, perhaps?

Output ranges can be virtual functions. All an output range is is a type with a 
"put" method.


> Besides, the sink version basically allows encapsulation of an output
> range

The point of an output range is to encapsulate and abstract. Putting another 
wrapper around it just gives the impression we don't know what we're doing.


> -- instead of calling x.toString(outputRange) you just write:
>
> 	x.toString((const(char)[] data) { outputRange.put(data); });
>
> Most of the time, you don't even need to bother with this, because given
> an output range, formattedWrite("%s"...) will automatically figure out
> which overload of toString to call and what arguments to pass to it.

What I object to with the sink design is there is no consistency in design - we 
cannot preach ranges as a best practice and then use some other methodology.

BTW, just to be clear, I applaud fixing druntime to remove unnecessary GC 
allocations, and agree that with proper design most of the allocations can go 
away. It's just that sink and output ranges are both designed to solve the same 
problem in pretty much the same way. The difference appears to be little more 
than tomayto tomahto.