Naming of new lazy versions of existing Phobos functions

[Walter Bright via Digitalmars-d]

On 7/18/2014 12:40 PM, Tourist wrote:
> Are you planning to deprecate the non-lazy functions at some (maybe very
> distant) point?

No. Phobos has already gone through multiple rounds of renaming/deprecation, all 
at considerable disruption. Each one was supposed to be "worth it" and the "last 
time". It needs to stop.


> If yes, I agree that it's a good opportunity for a cleanup, and
> there's no point to add prefixes/suffixes.

I object to the characterization that changing the names is a "cleanup", as if 
the current names are just screwups.


General comment (not particularly directed at Tourist):

There is no such thing as the perfect set of names and the perfect naming 
convention. These discussions about which of "car", "auto", "vehicle" is more 
intuitive give the illusion of sage discussions on issues of note, but are 
really just bikeshedding. There is no correct solution, and no possibility of 
consensus. Coding styles and best practices also change, making earlier name 
choices seem quaint, but that still doesn't justify renaming them all to the 
latest fashion.

I can't understand any user caring if a function is named "setExt" or 
"setExtension" or "withExtension". It's more like he needs a function that sets 
a filename extension, he finds it, uses it, and moves on.

What matters is what setExt() actually does, which is provide a lazy algorithm 
designed to be composable and not make decisions about how needed memory is 
allocated, thereby providing maximum flexibility and utility to the user.

I find these interminable naming threads to be frustrating and an impediment to 
progress on issues with Phobos that actually matter, like making Phobos usable 
for people who don't want to use the GC.

My bias is to give strong preference in names to the choice of the person who 
actually wrote the code in question. I agree that there are sometimes bad name 
choices that need some correction. Heck, I agreed to change peek/poke to 
volatileLoad/volatileStore because sound reasons were presented. I am not 
absolutely opposed to changing names, but let's keep things in perspective and 
work on things that matter.