Future of string lambda functions/string predicate functions

[Andrej Mitrovic]

On 8/6/13, Jakob Ovrum <jakobovrum at gmail.com> wrote:
>   * Leave support for string lambdas in existing Phobos functions
> for the foreseeable future, for backwards-compatibility purposes.
>   * New functions would not support string lambdas.

Yeah, I agree. There's a benefit of having less features that do the
exact same thing, especially for people new to D.

Btw, I don't buy Jonathan's "less is better" argument at all,
especially knowing what std.datetime looks like. He's arguing that
string lambdas are somehow smaller, yet he writes code with symbol
names such as hasOverloadedOpBinaryWithSelf,
hasOverloadedOpAssignWithDuration, tzDatabaseNameToWindowsTZName, and
forces us to write code like so:

cast(DateTime)SysTime(unixTimeToStdTime(_unixIntTime);

or even:

if (curTime.peek > cast(TickDuration)1.seconds) { }

Where is the short syntax for these expressions? I have to write my
own wrappers for these of course.

And JMD also argues that "seconds" is somehow better then "secs".
"secs" is simple and consistent with "nsecs", "usecs", "msecs", but he
always shots it down like it's some kind of abomination because
"standards and stuff" which nobody really cares about. I always end up
writing "secs" and get back a compiler error, it's frustrating.

I'd say keep the current string lambda parameters intact, but don't
introduce any new ones to new functions.