It also allows us to suppress a standard deduction from the above process via "= delete;"
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
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
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 ofunique_ptr(pointer p) -> deletewhich of course isn't possible in C++17. Or maybe I just didn't get it? Please someone enlighten me.
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/32992ae4-41fa-440f-acf1-c1825488262c%40isocpp.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.
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 disabledThat 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.
--
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 view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzubf3%2BZ-UPciYj0CkbeQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/775CACA7-EB8F-4EDF-A298-0B102B2AB2F8%40timur.audio.
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?
--
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/CAGsORuAOG6YdtQSSwmTZ3O4hLF_O0EA8ZsCKvu-RPFXmaYu%2BsA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02BCAFE2-2224-4945-AD10-BA076B3DE8C4%40timur.audio.
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?
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
UTC Time: January 3, 2018 10:10 PMFrom: 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.
I have written up the latest state in the current paper draft: