Naming of new lazy versions of existing Phobos functions

[Walter Bright via Digitalmars-d]

On 7/17/2014 3:59 PM, Brad Anderson wrote:
> Walter's prototype[1] for removing allocations from a phobos function
> (std.path.setExtension) got hung up on the naming of the function. It couldn't
> keep the same name because it differed only by return type.
>
> Walter doesn't like explicitly naming them as lazy because existing lazy
> functions like most of std.algorithm don't have names that state they are lazy.
> On the other hand, setExt is controversial because it's an arbitrary
> abbreviation done just to avoid the naming conflict. Not every function we'd
> like to see adopt the same approach would be amenable to a simple abbreviation
> to dodge the naming issue.

A good summary.


> I think it's probably a good time to come up with a naming scheme for these lazy
> versions of existing functions so things are consistent throughout Phobos.
>
> David Nadlinger offered a few ideas in the thread: setExtensionLazy,
> extensionSetter, or withExtension.
>
> I find the "with" prefix particularly attractive. It implies the lazy behavior,
> is short, and reads well when chained with other calls. Hypothetical example I
> gave in the Pull Request comments:
>
>    auto contents =
>        "  FILE".withStrip()
>                .withLowercase()
>                .withExtension(".txt")
>                .readText();
>
> At the risk of bikeshedding, I thought it would be useful to solicit the wider
> forum audience for ideas and opinions. Thoughts?
>
> 1. https://github.com/D-Programming-Language/phobos/pull/2149

Since there are a lot of existing lazy algorithms in Phobos that do not follow 
this naming convention, either the convention is pointless or we go through yet 
another round of changing Phobos names and breaking everyone's code.

I haven't completely sold Andrei on the idea, but I feel that all algorithms 
should be lazy unless they have a very strong reason not to be. Being the 
default suggests a naming convention for them would be unnecessary even if it 
were practical.

I also suggest that ext is not an arbitrary abbreviation for extension, it is 
commonplace. In a module named std.path, there's little doubt about what it 
means. And besides, "extension" itself is an abbreviation for "file name 
extension". I don't really want to go the Java approach of 
reallyLongSentencesAsIdentifierNames either, as those are not very practical 
unless one has an autocompleting IDE.