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
