Future of string lambda functions/string predicate functions

[monarch_dodra]

On Tuesday, 6 August 2013 at 21:35:05 UTC, John Colvin wrote:
> On Tuesday, 6 August 2013 at 20:28:59 UTC, Peter Alexander 
> wrote:
>> On Tuesday, 6 August 2013 at 09:05:57 UTC, Jakob Ovrum wrote:
>>> Specifically, I suggest the following deprecation path:
>>>
>>> * Add deprecation notes to std.functional's unaryFun and 
>>> binaryFun so users are dissuaded from using them in new code. 
>>> In time, we would remove their documentation.
>>> * Leave support for string lambdas in existing Phobos 
>>> functions for the foreseeable future, for 
>>> backwards-compatibility purposes.
>>> * Change all documentation so that it doesn't mention string 
>>> lambdas, whether in prose or code. Phobos pull request #707 
>>> (Switch std.algorithm/.range to lambda syntax)[2] attempted 
>>> this and was approved and merged, but subsequently reverted 
>>> due to bugs.
>>> * New functions would not support string lambdas.
>>
>> Yes x 4. I think this is the perfect path to their 
>> semi-deprecation.
>>
>> Deprecating them completely, I think, would be unwise since 
>> there's a lot of code out there using them. Deprecation 
>> through obscurity while retaining backwards-compatibility is 
>> the right choice.
>
> I agree this is the best decision.

I actual think this is a very bad situation. This puts them in 
the odd spot of "not deprecated, but sometimes supported". This 
puts the end coder who *wants* to use lambdas (after all they 
aren't deprecated), in a weird position of "which functions 
support it, which functions don't?"

Since the end coder is not a D guru, he'll have no idea which 
functions do support string lambdas, and which don't, which will 
leave him in an eternal guessing game of "well, looks like *that* 
doesn't compile"...

So, if we *do* choose that string lambdas should leave, then I 
believe they should clearly be marked as "deprecated". We can 
leave them in forever, but the end user *must* be told that 
string lambdas are *not* the way it is meant to be used anymore.

--------

Related: My vote goes that they should stay. Sure, normal lambdas 
are more powerful, but string lambdas are very light weight. Do 
you really argue that this is better?

sort!((a, b) => a > b)(1, 2, 3);
vs
sort!"a > b"(1, 2, 3);

string lambdas look clearer to me.

Also, and this is important (!): A lambda is *always unique*, 
whereas strings alias each other. This means that:

sort!"a > b"(1, 2, 3); //Both generate the same template
sort!"a > b"(1, 2, 3); //

sort!((a, b) => a > b)(1, 2, 3); //Generates two different 
templates
sort!((a, b) => a > b)(1, 2, 3);

This is particularly relevant for *struct* that take preds.

Imagine:
Sorter!"a > b" sorter1;
Sorter!"a > b" sorter2;
static assert(typeof(sorter1) == typeof(sorter2)); //Passes

But
Sorter!((a, b) => a > b) sorter1;
Sorter!((a, b) => a > b) sorter2;
static assert(typeof(sorter1) == typeof(sorter2)); //Fails

--------

So, my vote is that string lambdas should stay. Supporting them 
is easy: Just an extra alias at the top of the function. Getting 
rid of them buys us nothing. There are people who use them, and 
there are cases where they make more sense.

I *AM* 100% perfectly fine with making the default pred a normal 
lambda though, and promote their use over string lambdas.