[cfe-dev] C++1z invocation_traits
richard at metafoo.co.uk
Fri May 1 15:45:22 PDT 2015
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>
>> On Tue, Jan 27, 2015 at 11:34 AM, Marshall Clow <mclow.lists at gmail.com>
>>> 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.
>>> They're hiding here:
>>> 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:
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.
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...
More information about the cfe-dev