toString refactor in druntime

[Walter Bright via Digitalmars-d]

On 11/7/2014 5:41 PM, Manu via Digitalmars-d wrote:
> On 3 November 2014 19:55, Walter Bright via Digitalmars-d
> This isn't anything to do with what I'm talking about. I'm not nervous
> because I don't like the D template syntax, it's because I don't feel
> it's a good idea for druntime (specifically) to have non-static
> interfaces which may expose, or create dependencies on druntime
> internals.

My point with the C macro interfaces is it's not the "template" that makes an 
API design non-static, it's the way the API is designed. Such a determination 
can only be made on a case by case basis, not a blanket templates-are-bad.


> The only library I would use as comparison is the CRT, which is firmly
> self-contained, with a well defined API.

Hardly. It still uses macros, and it's still quite sensitive to various struct 
declarations which are in the corresponding .h files. If you don't agree, take a 
look in druntime at all the conditional compilation for the various CRTs which 
presumably have the same API.

Check out fileno(), for example. Or errno. Or heck, just grep for #define in the 
C .h files, or grep for "struct{".


> That's fine. But how is that the case here? Performing a string
> conversion implies direct access to the data being converted. If the
> function is a template, then my app is directly accessing internal
> druntime data.

It all depends on how you design it. Recall that what defines an Output Range is 
the existence of put(r,e). There's no dependency on internals unless you 
deliberately expose it.


> I don't like being classified as 'the offense', in fact, I'm really,
> really tired of unfairly being assigned this position whenever I try
> and make a stand for things that matter to me and my kind.

Sorry, I thought you'd find the metaphor amusing. I didn't mean it to be 
offensive (!). Oops, there I go again!


> which is excellent, but replacing it with indirect function calls
> isn't awesome. This takes one problem and replaces it with a different
> problem with different characteristics.

I think this is a misunderstanding of output ranges.


> I would like to see an overload like the C lib; API receives memory,
> writes to it. This may not be the API that most people use, but I
> think it should exist.
> I then suggested that this API may be crafted in such a way that the
> higher-level goals can also be expressed through it. It could be
> wrapped in a little thing that may request a memory expansion if the
> buffer supplied wasn't big enough:
>
> struct OutputBuffer
> {
>    char[] buffer;
>    bool function(size_t size) extendBuffer; // <- user-supplied
> (indirect) function that may expand the buffer in some app-specific
> way.
> }
>
> toString writes to 'buffer', if it's not big enough, ONLY THEN make an
> indirect function call to get more memory.  API is the similar to the
> synk callback, but only used in the rare case of overflow.

We're reinventing Output Ranges again.


> I don't know exactly, other people have much more elaborate needs than
> myself. I'm just saying I don't like where this API is headed. It
> doesn't satisfy my needs, and I'm super-tired of being vilified for
> having that opinion!

Well, my opinion that sink should be replaced with output range isn't very 
popular here either, join the club.


>    * toString should be capable of receiving a pre-allocated(/stack)
> buffer and just write to it
>    * indirect function calls should only happen only in the rare case
> of output buffer overflow, NOT in all cases

Again, this is reinventing output ranges. It's exactly the niche they serve.


> I don't think that's what's on offer here. If toString is a template
> (ie, receives an OutputRange, which is a user-defined type), how can
> it be that the user's instantiation would already be present in
> druntime?

If one uses an output range that is imported from druntime, which is quite 
likely, then it is also quite likely that the instantiation with that type will 
already be present in druntime.