Deprecating Allocating Functions In std.string

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 4 November 2015 at 16:17:29 UTC, Jack Stouffer 
wrote:
> Looking through the source code of std.string, a lot of the 
> functions that allocate have range based non-allocating 
> alternatives that accomplish the same task. I'm wondering if 
> there is any specific reason to keep the allocating versions 
> around? If there are two functions in the same module that 
> perform the same task, why not do the cycle of 
> deprecation->remove docs->remove on the allocating version, as 
> the other function is clearly better. Also, it's more GC 
> handling code that would be removed, which is good for PR 
> reasons.

And why break the code that uses them? They work just fine, and 
for many programs, the allocation is a non-issue and simply 
getting a string back rather than a range is more user-friendly. 
We probably wouldn't add functions like them at this point 
(particularly if we already had the range-based ones), but I 
really don't see any point in removing them. And even if it were 
good PR to remove GC-allocating functions, it's bad PR to break 
existing code, so it needs to have a solid reason as to why it's 
worth it, which I don't think that we have in this case. And it's 
not like we're ever going to remove all of the GC-allocating 
stuff from Phobos anyway. Some stuff needs it. We just want to 
make it so that the GC is not required by the code when it's not 
actually required to do what the code does. And if we have an 
eager function that allocates and a lazy one which doesn't, we've 
provided the @nogc option for that functionality already.

- Jonathan M Davis