std.stringbuffer

[Bruno Medeiros]

Frits van Bommel wrote:
> Bruno Medeiros wrote:
>> Janice Caron wrote:
>>> 2008/4/30 Bruno Medeiros <brunodomedeiros+spam at com.gmail>:
>>>>  Also, is there a reason why these mutable functions shouldn't be in
>>>> std.string, together with their invariant/const brethren?
>>>
>>> That's why we're having this discussion.
>>>
>>> The idea is that std.string can be optimised for invariant strings,
>>> while std.stringbuffer could be optimised for mutable strings. There
>>> are pros and cons for separate modules. I don't think Walter wants
>>> std.string "polluted" by all these functions he doesn't much care for.
>>> Also, it would be bad if mutable versions were called "by mistake"
>>> with consequent unexpected behavior.
>>>
>>
>> "mutable versions were called "by mistake" "? I don't think that point 
>> applies to D, after all, the purpose of the immutability system is for 
>> the compiler to check that this won't happen, so unless there is some 
>> compiler bug, that shouldn't happen in D.
> 
> What if you wanted a modified copy of the input, but that input happened 
> to be mutable?
> 

Hum, I see what you mean, yes, that could happen.

> The modifying versions should have some distinguishing characteristic to 
> separate them from the COW versions. I'd say either a different function 
> name or an extra out-buffer parameter (as long as they still work if the 
> buffer is the same array as the normal input).

Yes, the idea to distinguish them with a different name sounds good 
(names like "doToUpper", maybe?). So that means you agree it should be 
in the same package? :P

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D