*Should* char[] be an output range?

[Jonathan M Davis]

On Monday, September 02, 2013 10:04:20 monarch_dodra wrote:
> I'm finalizing work on improvements to "put". The main
> improvement is that put will now be able to transcode on the fly,
> allowing it to do things such as putting a dchar into char sink.
> 
> What this means is that "(const(char)[]){}" is now considered an
> output range for dchar. This wasn't the case before, and a source
> of bugs in functions like formattedWrite: They didn't get much
> visibility, since Appender (the sink of choice for tests) can do
> it natively. But passing a delegate char sink to formattedWrite
> often ended in error.
> 
> In any case, my main question is:
> 
> *currently*, "char[]" isn't considered an output range. Shouldn't
> it though? The rationale is that it contains dchar elements, and
> we don't know how to "put" a dechar in a char[]'s front. But we
> do now.
> 
> Was this just an implementation restriction? Or is there a real
> good reason to not allow it?
> 
> In my code, it's a one line tweak to "unlock" char[] as a full
> fledged output range for char/wchar/dchar/string/wstring/dstring.
> Should I do it?

The main problem has to do with what you do when there's not enough room to 
write to it. Even checking the length isn't enough, because it's unknown ahead 
of time whether a particular code point (or string of characters if calling 
put with multiple characters) will fit - at least not without converting the 
character to UTF-8 first, which would incur additional cost, since presumably 
that would result in it being converted twice (once to check and once when 
actually putting it).

Of course, it's a problem in general with output ranges that we haven't defined 
how to check whether put will succeed or what the normal procedure is when 
it's going to fail. My first suggestion for that would be to make it so that 
put returned whether it was successful or not, but it's something that 
probably needs to be discussed. However, with that problem solved, it may be 
reasonable to make char[] an output range.

But until we sort out some of the remaining details of output ranges (most 
particularly how to deal with put failing, but there are probably other issues 
that I'm not thinking of at the moment), I don't think that it's a good idea 
to change how char[] is treated, since how all of that is sorted out could 
have an effect on what we do with char[].

- Jonathan M Davis