• mogu (5/5) Jul 25 2016 Link:
• Steven Schveighoffer (5/10) Jul 26 2016 I think this should be forwarded. It's a very nice thing, and having C++...
• deadalnix (7/12) Jul 26 2016 I'd like to see that move forward, but the way this DIP is doing

mogu <mogucpp 163.com> writes:

Link:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0091r1.html

And we have DIP40:
http://wiki.dlang.org/DIP40

Is someone there to renew it in new DIPs repo? T.T

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 7/26/16 1:12 AM, mogu wrote:
 Link:
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0091r1.html

 And we have DIP40:
 http://wiki.dlang.org/DIP40

 Is someone there to renew it in new DIPs repo? T.T

I think this should be forwarded. It's a very nice thing, and having C++ 
adopting it could be new incentive to solve it. Must keep up with the 
Joneses :)

-Steve

deadalnix <deadalnix gmail.com> writes:

On Tuesday, 26 July 2016 at 05:12:13 UTC, mogu wrote:
 Link:
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0091r1.html

 And we have DIP40:
 http://wiki.dlang.org/DIP40

 Is someone there to renew it in new DIPs repo? T.T

I'd like to see that move forward, but the way this DIP is doing 
it won't cut it.

Defining IFTY for structs and functions independently is a recipe 
to have subtle difference between the 2. I'd support a proposal 
that define the concept of "Callable" or whatever the name, and 
then define IFTI for callables.