Deprecating Allocating Functions In std.string

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 4 November 2015 at 23:28:09 UTC, Jack Stouffer 
wrote:
> On Wednesday, 4 November 2015 at 22:42:19 UTC, Jonathan M Davis 
> wrote:
>> 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.
>
> Because there are two functions that do the exact same thing 
> that both need to be maintained. The fix for an existing code 
> base is as simple as a global find and replace for the function 
> name and change the type to auto.

And then slap an array() call on the end anyway. Sure, in some 
cases, you can replace a call to an eager function with a lazy 
one, but in many, you can't without first converting to an array, 
because the lazy function doesn't result in the right type of 
range. Lazy functions are frequently _not_ drop-in replacements 
for eager ones.

And as far as maintenance goes, if there's no really efficiency 
advantage to doing eager() over lazy().array(), then the 
internals of eager() can be changed to simply call 
lazy().array(), whereas if there _is_ an efficiency advantage to 
eager(), then we gain something by keeping it around.

>> And it's not like we're ever going to remove all of the 
>> GC-allocating stuff from Phobos anyway.
>
> We can remove as much as possible.

I really don't see any point in removing them when they work just 
fine. It's just going to cause code breakage. Those who want to 
avoid the allocations can just change their code to use the lazy 
functions, and those that don't care can just leave their code 
as-is. If we go and remove all of the existing eager functions, I 
expect that a number of folks will get ticked about the resulting 
code breakage and the fact that they end up having array() in a 
bunch of places in their code where they didn't have to before.

We're trying to avoid deprecating functions if we don't have to. 
Mass deprecations reduce our stability and hurt our PR. And a 
wholesale deprecation of eager functions goes completely contrary 
to that goal and without adding any real value.

>> 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.
>
> Again, I fail to see why you would ever need to use the 
> allocating versions of these functions when the non-allocating 
> versions perform the exact same tasks but faster.

Is it faster? If you don't actually need to allocate, then it 
likely is, but if you do need to allocate, then there's a decent 
chance that a version that was specifically written with that in 
mind is going to be be faster. And even if the lazy version _is_ 
faster, there are plenty of folks who would prefer the eager 
version simply because it's easier to use, and the efficiency 
gain doesn't mean anything in their particular use case.

We've been adding lazy versions of functions for years now, and 
we've never removed the eager versions. And I'm pretty sure that 
Walter and Andrei have generally been opposed to the idea of 
doing so precisely because of the code breakage that it causes. 
We have been moving towards using lazy range-based functions as 
much as possible and avoiding adding new eager functions, but 
that doesn't mean that removing the eager functions is worth the 
pain that that causes or even that the eager functions aren't 
worth having.

- Jonathan M Davis