[cfe-dev] C++1z invocation_traits

[Eric Fiselier]

Hi Richard,

I've sketched out some of my main concerns.

1. I think compatibility between gcc and clang would be really
helpful. Won't clang have to support GCC's internals in order to
support libstdc++?

2. __raw_invocation_type(expression) has usefulness beyond the traits
in the LFTS. It seems like it could be used to compute the invocation
type of non-member function expressions. Is there any concern with
users directly using this intrinsic to leverage that functionality?

3. As a layman __raw_invocation_type(expression) seems harder to
implement than __raw_invocation_type(Args...). Is that a concern?

4. The name should also reflect that the intrinsics provides the LFTS
v1 semantics. If the semantics change in a future standard we can
provide another differently named intrinsic. My concern is that in the
future, after we have shipped std::invocation_type<...> in C++1z,
libc++ will be unable to detect if clangs provides
`__raw_invocation_type(...)` for LFTS v1 or C++1z.

/Eric

On Fri, May 1, 2015 at 6:45 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 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.
>>
>>
>