On Tue, Jun 23, 2015 at 4:49 PM, Vladimir Panteleev via Digitalmars-d < digitalmars-d@puremagic.com> 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". > > - 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? > > +1 If I'd seen this two minutes ago could have saved me some typing.