Future of string lambda functions/string predicate functions

[Manu]

On 6 August 2013 19:25, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> On Tuesday, August 06, 2013 11:05:56 Jakob Ovrum wrote:
> > What does everyone think?
>
> I'm completely opposed to the removal of string lambdas. Obviously, they
> don't
> always work. More complicated functions definitely need to use the newer
> lambda
> syntax or function literals. But for simple lambdas, they're way better.
> I'd
> _much_ rather have func!"a != b"(args) than func!((a, b) => a != b)(args)
> or
> func!"a < b"(args) than func!((a, b) => a < b)(args). String lambdas are
> nice
> and short, and I think that they're plenty clear, and if they're not,
> they're
> trivial to explain.
>

Can you give an example where you've actually used a string lambda before
where the predicate is more complex than a basic comparison?
Surely the solution to this problem is to offer a bunch of templates that
perform the most common predicates in place of unary/binaryFun?

So rather than: func!((a, b) => a < b)(args)
You use: func!binaryLess(args)

Or something like that?

The thing that annoys me about string vs proper lambda's, is that I never
know which one I'm supposed to use. I need to refer to documentation every
time.
Also, the syntax highlighting fails.

We already have string lambdas. Removing them would break code for little
> benefit IMHO. If you prefer to use the newer lambda syntax, then use that,
> but
> I think that it's a definite loss if we get rid of the string lambdas, as
> they're so much more concise when they do work.
>
> I also think that all new Phobos functions which take unary or binary
> predicates should support string lambdas. It's trivial for them to do so,
> and
> it creates needless inconsistencies if some functions support them and some
> don't.
>
> - Jonathan M Davis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130814/e261ef50/attachment.html>