[cfe-dev] C++1z invocation_traits

[Richard Smith]

On Mon, Feb 2, 2015 at 5:27 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Mon, Feb 2, 2015 at 5:27 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> On Tue, Jan 27, 2015 at 11:34 AM, Marshall Clow <mclow.lists at gmail.com>
>> wrote:
>>
>>>
>>> On Jan 27, 2015, at 12:03 AM, Ben Pope <benpope81 at gmail.com> wrote:
>>>
>>> On Tuesday, January 27, 2015 03:59 PM, Ben Pope wrote:
>>>
>>> On Tuesday, January 27, 2015 02:28 PM, Michael Haidl wrote:
>>>
>>> Hi all,
>>>
>>> I am curious about the proposed invocation traits
>>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3866.html) and
>>> life would be a lot easier if they would make it into the next C++
>>> standard (at least for me). However 201z is far away and I was wondering
>>> if someone is already working on this in clang. If not can someone
>>> direct me to the right spot in clang where such a feature would be in
>>> the right place?
>>>
>>>
>>> I'm not sure what happened, they appear to have made it to N3908, then
>>> to N4023, then to N4081 but they don't appear in N4270.
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/
>>>
>>>
>>> They're hiding here:
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4335.html
>>>
>>>
>>> In other words, they’ll appear in libc++.
>>> [ We’re trying to get a full LFTS implementation in there, but it’s not
>>> all there yet ]
>>>
>>
>> We should figure out what intrinsics you guys want in order to support
>> this. I believe it's straightforward to implement invocation_type in terms
>> of raw_invocation_type in the library, so I think providing simply a
>> __raw_invocation_type(Fn, Arg1, Arg2, ...) would work?
>>
>
> (And it's up to you whether you'd prefer these arguments to be expressions
> or types...)
>

Ping. Mashall, Eric: do you have a preference on what compiler support you
want here? The most general option is probably:

  __raw_invocation_type(expression)

where the expression is required to be some kind of call expression, and
the type of __raw_invocation_type is the type of the callee. This allows
you to introspect the result of overload resolution, etc.

However, this violates the tradition of std_trait<Args...> mapping exactly
to __std_trait(Args...), so perhaps we should give it a different name to
avoid colliding with other compilers' eventual extensions. Or we could just
provide a __raw_invocation_type trait that takes a single function type and
computes the result type as specified by the TS.

Thoughts?

Looking at N4335 now, I'm a little concerned that we may be standardizing a
>> bad interface; we don't support using raw_invocation_type<F(Args...)> if F
>> is a function type, because that would create a function type whose return
>> type is a function type, which is ill-formed.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150501/e12308ef/attachment.html>