Future of string lambda functions/string predicate functions

[H. S. Teoh]

On Sun, Aug 11, 2013 at 09:26:17AM -0700, Andrei Alexandrescu wrote:
> On 8/8/13 9:52 AM, Jonathan M Davis wrote:
> >On Thursday, August 08, 2013 07:29:56 H. S. Teoh wrote:
> >>Seems this thread has quietened down. So, what is the conclusion?
> >>Seems like almost everyone concedes that silent deprecation is the
> >>way to go.  We still support string lambdas in the background, but
> >>in public docs we promote the use of the new lambda syntax. Would
> >>that be a fair assessment of this discussion?
> >
> >I find it interesting that very few Phobos devs have weighed in on
> >the matter, but unfortunately, most of the posters who have weighed
> >in do seem to be against keeping them.
> 
> There's a related issue that I think we must solve before deciding
> whether or not we should deprecate string lambdas. Consider:
> 
> void main() {
>     import std.range;
>     SortedRange!(int[], "a > b") a;
>     SortedRange!(int[], "a > b") b;
>     b = a;
>     SortedRange!(int[], (a, b) => a > b) c;
>     SortedRange!(int[], (a, b) => a > b) d;
>     d = c;
> }
> 
> The last line fails to compile because D does not currently have a
> good notion of comparing lambdas for equality. In contrast, string
> comparison is well defined, and although string lambdas have clowny
> issues with e.g. "a>b" being different from "a > b", people have a
> good understanding of what to do to get code working.
> 
> So I think we should come up with a good definition of what
> comparing two function aliases means.
[...]

I'm not sure how the compiler handles delegates internally, but a first
shot at it might be, any delegate with the same expression tree within
the same scope should compare equally. I don't know if this is actually
feasible to implement, though (I'm not familiar with DMD code).

The reason it must be the same scope is because otherwise, the delegate
might be closing over different variables, so it should not be treated
the same way (otherwise two delegates that are textwise the same may
have different runtime behaviours, leading to a wrong conflation of
template instantiations).


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis