Topic: Checking if a variant type can hold a type T
Author: Christopher Di Bella <cjdb.ns@gmail.com>
Date: Wed, 10 May 2017 10:45:20 +0000
Raw View
--001a114471aed196c0054f292bde
Content-Type: text/plain; charset="UTF-8"
Hi everyone,
I'd like to get a feel for whether or not a type_trait would be welcome for
checking if a variant type can hold a type T.
Currently, we have `holds_alternative`, which requires an object, and can't
be evaluated at compile-time for all expressions.
We also have `variant_alternative_t`, but this requires indexing, and
leaves implementing a check to the programmer(s) that need it.
This would be really handy for constraining classes to only accept types
their variants actually take.
```
using Example = std::variant<int, double, std::vector<int>>;
template <typename T> // or enable_if, if you don't have concepts available
requires
can_hold_v<Example, T>
class Foo {
public:
const T& example() const noexcept
{
return std::get<T>(example_);
}
private:
Example example_;
};
```
I asked about this on the Cpplang Slack channel, and Jason Turner helped me
with an implementation at https://godbolt.org/g/p6WUa4.
Please let me know your thoughts.
Cheers,
Chris
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACL3gUU-oBFZLF_MMFMB_xDn1JMVADWNj4Qn1NWAPYQ7gZd4Ww%40mail.gmail.com.
--001a114471aed196c0054f292bde
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi everyone,<div><br></div><div>I'd like to get a feel=
for whether or not a type_trait would be welcome for checking if a variant=
type can hold a type T.</div><div><br></div><div>Currently, we have `holds=
_alternative`, which requires an object, and can't be evaluated at comp=
ile-time for all expressions.</div><div>We also have `variant_alternative_t=
`, but this requires indexing, and leaves implementing a check to the progr=
ammer(s) that need it.</div><div><br></div><div>This would be really handy =
for constraining classes to only accept types their variants actually take.=
</div><div><br></div><div>```</div><div><font face=3D"monospace">using Exam=
ple =3D std::variant<int, double, std::vector<int>>;</font></di=
v><div><font face=3D"monospace"><br></font></div><div><font face=3D"monospa=
ce">template <typename T> // or enable_if, if you don't have conc=
epts available</font></div><div><font face=3D"monospace">requires</font></d=
iv><div><font face=3D"monospace">=C2=A0 =C2=A0can_hold_v<Example, T><=
/font></div><div><font face=3D"monospace">class Foo {</font></div><div><fon=
t face=3D"monospace">public:</font></div><div><font face=3D"monospace">=C2=
=A0 =C2=A0const T& example() const noexcept</font></div><div><font face=
=3D"monospace">=C2=A0 =C2=A0{</font></div><div><font face=3D"monospace">=C2=
=A0 =C2=A0 =C2=A0 return std::get<T>(example_);</font></div><div><fon=
t face=3D"monospace">=C2=A0 =C2=A0}</font></div><div><font face=3D"monospac=
e">private:</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0Example =
example_;</font></div><div><font face=3D"monospace">};</font></div><div>```=
</div><div><br></div><div>I asked about this on the Cpplang Slack channel, =
and Jason Turner helped me with an implementation at=C2=A0<a href=3D"https:=
//godbolt.org/g/p6WUa4">https://godbolt.org/g/p6WUa4</a>.</div><div><br></d=
iv><div>Please let me know your thoughts.</div><div><br></div><div>Cheers,<=
/div><div><br></div><div>Chris</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACL3gUU-oBFZLF_MMFMB_xDn1JMVADWNj4Qn=
1NWAPYQ7gZd4Ww%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACL3gUU-oBFZLF_M=
MFMB_xDn1JMVADWNj4Qn1NWAPYQ7gZd4Ww%40mail.gmail.com</a>.<br />
--001a114471aed196c0054f292bde--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 10 May 2017 10:20:41 -0400
Raw View
--001a1141ca3276a17c054f2c2d0c
Content-Type: text/plain; charset="UTF-8"
On Wed, May 10, 2017 at 6:45 AM, Christopher Di Bella <cjdb.ns@gmail.com>
wrote:
> Hi everyone,
>
> I'd like to get a feel for whether or not a type_trait would be welcome
> for checking if a variant type can hold a type T.
>
> Currently, we have `holds_alternative`, which requires an object, and
> can't be evaluated at compile-time for all expressions.
> We also have `variant_alternative_t`, but this requires indexing, and
> leaves implementing a check to the programmer(s) that need it.
>
> This would be really handy for constraining classes to only accept types
> their variants actually take.
>
Based on your desired usage, you want something slightly different from
what you've requested and different from the implementation you've linked.
You actually want to determine if there is *exactly one* match (as opposed
to 0 or multiple).
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnmoKd6v4E2M17M-c7SdkUtbwfGy6v_bK4kuhC5%3DwC0SA%40mail.gmail.com.
--001a1141ca3276a17c054f2c2d0c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, May 10, 2017 at 6:45 AM, Christopher Di Bella <span dir=3D"ltr"><<a =
href=3D"mailto:cjdb.ns@gmail.com" target=3D"_blank">cjdb.ns@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi ever=
yone,<div><br></div><div>I'd like to get a feel for whether or not a ty=
pe_trait would be welcome for checking if a variant type can hold a type T.=
</div><div><br></div><div>Currently, we have `holds_alternative`, which req=
uires an object, and can't be evaluated at compile-time for all express=
ions.</div><div>We also have `variant_alternative_t`, but this requires ind=
exing, and leaves implementing a check to the programmer(s) that need it.</=
div><div><br></div><div>This would be really handy for constraining classes=
to only accept types their variants actually take.</div></div></blockquote=
><div><br></div><div>Based on your desired usage, you want something slight=
ly different from what you've requested and different from the implemen=
tation you've linked. You actually want to determine if there is *exact=
ly one* match (as opposed to 0 or multiple).</div></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEnmoKd6v4E2M17M-c7SdkUtbwfGy6v_=
bK4kuhC5%3DwC0SA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnmoKd6v4=
E2M17M-c7SdkUtbwfGy6v_bK4kuhC5%3DwC0SA%40mail.gmail.com</a>.<br />
--001a1141ca3276a17c054f2c2d0c--
.
Author: Christopher Di Bella <cjdb.ns@gmail.com>
Date: Wed, 10 May 2017 23:10:42 +0000
Raw View
--f403043edfc87dae2b054f33950c
Content-Type: text/plain; charset="UTF-8"
I don't have any use cases for zero or multiple matches, but only checking
for exactly one match seems like an unnecessary constraint overall.
Would it be a good idea to think of some good cases for zero and multiple
matches, and then come back?
Cheers,
Chris
On Thu., 11 May 2017, 00:20 'Matt Calabrese' via ISO C++ Standard - Future
Proposals, <std-proposals@isocpp.org> wrote:
> On Wed, May 10, 2017 at 6:45 AM, Christopher Di Bella <cjdb.ns@gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> I'd like to get a feel for whether or not a type_trait would be welcome
>> for checking if a variant type can hold a type T.
>>
>> Currently, we have `holds_alternative`, which requires an object, and
>> can't be evaluated at compile-time for all expressions.
>> We also have `variant_alternative_t`, but this requires indexing, and
>> leaves implementing a check to the programmer(s) that need it.
>>
>> This would be really handy for constraining classes to only accept types
>> their variants actually take.
>>
>
> Based on your desired usage, you want something slightly different from
> what you've requested and different from the implementation you've linked.
> You actually want to determine if there is *exactly one* match (as opposed
> to 0 or multiple).
>
> --
> 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-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnmoKd6v4E2M17M-c7SdkUtbwfGy6v_bK4kuhC5%3DwC0SA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnmoKd6v4E2M17M-c7SdkUtbwfGy6v_bK4kuhC5%3DwC0SA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACL3gUUfM%2BRw%2B1oRWWH9PH46biL8jXis7SWfiJOBVM4S1CzimQ%40mail.gmail.com.
--f403043edfc87dae2b054f33950c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't have any use cases for zero or multiple matche=
s, but only checking for exactly one match seems like an unnecessary constr=
aint overall.</div><span>
</span><p dir=3D"ltr">Would it be a good idea to think of some good cases f=
or zero and multiple matches, and then come back? </p><p dir=3D"ltr">Cheers=
,=C2=A0</p><p dir=3D"ltr">Chris</p><span>
</span><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu., 11 May 2017=
, 00:20 'Matt Calabrese' via ISO C++ Standard - Future Proposals, &=
lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-propos=
als@isocpp.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Wed, M=
ay 10, 2017 at 6:45 AM, Christopher Di Bella <span dir=3D"ltr"><<a href=
=3D"mailto:cjdb.ns@gmail.com" target=3D"_blank">cjdb.ns@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi everyone=
,<div><br></div><div>I'd like to get a feel for whether or not a type_t=
rait would be welcome for checking if a variant type can hold a type T.</di=
v><div><br></div><div>Currently, we have `holds_alternative`, which require=
s an object, and can't be evaluated at compile-time for all expressions=
..</div><div>We also have `variant_alternative_t`, but this requires indexin=
g, and leaves implementing a check to the programmer(s) that need it.</div>=
<div><br></div><div>This would be really handy for constraining classes to =
only accept types their variants actually take.</div></div></blockquote><di=
v><br></div></div></div></div><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div>Based on your desired usage, you want someth=
ing slightly different from what you've requested and different from th=
e implementation you've linked. You actually want to determine if there=
is *exactly one* match (as opposed to 0 or multiple).</div></div><br></div=
></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEnmoKd6v4E2M17M-c7SdkUtbwfGy6v_=
bK4kuhC5%3DwC0SA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CANh8DEnmoKd6v4E2M17M-c7SdkUtbwfGy6v_bK4kuhC5%3DwC0SA%40mail.gmail.c=
om</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACL3gUUfM%2BRw%2B1oRWWH9PH46biL8jXis=
7SWfiJOBVM4S1CzimQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACL3gUUfM%2B=
Rw%2B1oRWWH9PH46biL8jXis7SWfiJOBVM4S1CzimQ%40mail.gmail.com</a>.<br />
--f403043edfc87dae2b054f33950c--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Wed, 10 May 2017 17:36:43 -0700 (PDT)
Raw View
------=_Part_4792_1853820397.1494463003727
Content-Type: multipart/alternative;
boundary="----=_Part_4793_854909437.1494463003728"
------=_Part_4793_854909437.1494463003728
Content-Type: text/plain; charset="UTF-8"
On Wednesday, May 10, 2017 at 3:45:32 AM UTC-7, Christopher Di Bella wrote:
>
>
> I'd like to get a feel for whether or not a type_trait would be welcome
> for checking if a variant type can hold a type T.
>
> Currently, we have `holds_alternative`, which requires an object, and
> can't be evaluated at compile-time for all expressions.
> We also have `variant_alternative_t`, but this requires indexing, and
> leaves implementing a check to the programmer(s) that need it.
>
> This would be really handy for constraining classes to only accept types
> their variants actually take.
>
> ```
> using Example = std::variant<int, double, std::vector<int>>;
>
> template <typename T> // or enable_if, if you don't have concepts available
> requires
> can_hold_v<Example, T>
> class Foo {
> public:
> const T& example() const noexcept
> {
> return std::get<T>(example_);
> }
> private:
> Example example_;
> };
> ```
>
> I asked about this on the Cpplang Slack channel, and Jason Turner helped
> me with an implementation at https://godbolt.org/g/p6WUa4
> <https://www.google.com/url?q=https%3A%2F%2Fgodbolt.org%2Fg%2Fp6WUa4&sa=D&sntz=1&usg=AFQjCNEJ8pP9ixjSP25MXGThIDkkdydjgw>
> .
>
As Matt Calabrese said in this thread: it seems like there are a whole lot
of possible semantics here, and you've picked at least two of them.
- "Example matches std::variant<Ts...> where at least one of the Ts is T"
- "Example matches std::variant<Ts...> where exactly one of the Ts is T"
- "Example matches std::variant<Ts...> where exactly one of the Ts is
implicitly convertible from T"
- "Example is implicitly convertible from T"
- "std::get<T>(std::declval<Example>()) is well-formed"
etc. etc.
If you really wanted to write your Foo class template today in C++17, I'd
argue for writing it like this:
template <typename T, typename Enabled =
decltype(std::get<T>(std::declval<Example>()))>
class Foo {
I think there's a market for metaprogramming utilities in the standard
library that would let us write Jason's example as simply std::meta::contains<std::meta::as_typelist<Example>,
T>; but I don't think that really solves your question because your
question is ill-defined.
HTH,
Arthur
>
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a83e3e9-4742-453a-9703-6238c7a860f3%40isocpp.org.
------=_Part_4793_854909437.1494463003728
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, May 10, 2017 at 3:45:32 AM UTC-7, Christophe=
r Di Bella wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><div>I'd like to get a feel for whether or not a typ=
e_trait would be welcome for checking if a variant type can hold a type T.<=
/div><div><br></div><div>Currently, we have `holds_alternative`, which requ=
ires an object, and can't be evaluated at compile-time for all expressi=
ons.</div><div>We also have `variant_alternative_t`, but this requires inde=
xing, and leaves implementing a check to the programmer(s) that need it.</d=
iv><div><br></div><div>This would be really handy for constraining classes =
to only accept types their variants actually take.</div><div><br></div><div=
>```</div><div><font face=3D"monospace">using Example =3D std::variant<i=
nt, double, std::vector<int>>;</font></div><div><font face=3D"mono=
space"><br></font></div><div><font face=3D"monospace">template <typename=
T> // or enable_if, if you don't have concepts available</font></di=
v><div><font face=3D"monospace">requires</font></div><div><font face=3D"mon=
ospace">=C2=A0 =C2=A0can_hold_v<Example, T></font></div><div><font fa=
ce=3D"monospace">class Foo {</font></div><div><font face=3D"monospace">publ=
ic:</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0const T& exa=
mple() const noexcept</font></div><div><font face=3D"monospace">=C2=A0 =C2=
=A0{</font></div><div><font face=3D"monospace">=C2=A0 =C2=A0 =C2=A0 return =
std::get<T>(example_);</font></div><div><font face=3D"monospace">=C2=
=A0 =C2=A0}</font></div><div><font face=3D"monospace">private:</font></div>=
<div><font face=3D"monospace">=C2=A0 =C2=A0Example example_;</font></div><d=
iv><font face=3D"monospace">};</font></div><div>```</div><div><br></div><di=
v>I asked about this on the Cpplang Slack channel, and Jason Turner helped =
me with an implementation at=C2=A0<a href=3D"https://www.google.com/url?q=
=3Dhttps%3A%2F%2Fgodbolt.org%2Fg%2Fp6WUa4&sa=3DD&sntz=3D1&usg=
=3DAFQjCNEJ8pP9ixjSP25MXGThIDkkdydjgw" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgodbolt.org%2Fg%2Fp6WUa4\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEJ8pP9ix=
jSP25MXGThIDkkdydjgw';return true;" onclick=3D"this.href=3D'https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2Fp6WUa4\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNEJ8pP9ixjSP25MXGThIDkkdydjgw';return true;=
">https://godbolt.org/g/<wbr>p6WUa4</a>.</div></div></blockquote><div><br><=
/div><div>As Matt Calabrese said in this thread: it seems like there are a =
whole lot of possible semantics here, and you've picked at least two of=
them.</div><div>- "Example matches std::variant<Ts...> where at=
least one of the Ts is T"</div><div>- "Example matches std::vari=
ant<Ts...> where exactly one of the Ts is T"</div><div><div>- &q=
uot;Example matches std::variant<Ts...> where exactly one of the Ts i=
s implicitly convertible from T"</div></div><div><div>- "Example =
is implicitly convertible from T"</div></div><div>- "std::get<=
T>(std::declval<Example>()) is well-formed"</div><div>etc. et=
c.</div><div><br></div><div>If you really wanted to write your Foo class te=
mplate today in C++17, I'd argue for writing it like this:</div><div><b=
r></div><div><div><font face=3D"monospace">template <typename T, typenam=
e Enabled =3D decltype(std::get<T>(std::declval<Example>()))>=
;</font></div><div><span style=3D"font-family: monospace;">class Foo {</spa=
n><br></div></div><div><br></div><div>I think there's a market for meta=
programming utilities in the standard library that would let us write Jason=
's example as simply=C2=A0<font face=3D"courier new, monospace">std::me=
ta::contains<std::meta::as_typelist<Example>, T></font>; but I =
don't think that really solves your question because your question is i=
ll-defined.</div><div><br></div><div>HTH,</div><div>Arthur</div><blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2a83e3e9-4742-453a-9703-6238c7a860f3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2a83e3e9-4742-453a-9703-6238c7a860f3=
%40isocpp.org</a>.<br />
------=_Part_4793_854909437.1494463003728--
------=_Part_4792_1853820397.1494463003727--
.
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 10 May 2017 23:15:34 -0700 (PDT)
Raw View
------=_Part_4437_431221217.1494483334799
Content-Type: multipart/alternative;
boundary="----=_Part_4438_186342934.1494483334800"
------=_Part_4438_186342934.1494483334800
Content-Type: text/plain; charset="UTF-8"
On Wednesday, May 10, 2017 at 8:36:43 PM UTC-4, Arthur O'Dwyer wrote:
If you really wanted to write your Foo class template today in C++17, I'd
> argue for writing it like this:
>
> template <typename T, typename Enabled =
> decltype(std::get<T>(std::declval<Example>()))>
> class Foo {
>
>
Last time I checked, std::get isn't required to be SFINAE-friendly.
--
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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6a1e727b-e55c-4e55-8d11-fbb6a6f5cc5d%40isocpp.org.
------=_Part_4438_186342934.1494483334800
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, May 10, 2017 at 8:36:43 PM UTC-4, Ar=
thur O'Dwyer wrote:<div><br><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div>If you really wanted to write your Foo class templa=
te today in C++17, I'd argue for writing it like this:</div><div><br></=
div><div><div><font face=3D"monospace">template <typename T, typename En=
abled =3D decltype(std::get<T>(std::<wbr>declval<Example>()))&g=
t;</font></div><div><span style=3D"font-family:monospace">class Foo {</span=
><br></div></div><div><br></div></div></blockquote><div>=C2=A0</div><div>La=
st time I checked, std::get isn't required to be SFINAE-friendly.=C2=A0=
</div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6a1e727b-e55c-4e55-8d11-fbb6a6f5cc5d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6a1e727b-e55c-4e55-8d11-fbb6a6f5cc5d=
%40isocpp.org</a>.<br />
------=_Part_4438_186342934.1494483334800--
------=_Part_4437_431221217.1494483334799--
.