On Tuesday, 26 April 2016 at 17:58:22 UTC, Andrei Alexandrescu wrote:
> https://github.com/dlang/phobos/pull/3882
>
> I just closed with some regret a nice piece of engineering. Please comment if you think string lambdas have a lot of unexploited potential.
>
> One thing we really need in order to 100% replace string lambdas with lambdas is function equivalence. Right now we're in the odd situation that SomeTemplate!((a, b) => a < b) has distinct types, one per instantiation.
>
>
> Andrei

I will just point out an obvious solution to the problem of having distinct types: if a normal lambda is sufficiently simple, and is used as a template parameter, lower the code to the one which uses an equivalent string lambda.

The string needs to somewhat normalized so that (a, b) => a < b  and  (c,d) => c<d  are converted to the same string.

Whether the compiler allows explicit string lambdas in user code in another issue.

> Whether the compiler allows explicit string lambdas in user code in another issue.

s/in another issue/is another issue/

On Sun, 01 May 2016 15:03:41 +0000
Seb via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> I really like them too and was impressed that Andrei is so against them, especially if you have more arguments writing the lambda get's more tedious.

String lambdas were an innovative solution to make lambdas shorter than having to provide full-on anonymous functions with brackets and the whole bit. However, they quickly proved to have problems as soon as you tried to do much of anything beyond arithmetic and comparisons, because you could only use functions in them that were in modules imported by std.functional. So, at some point there was a discussion or two or introducing a shorter lambda syntax, and we ended up adding the syntax which is currently used which (as I understand it) is the same as what C# uses, and that works in a much broader context than string lambdas do. If we'd had it initially, we probably would never have had string lambdas.

Really, the only three reasons that we still have string lambdas at this point is to avoid breaking code, because you can't compare lambdas for equality (whereas you can compare strings), and because the same template instantiated with the same lambda in multiple places results in different instantiations, so they're incompatible.

Now, string lambdas are still great for basic stuff like "a != b" and
"a + b" and the like, because even the new lambda syntax is longer than
that. But having the string lambdas on top of the other is adding more
complication to the language/library, and it's going to continue to cause
problems when folks try and use the string lambdas to call functions that
std.functional doesn't have access to - and it wouldn't surprise me if the
recent import fixes actually make it so that std.functional has access to
even fewer functions.

So, on some level it _will_ suck to lose string lambdas even once we've fixed the issues with non-string lambdas, but they're redundant and will be potentially confusing to keep around. So, most folks seem to have concluded that they should be removed (some even seem to think that they should be removed even without the current issues with non-string lambdas being fixed, but that's unreasonable IMHO).

- Jonathan M Davis

On 02.05.2016 02:17, Jonathan M Davis via Digitalmars-d wrote:
> So, at some point there was a discussion or two or introducing a shorter
> lambda syntax, and we ended up adding the syntax which is currently used
> which (as I understand it) is the same as what C# uses,

There is a difference. `x => {foo(x);}` has a different meaning in D than in C#. C#'s meaning is expressed with `(x) {foo(x);}` in D, and D's meaning is `x => () => {foo(x);}` in C#.