std.uni.toLowerCase / .toUpperCase

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 23 June 2015 at 23:17:54 UTC, Meta wrote:
> I really hate this naming scheme for functions that take lazy 
> parameters. I still don't see why we don't do the (IMO) 
> simplest and most intuitive thing and name them lazyToLower / 
> lazyToUpper (or toLowerLazy / toUpperLazy). There is precedent 
> with C#'s handling of async functions; for example, 
> AccessTheWebAsync or GetStringAsync[1]. Your proposed naming 
> scheme seems like it's trying to be too "clever" and really 
> just ends up causing unnecessary confusion. This is not Ruby.
> [1]https://msdn.microsoft.com/en-us/library/hh191443.aspx

I'm not sure about this... I've seen another proposal for a 
"lazy" suffix in the other thread, but I think this won't be 
great in the long run:

- Ultimately, we want to encourage use of the lazy versions, in 
the same way that e.g. std.algorithm and std.range are encouraged 
over eager operations for arrays.

- There is no consistency with any existing naming schemes. 
Currently no names in Phobos contain the word "Lazy".

- If std.algorithm were to follow this convention, it would have 
lazyJoin instead of joiner, lazySplit instead of splitter, 
lazyConcat OSLT instead of chain, etc. Given a typical program 
using std.algorithm, do you think such names would look better 
there than the current ones?

- I'm not sure about the C# async analogy: with "async", the 
methods are used in a different way. The new range-based 
functions are used in the same way, but work on different types.

Here's an example program using setExt[ension] and toLower[Case], 
in 4 variants...

https://gist.github.com/CyberShadow/5cc7e926f566d56a672f

IMHO, in this case, the "Lazy" suffix is a distracting 
technicality that doesn't carry its weight. Am I the only one?