Future of string lambda functions/string predicate functions

[Jonathan M Davis]

On Wednesday, August 14, 2013 12:05:01 Manu wrote:
> Can you give an example where you've actually used a string lambda before
> where the predicate is more complex than a basic comparison?

You can use string lambdas with anything which std.functional imports, so

std.algorithm
std.conv
std.exception
std.math
std.range
std.string
std.traits
std.typecons
std.typetuple

And to show how broken string lambdas are, most of the imports are list like 
this

// for making various functions visible in *naryFun
import std.algorithm, std.conv, std.exception, std.math, std.range, 
std.string;

All of those modules are imported specifically so that string lambdas can use 
their stuff. I'm sure that I've used std.conv.to and various string functions 
at minimum, since I generally prefer to use string lambdas when I can, but you 
generally have to just trying them and see what does and doesn't work if you 
want to use string lambdas for anything besides operators. Operators are where 
the major gain is though.

> 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?

That would result in too many stray templates. Something like binaryOp!"<" 
would make more sense. Then we pretty much just need unaryOp and binaryOp 
rather than a template for every operator. Other than that, it's a good idea 
though, since it allows us to make the common case cleaner.

> 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.

Unless you happen to have memorized what std.functional imports, it's a 
guessing game, which is the major problem with string lambdas. It also has the 
unfortunate side effect of making it so that we can't change what 
std.functional imports.

> Also, the syntax highlighting fails.

I've never really viewed that as problem. I _like_ the fact that they're 
highlighted as a string and therefore clearly separate from the rest of the 
expression. Having syntax highlighting inside the lambda is generally a 
negative IMHO, though I can see why you'd want it. The only places where I 
might want it would be complicated enough to require regular lambdas anyway, 
in which case, it might even be cleaner to use a nested function.

- Jonathan M Davis