Naming of new lazy versions of existing Phobos functions

[Brad Anderson via Digitalmars-d]

On Friday, 18 July 2014 at 08:48:08 UTC, Walter Bright wrote:
> [...]
> 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'm not suggesting we rename anything. The convention would be 
just for when there is an existing eager function we'd like to 
add a lazy version of but which we can't use the original name 
because an overload isn't possible. It's out of necessity, not 
desire. I wish we didn't need new names.

> 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.

Yeah, I agree. I'd hate having a "with" prefix on everything. I'm 
just trying to think of a consistent way to approach this issue 
since all of these new lazy functions in Phobos will need new 
names in order for us to move forward with Operation Couchpotato.

Looking over std.string at all the functions we should probably 
add lazy versions of the only option I can think of apart from 
"with" is maybe use the past participle on the ones with verbs.

So here are both options side by side for comparison:

- abbrev         : abbreviated    : withAbbrev
- capitalize     : capitalized    : withCapitalize
- center         : centered       : withCenter
- detab          : detabbed       : withDetab
- entab          : entabbed       : withEntab
- format         : formatted      : withFormat
- leftJustify    : leftJustified  : withLeftJustify
- munch          : munched        : withMunch
- outdent        : outdented      : withOutdent
- removechars    : removedChars   : withRemoveChars
- rightJustify   : rightJustified : withRightJustify
- splitLines     : splittedLines  : withSplitLines
- squeeze        : squeezed*      : withSqueeze
- strip          : stripped       : withStrip
- stripLeft      : strippedLeft   : withStripLeft
- stripRight     : strippedRight  : withStripRight
- succ           : ?              : withSucc
- toLower        : lowered        : withLower
- toStringz      : ?              : withStringz
- toUpper        : uppered        : withUpper
- tr             : ?              : withTr
- translate      : translated     : withTranslate
- wrap           : wrapped        : withWrap

* or squoze, heh

That actually works surprisingly well for the most part. succ() 
has a bad name anyway so I'd think we'd take the opportunity to 
just come up with a better one for the lazy version. Not sure 
what to do about tr and toStringz.

I left out soundex() and maketrans() because they are kind of 
different beasts (and technically return fixed sizes so a static 
array is probably a better option for these two anyway). I also 
am leaving out to[Lower,Upper]InPlace() because they should 
probably just take an allocator or something (maybe rename them 
finally while we are at it; 
toLowerOftenInPlaceButNotAlwaysBecauseOfVariableWidthEncoding() 
perhaps).

setExtension doesn't work with this approach though. I'd argue 
using "set" in the name was bad in the first place because it's 
not setting anything, it's making something new.

Maybe "with" could be for functions with no verb or a verb with 
an identical past and present participle, otherwise just use the 
paste tense of the verb.

Let's try using this rule with std.path:

- absolutePath        : withAbsolutePath
- buildNormalizedPath : builtNormalizedPath (maybe normalizedPath)
- buildPath           : builtPath           (maybe path)
- defaultExtension    : defaultedExtension  (maybe 
ensureExtension)
- dirName             : withDirName         (maybe dirNameOnly)
- driveName           : withDriveName       (maybe driveNameOnly)
- expandTilde         : expandedTilde
- relativePath        : withRelativePath
- setExtension        : withExtension
- stripDrive          : strippedDrive
- stripExtension      : strippedExtension

baseName() and extension() just slice (or should just slice, 
didn't look at the implementations) so they were left out. 
dirName could probably be made to not allocate.

The rule seems to work ok. Not nearly as clean and nice as it 
applies to std.string though.

What do you think?