toString refactor in druntime

[Jonathan Marler via Digitalmars-d]

On Tuesday, 4 November 2014 at 02:49:55 UTC, Steven Schveighoffer 
wrote:
> On 11/3/14 6:05 PM, Jonathan Marler wrote:
>> In many cases templates are good because they provide the a 
>> way for the
>> programmer to use a library optimized for their particular 
>> application.
>> This is the case for the toString function.  An argument can 
>> be made
>> that using templates is dangerous because if they are used 
>> incorrectly,
>> the number of template instantiates can blow up.  But this can 
>> always be
>> solved by the programmer by changing all their template calls 
>> to use the
>> same template parameters.  This allows the template solution to
>> simultaneously support a sink that represents a real function, 
>> or a
>> delegate, or whatever the application needs.
>
> If we make toString a template, we precludes it as a virtual 
> function, and we force the object to expose its inner workings.
>
> I think the template solution has advantages, one being the 
> possibility for optimization. But I don't think the gains are 
> significant enough. It's also more complex than necessary.
>

I was thinking you could have the best of both worlds with 
templates.  For example, you could define the toString template 
like this:

   void toStringTemplate(T)(T sink) 
if(isOutputRange!(T,const(char)[]))

Then you could declare an alias like this:

   alias toString = toStringTemplate!(void 
delegate(const(char)[]));

Which (correct me if I'm wrong) I believe is equivalent to the 
original sink delegate function.  This allows programmers to 
write the logic for toString once and allow a developer using the 
library to choose whether they want to use the delegate version 
or the generic output range version.

This gives the user of the library the ability to choose the best 
version for their own application.

Note: I added this "alias" method to my dtostring.d test code and 
it wasn't as fast as the delegate version.  I'm not sure why as I 
thought the generated code would be identical.  If anyone has any 
insight as to why this happened let me know.

code is at http://marler.info/dtostring.d