class template deduction: can explicit guide be =delete'd?

443 views
Skip to first unread message

Sergey Zubkov

unread,
Aug 2, 2016, 1:14:55 PM8/2/16
to ISO C++ Standard - Future Proposals

The proposal p0091R3 says, in prose under "Explicitly specified deduction guides",
It also allows us to suppress a standard deduction from the above process via "= delete;" 
but the proposed wording and what is now in n4606 does not seem to allow that: deduction-guide ends with simple-template-id and semicolon.

Was that intentional, and if so, how do we suppress unwelcome implicit deductions?

Faisal Vali

unread,
Aug 2, 2016, 1:42:41 PM8/2/16
to <std-proposals@isocpp.org>
I believe it was intentional to leave the feature out (at least for
what was felt to be ready at the time) - but I agree it would be
useful - and if you (or anyone) knows how to (I don't), I suggest
submitting a national body comment.

> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ef5033c-9d63-4b0d-b8aa-e5fc50939ee7%40isocpp.org.

Richard Smith

unread,
Aug 4, 2016, 2:31:21 PM8/4/16
to std-pr...@isocpp.org

Like this:

template<typename T> struct nondeducible_impl { using type = T; };

template<typename T> using nondeducible = typename nondeducible_impl<T>::type;

template<typename T> struct X {
  X(nondeducible<T>);
};
X x=0; // error, can't deduce T

Tomasz

unread,
Aug 5, 2016, 1:02:03 AM8/5/16
to ISO C++ Standard - Future Proposals


W dniu czwartek, 4 sierpnia 2016 20:31:21 UTC+2 użytkownik Richard Smith napisał:

On 2 Aug 2016 10:15 a.m., "Sergey Zubkov" <cubb...@gmail.com> wrote:
>
>
> The proposal p0091R3 says, in prose under "Explicitly specified deduction guides",
>>
>> It also allows us to suppress a standard deduction from the above process via "= delete;" 
>
> but the proposed wording and what is now in n4606 does not seem to allow that: deduction-guide ends with simple-template-id and semicolon.
>
> Was that intentional, and if so, how do we suppress unwelcome implicit deductions?

Like this:

template<typename T> struct nondeducible_impl { using type = T; };

template<typename T> using nondeducible = typename nondeducible_impl<T>::type;

template<typename T> struct X {
  X(nondeducible<T>);
};
X x=0; // error, can't deduce T


There is some disconnection:
 - implicit deduction guides will be automatically generated for the existing code, including 3rdParty classes that the programmer cannot modify
 - to disable implicit deduction guide the code of the class need to be modified

Faisal Vali

unread,
Aug 5, 2016, 11:05:21 AM8/5/16
to <std-proposals@isocpp.org>
Well I think there is no disconnection if you embrace the philosophy
that we all should be re-writing (or re-imagining in the absence of
source) other people's code to improve it, anyway ;)


>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e18a92c5-c0b3-4fd7-bb15-e0e5426ed696%40isocpp.org.

Timur Doumler

unread,
Nov 21, 2017, 12:58:57 PM11/21/17
to ISO C++ Standard - Future Proposals
Sorry for resurrecting this thread, but does anyone know why it was decided not to have deleted deduction guides as a language facility? Richard's solution feels like unnecessarily verbose to me (having to introduce a helper type in order to break the deduction guide).

A related question: the constructor explicit unique_ptr(pointer p) has the following note in the standard:

“If class template argument deduction would select the function template corresponding to this constructor, then the program is ill-formed.”

What is the suggested implementation strategy for this? It is surprising to me that the standard enforces such a constraint but provides no facility to express this constraint in C++ code. I would like to disable CTAD in such a case with something along the lines of

unique_ptr(pointer p) -> delete

which of course isn't possible in C++17. Or maybe I just didn't get it? Please someone enlighten me.

Thanks,
Timur

Richard Smith

unread,
Nov 21, 2017, 2:48:33 PM11/21/17
to std-pr...@isocpp.org
On 21 November 2017 at 09:58, Timur Doumler <goo...@timur.audio> wrote:
Sorry for resurrecting this thread, but does anyone know why it was decided not to have deleted deduction guides as a language facility? Richard's solution feels like unnecessarily verbose to me (having to introduce a helper type in order to break the deduction guide).

=delete is simply wrong as a way of removing an implicit deduction guide. =delete means "participates in overload resolution, the program is ill-formed if it's selected", not "remove this from the overload set". And indeed =delete might be useful for deduction guides as a "honeypot" for undesirable deductions, just as it's useful in other overload sets. But it does not solve the problem at hand.

Also, the idea is that the helper type would become a standard library facility, rather than something that users reinvent.

A related question: the constructor explicit unique_ptr(pointer p) has the following note in the standard:

“If class template argument deduction would select the function template corresponding to this constructor, then the program is ill-formed.”

What is the suggested implementation strategy for this? It is surprising to me that the standard enforces such a constraint but provides no facility to express this constraint in C++ code. I would like to disable CTAD in such a case with something along the lines of

unique_ptr(pointer p) -> delete

which of course isn't possible in C++17. Or maybe I just didn't get it? Please someone enlighten me.

I think that's a wording error. The "pointer" member type is computed from the template parameters (based on whether 'typename remove_reference_t<D>::pointer' is valid), so that constructor can never be used for deduction anyway.

(Technically, an implementation could choose to model that distinction with a partial specialization of the unique_ptr template instead of locally in the definition of the "pointer" member; perhaps this wording is trying to say what happens for an implementation that does so?)
 
Thanks,
Timur


On Thursday, August 4, 2016 at 8:31:21 PM UTC+2, Richard Smith wrote:

On 2 Aug 2016 10:15 a.m., "Sergey Zubkov" <cubb...@gmail.com> wrote:
>
>
> The proposal p0091R3 says, in prose under "Explicitly specified deduction guides",
>>
>> It also allows us to suppress a standard deduction from the above process via "= delete;" 
>
> but the proposed wording and what is now in n4606 does not seem to allow that: deduction-guide ends with simple-template-id and semicolon.
>
> Was that intentional, and if so, how do we suppress unwelcome implicit deductions?

Like this:

template<typename T> struct nondeducible_impl { using type = T; };

template<typename T> using nondeducible = typename nondeducible_impl<T>::type;

template<typename T> struct X {
  X(nondeducible<T>);
};
X x=0; // error, can't deduce T

> --
> You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ef5033c-9d63-4b0d-b8aa-e5fc50939ee7%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

Timur Doumler

unread,
Nov 22, 2017, 11:29:56 AM11/22/17
to std-pr...@isocpp.org
On 21 Nov 2017, at 20:48, Richard Smith <ric...@metafoo.co.uk> wrote:
=delete is simply wrong as a way of removing an implicit deduction guide. =delete means "participates in overload resolution, the program is ill-formed if it's selected", not "remove this from the overload set". And indeed =delete might be useful for deduction guides as a "honeypot" for undesirable deductions, just as it's useful in other overload sets. But it does not solve the problem at hand.

Yes, makes total sense, thanks for the clarification.

Re: your technique of disabling CTAD: actually quite a few people are aware of this technique and use it also to disable argument deduction for normal templated functions, e.g.:

template<typename T> struct identity {
   using T = type;
};

template<typename T> void foo(identity<T>::type x);  // TAD disabled

That makes me think whether we should have a little standard utility for this purpose? Such as std::identity (or std::same_type or whatever name). Then people don’t have to declare their own structs just for the purpose of disabling TAD. Of course you could achieve the same effect with std::common_type<T> or std::enable_if_t<true, T> but that feels like a hack.

What do you think?

Cheers,
Timur

Zhihao Yuan

unread,
Nov 22, 2017, 2:16:32 PM11/22/17
to std-pr...@isocpp.org
On Wed, Nov 22, 2017 at 10:29 AM, Timur Doumler <ma...@timur.audio> wrote:

actually quite a few people are aware of this technique and use it also to disable argument deduction for normal templated functions, e.g.:

template<typename T> struct identity {
   using T = type;
};

template<typename T> void foo(identity<T>::type x);  // TAD disabled

That makes me think whether we should have a little standard utility for this purpose? Such as std::identity (or std::same_type or whatever name). Then people don’t have to declare their own structs just for the purpose of disabling TAD. Of course you could achieve the same effect with std::common_type<T> or std::enable_if_t<true, T> but that feels like a hack.

a couple of years ago, but couldn't decide a name
for it.  Maybe you can write a paper and convince
us to stick with some name.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

Timur Doumler

unread,
Nov 22, 2017, 2:29:13 PM11/22/17
to std-pr...@isocpp.org
Thanks for this paper link!

I’d be happy to write a new paper, and my gut feeling says that identity<T> is the best name because then I can write identity_t<T> and it’d also be consistent with boost::mpl::identity<T> which is exactly the same thing and has been around for ages.

But it seems like all of this has already been ruminated by WG21 years ago, so before writing anything I should perhaps try to find the minutes of that discussion and understand why it didn’t happen back then – because there must be good reasons.

Timur

--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.

To post to this group, send email to std-pr...@isocpp.org.

Timur Doumler

unread,
Nov 22, 2017, 4:43:29 PM11/22/17
to std-pr...@isocpp.org
OK, now that I have read up on the history of this whole thing, my understanding that this feature is considered very useful is confirmed. Afaiu, std::identity was rejected because of two reasons:

- the name “identity” can’t be used because it clashes with a legacy SGI extension of the standard library that is still in use,
- the original version also had an operator() which caused all kinds of other issues.

This discussion said LEWG wants the feature, but it never lead to an updated paper afaics. Later, many people said it should be brought back *without the operator()* and there was bikeshedding on the name here  including identity_of<T>, same<T>, omit_from_deduction<T>, … but no one has actually proposed this thing again since then.

I’d really like to have this, because 1) a standard facility greatly improves teachability of this useful “disable deduction” idiom and 2) the idiom is more relevant than ever because in C++17 we got CTAD and you can use it there, too.

I prefer the name same_type because it is consistent with other metafunctions like common_type and underlying_type, and its usage in code would be very self-explanatory: “I am using the same type, but going through this helper struct for a reason”. I also have reasons for disliking the other proposed names.

I’d be ready to write this all up in a new, concise proposal  – if someone could please confirm that this wouldn’t be a waste of LEWG/LWG’s time?

Thanks,
Timur


Zhihao Yuan

unread,
Nov 22, 2017, 8:53:06 PM11/22/17
to std-pr...@isocpp.org
On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <ma...@timur.audio> wrote:
I prefer the name same_type because it is consistent with other metafunctions like common_type and underlying_type, and its usage in code would be very self-explanatory: “I am using the same type, but going through this helper struct for a reason”. I also have reasons for disliking the other proposed names.

A different same_type, similar to common_type, would be
a trait taking a list of types, then define `type` member
when they are the same -- I have been using this, so I feel
that your naming suggestion is ambiguous.

I’d be ready to write this all up in a new, concise proposal  – if someone could please confirm that this wouldn’t be a waste of LEWG/LWG’s time?

Nobody can say yes or no, but given the evidences, it's clear
that LEWG would love to see that.

Timur Doumler

unread,
Nov 23, 2017, 1:36:20 AM11/23/17
to std-pr...@isocpp.org
Ok, thanks Zhihao! I’ll think harder about the name and write a proposal for Jacksonville.
--
You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

Timur Doumler

unread,
Nov 23, 2017, 4:58:46 AM11/23/17
to std-pr...@isocpp.org
Coming back to the original question: =delete-ing explicit guides. As Richard said, they are useful as “honeypots”. Here’s a simple example:

std::complex c {2, 3};   // deduces std::complex<int>

However, [complex.numbers] says:
"The effect of instantiating the template complex for any type other than float, double, or long double is unspecified.”

It might therefore be desirable to disable the deduction, issue a compiler error along the lines of “argument deduction failed: deduction guide was marked as deleted”, and force the user to explicitly type out the template arguments if she really wants to instantiate complex<int>. (This example might be flawed but that’s not the point.)

Afaics here (last poll), EWG concluded it was an oversight to not have =delete as a feature in the first place, and decided that they want to add it as a DR for C++17.

Afaict, nothing happened afterwards.

Is this correct? If yes, should we bring this proposal back? (I’d be in favour). If no, does anyone know the status of this?

Thanks,
Timur

John Bytheway

unread,
Dec 5, 2017, 3:54:51 PM12/5/17
to std-pr...@isocpp.org
On 2017-11-23 01:53, Zhihao Yuan wrote:
> On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <ma...@timur.audio
> <mailto:ma...@timur.audio>> wrote:
>
> I prefer the name same_type because it is consistent with other
> metafunctions like common_type and underlying_type, and its usage in
> code would be very self-explanatory: “I am using the /same type/,
> but going through this helper struct for a reason”. I also have
> reasons for disliking the other proposed names.
>
>
> A different same_type, similar to common_type, would be
> a trait taking a list of types, then define `type` member
> when they are the same -- I have been using this, so I feel
> that your naming suggestion is ambiguous.

You don't say what ::type is defined to in your use case, but I imagine
it is that common type argument (unless the list is empty).

Such a tool, when passed a single type, would just set ::type to that
type. Which is exactly what the other proposed same_type wants. So the
two uses are compatible, and the same name could be used for both.

John Bytheway

Timur Doumler

unread,
Dec 5, 2017, 4:41:59 PM12/5/17
to std-pr...@isocpp.org
Cool! A very interesting observation I’ve not considered yet.

My original idea was to define the “disable TAD” utility like this:

template <typename T>
struct same_type
{
using type = T;
};

// helper type
template <typename T>
using same_type_t = typename same_type<T>::type;

But now it sounds like the same effect + Zhihao’s use case could be handled by something along the lines of this
(quickly hacked together, so might not be the perfect implementation):

// primary template (used for zero types)
template <typename... T>
struct same_type {};

// one type
template <typename T>
struct same_type<T>
{
using type = T;
};

// two types
template <typename T1, typename T2>
struct same_type<T1, T2>
{
using type = std::enable_if_t<std::is_same_v<T1, T2>, T1>;
};

// 3+ types
template <typename T1, typename T2, typename... R>
struct same_type<T1, T2, R...>
{
using type = typename same_type<T1, typename same_type<T2, R...>::type>::type;
};

// helper type
template <typename... T>
using same_type_t = typename same_type<T...>::type;

Use like this:

same_type_t<> // no such type!
same_type_t<int> // int – this could be used as "disable TAD” utility
same_type_t<int, int, int> // int
same_type_t<int, int, float> // no such type!

Now I’m even more convinced that this would be a useful standard utility!

What do you think?
Timur
> --
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1525021f-a437-14cc-38b1-6051e8860262%40gmail.com.

Timur Doumler

unread,
Dec 5, 2017, 4:58:04 PM12/5/17
to std-pr...@isocpp.org
…can be implemented even shorter (below).

And it would be really elegant it std::is_same would be variadic (which it isn’t).

But that’s not the point. The question is: is this utility useful enough?
Timur

// primary template (used for zero types)
template <typename... T>
struct same_type {};

// one type
template <typename T>
struct same_type<T>
{
using type = T;
};

// 2+ types
template <typename T1, typename... R>
struct same_type<T1, R...>
{
using type = std::enable_if_t<std::is_same_v<T1, typename same_type<R...>::type>, T1>;
};

// helper type
template <typename... T>
using same_type_t = typename same_type<T...>::type;

> To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/F80FF425-69C0-4EF6-AD76-6F92FC46C3E2%40timur.audio.

Zhihao Yuan

unread,
Dec 5, 2017, 5:35:35 PM12/5/17
to std-pr...@isocpp.org
On Tue, Dec 5, 2017 at 3:41 PM, Timur Doumler <ma...@timur.audio> wrote:

    same_type_t<>                   // no such type!
    same_type_t<int>             // int – this could be used as "disable TAD” utility
    same_type_t<int, int, int>   // int
    same_type_t<int, int, float> // no such type!


Well, that's very mathematical :) Thanks jbytheway@.

Now I’m even more convinced that this would be a useful standard utility!

What do you think?

Both me and STL@ had use the variadic same_type_t
to implement std::array's deduction guide, but that's
the only concrete use case I found so far.  Using this
to do identity_t's job is acceptable for me though.

John Bytheway

unread,
Dec 7, 2017, 4:57:16 PM12/7/17
to std-pr...@isocpp.org
On 2017-12-05 22:35, Zhihao Yuan wrote:
> On Tue, Dec 5, 2017 at 3:41 PM, Timur Doumler <ma...@timur.audio
> <mailto:ma...@timur.audio>> wrote:
>
>
>     same_type_t<>                   // no such type!
>     same_type_t<int>             // int – this could be used as
> "disable TAD” utility
>     same_type_t<int, int, int>   // int
>     same_type_t<int, int, float> // no such type!
>
>
> Well, that's very mathematical :) Thanks jbytheway@.

You're welcome :). I feel that to be properly mathematical
same_type<>::type should be defined, because all the (zero) arguments
are the same type! But in all use cases I can think of you don't want
to support the zero-arguments case, so the above is probably the better
approach.

> Now I’m even more convinced that this would be a useful standard
> utility!
>
> What do you think?
>
>
> Both me and STL@ had use the variadic same_type_t
> to implement std::array's deduction guide, but that's
> the only concrete use case I found so far.  Using this
> to do identity_t's job is acceptable for me though.

This is also useful any time you want to take a variadic number of
arguments but enforce that they are all of the same type (e.g. a
variadic max function that returns by reference). This is a situation
I've hit a few times.

John Bytheway

Timur Doumler

unread,
Dec 7, 2017, 5:02:00 PM12/7/17
to std-pr...@isocpp.org
> I feel that to be properly mathematical
> same_type<>::type should be defined, because all the (zero) arguments
> are the same type!

I disagree: for same_type<> there is *no type* that is passed in, so it should define *no type* in return. If you’d like to define same_type<>::type, what would you define it to? void? But that is same_type<void>::type. void is a type. void is not no type.
>
> This is also useful any time you want to take a variadic number of
> arguments but enforce that they are all of the same type (e.g. a
> variadic max function that returns by reference). This is a situation
> I've hit a few times.

Interesting. My main question at the moment is whether we should aim to standardise the variadic version, or just the single-type one. I left this question open in the current proposal draft. If it’s the variadic one, it can’t be really justified unless there are real-world use cases.

Cheers,
Timur

Timur Doumler

unread,
Dec 7, 2017, 5:21:33 PM12/7/17
to std-pr...@isocpp.org

>> This is also useful any time you want to take a variadic number of
>> arguments but enforce that they are all of the same type (e.g. a
>> variadic max function that returns by reference). This is a situation
>> I've hit a few times.

John, would it be OK if I mention this use case (along with your name) in the paper?

Thanks,
Timur

John Bytheway

unread,
Dec 7, 2017, 5:39:42 PM12/7/17
to std-pr...@isocpp.org
On 2017-12-07 22:01, Timur Doumler wrote:
>> I feel that to be properly mathematical
>> same_type<>::type should be defined, because all the (zero) arguments
>> are the same type!
>
> I disagree: for same_type<> there is *no type* that is passed in, so it
> should define *no type* in return. If you’d like to define same_type<>::type,
> what would you define it to? void? But that is same_type<void>::type. void is
> a type. void is not no type.

This is a purely academic question. As I said, in practise the useful
choice seems to be the one you made.

But, to clarify my position: it comes comes down to what question you
think this tool is answering.

The question you are answering is "Is there a type which is the same as
all the argument types? If so, define ::type to be that type". The
question I was thinking of was "Are all the argument types the same? If
so, define ::type". There may be cases where you want that latter
behaviour, but I can't think of any, so let's not worry about it.

John

Timur Doumler

unread,
Dec 7, 2017, 5:44:23 PM12/7/17
to std-pr...@isocpp.org
> The question you are answering is "Is there a type which is the same as
> all the argument types? If so, define ::type to be that type”.

Yes, this is generally what I'd expect metafunctions to do: see enable_if, common_type, etc.

> The
> question I was thinking of was "Are all the argument types the same? If
> so, define ::type". There may be cases where you want that latter
> behaviour, but I can't think of any, so let's not worry about it.

This is not the question I had in mind. The answer to this question is a bool value. This is essentially std::is_same, which defines ::value, except that unfortunately std::is_same is not variadic (why not?)

Timur

Timur Doumler

unread,
Dec 7, 2017, 5:45:46 PM12/7/17
to std-pr...@isocpp.org


> On 7 Dec 2017, at 23:44, Timur Doumler <ma...@timur.audio> wrote:
>
>> The question you are answering is "Is there a type which is the same as
>> all the argument types? If so, define ::type to be that type”.
>
> Yes, this is generally what I'd expect metafunctions to do: see enable_if, common_type, etc.

The standardese term for this is a “type transformation” - types as input, types as output.

John Bytheway

unread,
Dec 7, 2017, 6:25:57 PM12/7/17
to std-pr...@isocpp.org
Feel free.

For completeness I will say: although I have a memory of encountering
this situation, I can't (after a quick search) find a specific example,
nor do I remember how I handled it.

In particular, this same_type is good for SFINAEing out such functions
on a type mismatch, whereas I suspect I would have been more likely to
want to static_assert that the argument types were the same (which is
better achieved via a variadic version of std::is_same, such as you
mentioned in your other post).

So, although this is certainly a potential use case, I cannot claim to
have explored it well.

John

Zhihao Yuan

unread,
Dec 10, 2017, 6:57:59 AM12/10/17
to std-pr...@isocpp.org
On Thu, Dec 7, 2017 at 5:25 PM, John Bytheway <jbyt...@gmail.com> wrote:
I suspect I would have been more likely to
want to static_assert that the argument types were the same (which is
better achieved via a variadic version of std::is_same

It doesn't have to be variadic if you can rewrite the
template parameters

  template <typename... T>

into

  template <typename T, typename... U>

and use

  static_assert(std::is_same_v<T, U> && ...);

or enable_if_t, and that's how std::array deduction guide
being specified in the standard.  For this use case,

  -> same_type_t<T...>

is a shortcut to

  -> enable_if_t<std::is_same_v<T, U> && ...>

Different sfinae traits can function at the same time:

  template <typename... T,
            std::enable_if_t<..., int> = 0,
            typename = same_type_t<T...>>

, so adding such a trait doesn't make the <type_traits>
less composable.

Timur Doumler

unread,
Jan 3, 2018, 5:10:44 PM1/3/18
to ISO C++ Standard - Future Proposals, z...@miator.net
After some discussion at the BSI, the consensus was that conflating the identity type transformation and the variadic same_type into one thing is confusing and wrong, and that therefore same_type is not a good name for the former. This was followed by an extended bikeshedding about another name, with identity and type emerging as the only viable options.

I have written up the latest state in the current paper draft:

Any feedback would be very much appreciated.

Thanks,
Timur

Zhihao Yuan

unread,
Jan 3, 2018, 6:46:29 PM1/3/18
to std-pr...@isocpp.org

UTC Time: January 3, 2018 10:10 PM
From: goo...@timur.audio

After some discussion at the BSI, the consensus was that conflating the identity type transformation and the variadic same_type into one thing is confusing and wrong, and that therefore same_type is not a good name for the former. This was followed by an extended bikeshedding about another name, with identity and type emerging as the only viable options.

Works for me :)

I have written up the latest state in the current paper draft:

Nice work, though I'll still vote for "identity."

Jakob Riedle

unread,
Jan 18, 2018, 5:53:24 PM1/18/18
to ISO C++ Standard - Future Proposals, z...@miator.net
Nice Job!
Reply all
Reply to author
Forward
0 new messages