Fix issue 20099 - Memoize should handle lambdas

[Biotronic]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @Biotronic! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20099	enhancement	Memoize should handle lambdas

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + phobos#7507"

[Biotronic]

That should take care of the issues that have been pointed out, and also makes memoize handle overloads, which confused it before.

[kinke]

I don't think it does. Try

alias foo = memoize!(n => new Object());
assert(foo(0) is foo(0U));

[Biotronic]

I don't see the problem there - you have a templated function and you expect it to be the same with different template arguments? First, that's a completely different issue from the above. Second, it's one that cannot possibly be handled sensibly in the language today. Third, it's code that didn't compile before, so it doesn't break any existing code.

[kinke]

You open the door for a single memoize!Func instantiation to (IMO quite probably unintentionally) break down into a multitude of actually memoized functions, depending on the used args, just for the sake of saving to type down the explicit parameter types for lambdas.

I think a memoize!F instance should stick binding to a single function. The user can always declare some alias memoizedFun(T) = memoize!((T p) => make(p)) in case a templated wrapper is actually desired.

[Biotronic]

I do see that, but I think the issue is much smaller than you make it out to be. Note also that you have the same issue for explicit template functions:

int foo(T)(T t) {
    return T.stringof.length;
}
unittest {
    assert(memoize!foo(0) != memoize!foo(0U));
}

I hope the above both compiles and passes the assert.

We could in fact test for lamba-osity by static asserting on fun.stringof[0..8] == "__lambda", if we find that this is a big issue.

[n8sh]

I hope the above both compiles and passes the assert.

It turns out that prior to this PR that code doesn't compile because Parameters!foo doesn't work for an uninstantiated template:

Error: template instance std.traits.Parameters!(foo) does not match template declaration
 Parameters(func...)
  with func = (foo(T)(T t))
  must satisfy the following constraint:
       isCallable!func

[kinke]

Yes, it currently (master) doesn't support any templates and always binds to one function (thus the 'confusion' for overloads), and the short-hand lambda syntax is one such case, but not so obvious by the produced error msges.

[kinke]

I do see that, but I think the issue is much smaller than you make it out to be.

You're probably right. I suppose the memoized wrapper now (this PR) cleanly wraps a symbol, incl. overloads and templates, and doesn't expand (just propagate) the domain of argument types.

[RazvanN7]

@Biotronic can you please rebase so we can get this in?

[pbackus]

Need to pass true as an additional argument to __traits(getOverloads) here in order to include template overloads. As-is, the check for anySatisfy!(isTemplate, overloads) below will always evaluate to false.

[RazvanN7]

ping @Biotronic

[n8sh]

Rebased & expanded commit message.