String lambdas

[Jonathan M Davis via Digitalmars-d]

On Wednesday, April 27, 2016 21:18:35 deadalnix via Digitalmars-d wrote:
> On Wednesday, 27 April 2016 at 12:31:18 UTC, Andrei Alexandrescu
>
> wrote:
> > On 04/26/2016 03:45 PM, Jack Stouffer wrote:
> >> I think that the drawback you mentioned does not outweigh the
> >> benefits
> >> gained from using actual lambdas.
> >
> > Actually it turns out to be a major usability issue. -- Andrei
>
> That would be better for this to go forward in a sensible manner
> that you explains what is the major usability issue here.

Well, it's problematic with default predicates, because you can't test that
the default is being used (which some algorithms do for efficiency). You're
forced to duplicate the function rather than use a default. But the far
bigger problem is when dealing with types that take a predicate (which is
going to happen with some containers and many ranges). e.g. this compiles

    RedBlackTree!(int, "a < b") a;
    RedBlackTree!(int, "a < b") b = a;

but this does not:

    RedBlackTree!(int, (a, b) => a < b) a;
    RedBlackTree!(int, (a, b) => a < b) b = a;

You get this wonderfully nonsensical error:

q.d(6): Error: cannot implicitly convert expression (a) of type 
q.main.RedBlackTree!(int, (a, b) => a < b, false) to q.main.RedBlackTree!(int, 
(a, b) => a < b, false)

So, you can't convert an expression of one type to an expression of exactly
the same type? Sure, the error message could be improved, but I doubt that
very many folks are going to expect this sort of error unless they've run
into the problem previously. It totally fails to principle of least
surprise. And it's definitely a usability problem.

It makes passing around types with predicates a royal pain when you need to
type them explicitly (which happens far more with containers than ranges).
It also makes having member variables of them harder. To some extent, you
can get around it with typeof(a) - which is often what we have to do with
ranges anyway, but that's pretty ridiculous when you typed out the exact
type to begin with and code-wise, there's no reason why they shouldn't be
identical.

There are likely other uses cases where this is a problem, but those are the
two that we definitely run into with current Phobos code. And while the
problem may make sense to a compiler writer, it's not what much of anyone
else is going to expect or want to deal with.

- Jonathan M Davis