Naming of new lazy versions of existing Phobos functions

[Brad Anderson via Digitalmars-d]

On Friday, 18 July 2014 at 22:37:26 UTC, Walter Bright wrote:
> On 7/18/2014 2:14 PM, Brad Anderson wrote:
>> It's kind of weird that you'd say that because you seem to be 
>> pretty strongly
>> opinionated about the naming.
>
> It's not just this one, it comes up again and again, always 
> spawning long debates, and accomplishing next to nothing.
>

Oftentimes this is true and I share your dread of long debates 
(which is why I mentioned bikeshedding in the initial post). This 
isn't a "let's make better names for the sake of having nicer 
names" post though. This post was to talk about a real, upcoming 
problem for which adding a new name for the functions involved is 
the only option.

> [...]
> There is no solution, there is just more discussion and more 
> debate, and useful work is not getting done.

Yes, there will always be dissenting opinions on naming but I've 
spent more time arguing with you about whether or not this is a 
waste of time than it took for us to come up with some great 
names to use for all the std.string and std.path functions 
elsewhere in this thread.

> [...]
> A naming convention implies a mass renaming of existing lazy 
> algorithms - or it is not a convention at all.
>
> Lazy algorithms are not a new invention in Phobos. They've been 
> there since the beginning of range use. setExt is not a 
> prototype for lazy ranges, we already have them in plenty. It's 
> a prototype for removing storage allocation from Phobos 
> functions, making them more composable, etc.

It's not a convention for lazy functions. It's just a discussion 
about how to approach the naming problem you discovered. The fact 
that the functions are lazy has nothing to do with this. The only 
thing the functions being discussed have in common is that they 
need alternative but very similar names because of a technical 
issue (in an ideal world there would be no need to change the 
names at all). That the new functions are to solve the allocation 
decision problem or that they are lazy makes no difference here. 
It could be any problem in which we can't just use an overload to 
address.

> Whether "setExtension" or "withExtension" is more intuitive is 
> caring too much. Calling it "sdjfhalkjshdfjh" is caring too 
> little.

Well, it's "setExt" versus "withExtension" but I agree we've 
wasted too much time on this detail.