std.uni.toLowerCase / .toUpperCase

[Meta via Digitalmars-d]

On Tuesday, 23 June 2015 at 23:49:45 UTC, Vladimir Panteleev 
wrote:
> 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".

And hopefully not many would have to. I can't say that this is 
the right solution for all lazy / range-based code going forward, 
but it's better than what we have, and I believe it's better than 
withExtension / upperCased / etc.

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

They would definitely be more recognizable as lazy functions, at 
the least. This would make code using std.algorithm more verbose, 
but we're not looking at changing every name in std.algorithm. 
We're looking at changing a couple of very bad names that give no 
indication that they're lazy / range-based (and let's not forget 
that the two aren't synonymous; we do have a lazy keyword after 
all).

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

It is a bit longer, but 4 extra characters is not all that much 
to pay to make a few functions much clearer about what they do.