------=_Part_402_193166953.1470158095384
Content-Type: multipart/alternative;
 boundary="----=_Part_403_1833807638.1470158095384"

------=_Part_403_1833807638.1470158095384
Content-Type: text/plain; charset=UTF-8


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?

--
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/9ef5033c-9d63-4b0d-b8aa-e5fc50939ee7%40isocpp.org.

------=_Part_403_1833807638.1470158095384
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div><div><div>The proposal p0091R3 says, in prose und=
er &quot;Explicitly specified deduction guides&quot;,</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1p=
x; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding=
-left: 1ex;"><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">It=
 also allows us to suppress a standard deduction from the above process via=
 &quot;</font><tt style=3D"color: rgb(0, 0, 0); font-family: &quot;Times Ne=
w Roman&quot;; font-size: medium;">=3D delete;&quot;=C2=A0</tt></blockquote=
><div>but the proposed wording and what is now in n4606 does not seem to al=
low that: deduction-guide ends with=C2=A0simple-template-id and semicolon.<=
br></div><div><br></div><div>Was that intentional, and if so, how do we sup=
press unwelcome implicit deductions?</div></div></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&quot; 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/9ef5033c-9d63-4b0d-b8aa-e5fc50939ee7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9ef5033c-9d63-4b0d-b8aa-e5fc50939ee7=
%40isocpp.org</a>.<br />

------=_Part_403_1833807638.1470158095384--

------=_Part_402_193166953.1470158095384--

.

On Tue, Aug 2, 2016 at 12:14 PM, Sergey Zubkov <cubbimew@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?
>

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-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/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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CABsSThqx_CPe9EirBoaUcsgaJ04cCk0Pvqgf%2B0w_Ky-_urfvPw%40mail.gmail.com.

.

--001a11400ee6e463560539432711
Content-Type: text/plain; charset=UTF-8

On 2 Aug 2016 10:15 a.m., "Sergey Zubkov" <cubbimew@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-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/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-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm%2B9O0RpFWt%3DrLnwwN1dt4TPjfbUcMZX_vpbqRXNeQBYg%40mail.gmail.com.

--001a11400ee6e463560539432711
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On 2 Aug 2016 10:15 a.m., &quot;Sergey Zubkov&quot; &lt;<a h=
ref=3D"mailto:cubbimew@gmail.com">cubbimew@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; The proposal p0091R3 says, in prose under &quot;Explicitly specified d=
eduction guides&quot;,<br>
&gt;&gt;<br>
&gt;&gt; It also allows us to suppress a standard deduction from the above =
process via &quot;=3D delete;&quot;=C2=A0<br>
&gt;<br>
&gt; but the proposed wording and what is now in n4606 does not seem to all=
ow that: deduction-guide ends with=C2=A0simple-template-id and semicolon.<b=
r>
&gt;<br>
&gt; Was that intentional, and if so, how do we suppress unwelcome implicit=
 deductions?</p>
<p dir=3D"ltr">Like this:</p>
<p dir=3D"ltr">template&lt;typename T&gt; struct nondeducible_impl { using =
type =3D T; };</p>
<p dir=3D"ltr">template&lt;typename T&gt; using nondeducible =3D typename n=
ondeducible_impl&lt;T&gt;::type;</p>
<p dir=3D"ltr">template&lt;typename T&gt; struct X {<br>
=C2=A0 X(nondeducible&lt;T&gt;);<br>
};<br>
X x=3D0; // error, can&#39;t deduce T</p>
<p dir=3D"ltr">&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/9ef5033c-9d63-4b0d-b8aa-e5fc5093=
9ee7%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/9ef5033c-9d63-4b0d-b8aa-e5fc50939ee7%40isocpp.org</a>.<br></p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAOfiQqm%2B9O0RpFWt%3DrLnwwN1dt4TPjfb=
UcMZX_vpbqRXNeQBYg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqm%2B9O=
0RpFWt%3DrLnwwN1dt4TPjfbUcMZX_vpbqRXNeQBYg%40mail.gmail.com</a>.<br />

--001a11400ee6e463560539432711--

.

------=_Part_1283_1973785640.1470373322764
Content-Type: multipart/alternative;
 boundary="----=_Part_1284_820780552.1470373322764"

------=_Part_1284_820780552.1470373322764
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 4 sierpnia 2016 20:31:21 UTC+2 u=C5=BCytkownik Richard Smi=
th=20
napisa=C5=82:
>
> On 2 Aug 2016 10:15 a.m., "Sergey Zubkov" <cubb...@gmail.com <javascript:=
>>=20
> wrote:
> >
> >
> > The proposal p0091R3 says, in prose under "Explicitly specified=20
> deduction guides",
> >>
> >> It also allows us to suppress a standard deduction from the above=20
> process via "=3D delete;"=20
> >
> > but the proposed wording and what is now in n4606 does not seem to allo=
w=20
> that: deduction-guide ends with simple-template-id and semicolon.
> >
> > Was that intentional, and if so, how do we suppress unwelcome implicit=
=20
> deductions?
>
> Like this:
>
> template<typename T> struct nondeducible_impl { using type =3D T; };
>
> template<typename T> using nondeducible =3D typename=20
> nondeducible_impl<T>::type;
>
> template<typename T> struct X {
>   X(nondeducible<T>);
> };
> X x=3D0; // error, can't deduce T
>

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

--=20
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 e=
mail 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/e18a92c5-c0b3-4fd7-bb15-e0e5426ed696%40isocpp.or=
g.

------=_Part_1284_820780552.1470373322764
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>W dniu czwartek, 4 sierpnia 2016 20:31:21 UTC+2 u=
=C5=BCytkownik Richard Smith napisa=C5=82:<blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><p dir=3D"ltr">On 2 Aug 2016 10:15 a.m., &quot;Sergey Zubkov&qu=
ot; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
ayVIIbqlBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">cubb...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; The proposal p0091R3 says, in prose under &quot;Explicitly specified d=
eduction guides&quot;,<br>
&gt;&gt;<br>
&gt;&gt; It also allows us to suppress a standard deduction from the above =
process via &quot;=3D delete;&quot;=C2=A0<br>
&gt;<br>
&gt; but the proposed wording and what is now in n4606 does not seem to all=
ow that: deduction-guide ends with=C2=A0simple-template-id and semicolon.<b=
r>
&gt;<br>
&gt; Was that intentional, and if so, how do we suppress unwelcome implicit=
 deductions?</p>
<p dir=3D"ltr">Like this:</p>
<p dir=3D"ltr">template&lt;typename T&gt; struct nondeducible_impl { using =
type =3D T; };</p>
<p dir=3D"ltr">template&lt;typename T&gt; using nondeducible =3D typename n=
ondeducible_impl&lt;T&gt;::type;</p>
<p dir=3D"ltr">template&lt;typename T&gt; struct X {<br>
=C2=A0 X(nondeducible&lt;T&gt;);<br>
};<br>
X x=3D0; // error, can&#39;t deduce T</p></blockquote><div><br>There is som=
e disconnection:<br>=C2=A0- implicit deduction guides will be automatically=
 generated for the existing code, including 3rdParty classes that the progr=
ammer cannot modify<br>=C2=A0- to disable implicit deduction guide the code=
 of the class need to be modified<br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/e18a92c5-c0b3-4fd7-bb15-e0e5426ed696%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e18a92c5-c0b3-4fd7-bb15-e0e5426ed696=
%40isocpp.org</a>.<br />

------=_Part_1284_820780552.1470373322764--

------=_Part_1283_1973785640.1470373322764--

.

On Fri, Aug 5, 2016 at 12:02 AM, Tomasz <tomaszkam@gmail.com> wrote:
>
>
> W dniu czwartek, 4 sierpnia 2016 20:31:21 UTC+2 u=C5=BCytkownik Richard S=
mith
> napisa=C5=82:
>>
>> 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 "=3D delete;"
>> >
>> > but the proposed wording and what is now in n4606 does not seem to all=
ow
>> > 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 =3D T; };
>>
>> template<typename T> using nondeducible =3D typename
>> nondeducible_impl<T>::type;
>>
>> template<typename T> struct X {
>>   X(nondeducible<T>);
>> };
>> X x=3D0; // 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 modi=
fy
>  - to disable implicit deduction guide the code of the class need to be
> modified

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-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/e18a92c5-c0b=
3-4fd7-bb15-e0e5426ed696%40isocpp.org.

--=20
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 e=
mail 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/CABsSTho5TZq_s%2BDH4unWH9s%3DbTJHzhCvDrzbUu3uZ4d=
5VdPe3g%40mail.gmail.com.

.

------=_Part_8513_1900296952.1511287137277
Content-Type: multipart/alternative;
 boundary="----=_Part_8514_1102173000.1511287137277"

------=_Part_8514_1102173000.1511287137277
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry for resurrecting this thread, but does anyone know why it was decided=
=20
not to have deleted deduction guides as a language facility? Richard's=20
solution feels like unnecessarily verbose to me (having to introduce a=20
helper type in order to break the deduction guide).

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

=E2=80=9CIf class template argument deduction would select the function tem=
plate=20
corresponding to this constructor, then the program is ill-formed.=E2=80=9D

What is the suggested implementation strategy for this? It is surprising to=
=20
me that the standard enforces such a constraint but provides no facility to=
=20
express this constraint in C++ code. I would like to disable CTAD in such a=
=20
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?=20
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 <javascript:=
>>=20
> wrote:
> >
> >
> > The proposal p0091R3 says, in prose under "Explicitly specified=20
> deduction guides",
> >>
> >> It also allows us to suppress a standard deduction from the above=20
> process via "=3D delete;"=20
> >
> > but the proposed wording and what is now in n4606 does not seem to allo=
w=20
> that: deduction-guide ends with simple-template-id and semicolon.
> >
> > Was that intentional, and if so, how do we suppress unwelcome implicit=
=20
> deductions?
>
> Like this:
>
> template<typename T> struct nondeducible_impl { using type =3D T; };
>
> template<typename T> using nondeducible =3D typename=20
> nondeducible_impl<T>::type;
>
> template<typename T> struct X {
>   X(nondeducible<T>);
> };
> X x=3D0; // error, can't deduce T
>
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..
> > To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ef5033c-9d6=
3-4b0d-b8aa-e5fc50939ee7%40isocpp.org
> .
>

--=20
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 e=
mail 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/32992ae4-41fa-440f-acf1-c1825488262c%40isocpp.or=
g.

------=_Part_8514_1102173000.1511287137277
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry for resurrecting this thread, but does anyone know w=
hy it was decided not to have deleted deduction guides as a language facili=
ty? Richard&#39;s solution feels like unnecessarily verbose to me (having t=
o introduce a helper type in order to break the deduction guide).<div><br><=
div>A related question: the constructor <font face=3D"courier new, monospac=
e">explicit unique_ptr(pointer p)</font> has the following note in the stan=
dard:</div><div><br></div><div>=E2=80=9CIf class template argument deductio=
n would select the function template corresponding to this constructor, the=
n the program is ill-formed.=E2=80=9D</div><div><br></div><div>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 th=
is constraint in C++ code. I would like to disable CTAD in such a case with=
 something along the lines of</div><div><br></div><div><span style=3D"font-=
family: &quot;courier new&quot;, monospace;">unique_ptr(pointer p) -&gt; de=
lete</span><br></div><div><span style=3D"font-family: &quot;courier new&quo=
t;, monospace;"><br></span></div><div>which of course isn&#39;t possible in=
 C++17. Or maybe I just didn&#39;t get it? Please someone enlighten me.</di=
v><div><br></div><div>Thanks,</div><div>Timur<br><div><div><br><div><div><b=
r>On Thursday, August 4, 2016 at 8:31:21 PM UTC+2, Richard Smith wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">On 2 Aug 2016 10:15=
 a.m., &quot;Sergey Zubkov&quot; &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"ayVIIbqlBwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">cubb...@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; The proposal p0091R3 says, in prose under &quot;Explicitly specified d=
eduction guides&quot;,<br>
&gt;&gt;<br>
&gt;&gt; It also allows us to suppress a standard deduction from the above =
process via &quot;=3D delete;&quot;=C2=A0<br>
&gt;<br>
&gt; but the proposed wording and what is now in n4606 does not seem to all=
ow that: deduction-guide ends with=C2=A0simple-template-id and semicolon.<b=
r>
&gt;<br>
&gt; Was that intentional, and if so, how do we suppress unwelcome implicit=
 deductions?</p>
<p dir=3D"ltr">Like this:</p>
<p dir=3D"ltr">template&lt;typename T&gt; struct nondeducible_impl { using =
type =3D T; };</p>
<p dir=3D"ltr">template&lt;typename T&gt; using nondeducible =3D typename n=
ondeducible_impl&lt;T&gt;::type;</p>
<p dir=3D"ltr">template&lt;typename T&gt; struct X {<br>
=C2=A0 X(nondeducible&lt;T&gt;);<br>
};<br>
X x=3D0; // error, can&#39;t deduce T</p>
<p dir=3D"ltr">&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"ayVIIbqlBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">std-proposal...@<wbr>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"ayVIIbqlBwAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/9ef5033c-9d63-4b0d-b8aa-e5fc5093=
9ee7%40isocpp.org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9ef=
5033c-9d63-4b0d-b8aa-e5fc50939ee7%40isocpp.org&#39;;return true;" onclick=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/9ef5033c-9d63-4b0d-b8aa-e5fc50939ee7%40isocpp.org&#39;;return true;"=
>https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/9ef=
5033c-9d63-4b0d-<wbr>b8aa-e5fc50939ee7%40isocpp.org</a><wbr>.<br></p>
</blockquote></div></div></div></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/32992ae4-41fa-440f-acf1-c1825488262c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/32992ae4-41fa-440f-acf1-c1825488262c=
%40isocpp.org</a>.<br />

------=_Part_8514_1102173000.1511287137277--

------=_Part_8513_1900296952.1511287137277--

.

--001a11c185eaaf83f1055e837c8e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On 21 November 2017 at 09:58, Timur Doumler <google@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).
>

=3Ddelete is simply wrong as a way of removing an implicit deduction guide.
=3Ddelete means "participates in overload resolution, the program is
ill-formed if it's selected", not "remove this from the overload set". And
indeed =3Ddelete 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:
>
> =E2=80=9CIf class template argument deduction would select the function t=
emplate
> corresponding to this constructor, then the program is ill-formed.=E2=80=
=9D
>
> What is the suggested implementation strategy for this? It is surprising
> to me that the standard enforces such a constraint but provides no facili=
ty
> 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 "=3D 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 =3D T; };
>>
>> template<typename T> using nondeducible =3D typename
>> nondeducible_impl<T>::type;
>>
>> template<typename T> struct X {
>>   X(nondeducible<T>);
>> };
>> X x=3D0; // 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/i=
s
>> ocpp.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-proposals@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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/32992ae4-41=
fa-440f-acf1-c1825488262c%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=20
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 e=
mail 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/CAOfiQq%3DKtgadTNUqk%3DLirjteMamdh75XHxQa2MSc9ES=
FAFG6oQ%40mail.gmail.com.

--001a11c185eaaf83f1055e837c8e
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 2=
1 November 2017 at 09:58, Timur Doumler <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:google@timur.audio" target=3D"_blank">google@timur.audio</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Sorry for resur=
recting this thread, but does anyone know why it was decided not to have de=
leted deduction guides as a language facility? Richard&#39;s solution feels=
 like unnecessarily verbose to me (having to introduce a helper type in ord=
er to break the deduction guide).</div></blockquote><div><br></div><div>=3D=
delete is simply wrong as a way of removing an implicit deduction guide. =
=3Ddelete means &quot;participates in overload resolution, the program is i=
ll-formed if it&#39;s selected&quot;, not &quot;remove this from the overlo=
ad set&quot;. And indeed =3Ddelete might be useful for deduction guides as =
a &quot;honeypot&quot; for undesirable deductions, just as it&#39;s useful =
in other overload sets. But it does not solve the problem at hand.</div><di=
v><br></div><div>Also, the idea is that the helper type would become a stan=
dard library facility, rather than something that users reinvent.</div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>A rela=
ted question: the constructor <font face=3D"courier new, monospace">explici=
t unique_ptr(pointer p)</font> has the following note in the standard:</div=
><div><br></div><div>=E2=80=9CIf class template argument deduction would se=
lect the function template corresponding to this constructor, then the prog=
ram is ill-formed.=E2=80=9D</div><div><br></div><div>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 constra=
int in C++ code. I would like to disable CTAD in such a case with something=
 along the lines of</div><div><br></div><div><span style=3D"font-family:&qu=
ot;courier new&quot;,monospace">unique_ptr(pointer p) -&gt; delete</span><b=
r></div><div><span style=3D"font-family:&quot;courier new&quot;,monospace">=
<br></span></div><div>which of course isn&#39;t possible in C++17. Or maybe=
 I just didn&#39;t get it? Please someone enlighten me.</div></div></div></=
blockquote><div><br></div><div>I think that&#39;s a wording error. The &quo=
t;pointer&quot; member type is computed from the template parameters (based=
 on whether &#39;typename remove_reference_t&lt;D&gt;::pointer&#39; is vali=
d), so that constructor can never be used for deduction anyway.</div><div><=
br></div><div>(Technically, an implementation could choose to model that di=
stinction with a partial specialization of the unique_ptr template instead =
of locally in the definition of the &quot;pointer&quot; member; perhaps thi=
s wording is trying to say what happens for an implementation that does so?=
)</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div><div>Thanks,</div><div>Timur<br><div><div><br><div><div><br>On Thursd=
ay, August 4, 2016 at 8:31:21 PM UTC+2, Richard Smith wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr">On 2 Aug 2016 10:1=
5 a.m., &quot;Sergey Zubkov&quot; &lt;<a rel=3D"nofollow">cubb...@gmail.com=
</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; The proposal p0091R3 says, in prose under &quot;Explicitly specified d=
eduction guides&quot;,<br>
&gt;&gt;<br>
&gt;&gt; It also allows us to suppress a standard deduction from the above =
process via &quot;=3D delete;&quot;=C2=A0<br>
&gt;<br>
&gt; but the proposed wording and what is now in n4606 does not seem to all=
ow that: deduction-guide ends with=C2=A0simple-template-id and semicolon.<b=
r>
&gt;<br>
&gt; Was that intentional, and if so, how do we suppress unwelcome implicit=
 deductions?</p>
<p dir=3D"ltr">Like this:</p>
<p dir=3D"ltr">template&lt;typename T&gt; struct nondeducible_impl { using =
type =3D T; };</p>
<p dir=3D"ltr">template&lt;typename T&gt; using nondeducible =3D typename n=
ondeducible_impl&lt;T&gt;::type;</p>
<p dir=3D"ltr">template&lt;typename T&gt; struct X {<br>
=C2=A0 X(nondeducible&lt;T&gt;);<br>
};<br>
X x=3D0; // error, can&#39;t deduce T</p>
</span><p dir=3D"ltr"><span class=3D"">&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...@iso=
cpp.org</a>.<span class=3D""><br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/9ef5033c-9d63-4b0d-b8aa-e5fc5093=
9ee7%40isocpp.org" rel=3D"nofollow" target=3D"_blank">https://groups.google=
..com/a/is<wbr>ocpp.org/d/msgid/std-proposals<wbr>/9ef5033c-9d63-4b0d-b8aa-<=
wbr>e5fc50939ee7%40isocpp.org</a>.<br></span></p>
</blockquote></div></div></div></div></div></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/32992ae4-41fa-440f-acf1-c1825488262c%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3299=
2ae4-41fa-440f-<wbr>acf1-c1825488262c%40isocpp.org</a><wbr>.<br>
</blockquote></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&quot; 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/CAOfiQq%3DKtgadTNUqk%3DLirjteMamdh75X=
HxQa2MSc9ESFAFG6oQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DKtg=
adTNUqk%3DLirjteMamdh75XHxQa2MSc9ESFAFG6oQ%40mail.gmail.com</a>.<br />

--001a11c185eaaf83f1055e837c8e--

.

--Apple-Mail=_D752942A-E4D2-439D-B233-9232985A2256
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"


> On 21 Nov 2017, at 20:48, Richard Smith <richard@metafoo.co.uk> wrote:
> =3Ddelete is simply wrong as a way of removing an implicit deduction guid=
e. =3Ddelete means "participates in overload resolution, the program is ill=
-formed if it's selected", not "remove this from the overload set". And ind=
eed =3Ddelete might be useful for deduction guides as a "honeypot" for unde=
sirable 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 =3D 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 th=
is purpose? Such as std::identity (or std::same_type or whatever name). The=
n people don=E2=80=99t have to declare their own structs just for the purpo=
se 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

--=20
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 e=
mail 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/ADA71213-69E4-40AD-9B9B-9CEF726C9B9B%40timur.aud=
io.

--Apple-Mail=_D752942A-E4D2-439D-B233-9232985A2256
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 21 Nov 2017, at 2=
0:48, Richard Smith &lt;<a href=3D"mailto:richard@metafoo.co.uk" class=3D""=
>richard@metafoo.co.uk</a>&gt; wrote:</div><div class=3D""><div dir=3D"ltr"=
 style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font=
-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-al=
ign: start; text-indent: 0px; text-transform: none; white-space: normal; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><div class=3D"">=3Ddelete is simply=
 wrong as a way of removing an implicit deduction guide. =3Ddelete means "p=
articipates in overload resolution, the program is ill-formed if it's selec=
ted", not "remove this from the overload set". And indeed =3Ddelete might b=
e useful for deduction guides as a "honeypot" for undesirable deductions, j=
ust as it's useful in other overload sets. But it does not solve the proble=
m at hand.</div></div></div></div></div></blockquote><div><br class=3D""></=
div><div>Yes, makes total sense, thanks for the clarification.</div></div><=
br class=3D""><div class=3D"">Re: your technique of disabling CTAD: actuall=
y quite a few people are aware of this technique and use it also to disable=
 argument deduction for normal templated functions, e.g.:</div><div class=
=3D""><br class=3D""></div><div class=3D""><div class=3D"">template&lt;type=
name T&gt; struct identity {</div><div class=3D"">&nbsp; &nbsp;using T =3D =
type;</div><div class=3D"">};</div><div class=3D""><br class=3D""></div><di=
v class=3D"">template&lt;typename T&gt; void foo(identity&lt;T&gt;::type x)=
; &nbsp;// TAD disabled</div></div><div class=3D""><br class=3D""></div><di=
v class=3D"">That makes me think whether we should have a little standard u=
tility for this purpose? Such as std::identity (or std::same_type or whatev=
er name). Then people don=E2=80=99t have to declare their own structs just =
for the purpose of disabling TAD. Of course you could achieve the same effe=
ct with std::common_type&lt;T&gt; or std::enable_if_t&lt;true, T&gt; but th=
at feels like a hack.</div><div class=3D""><br class=3D""></div><div class=
=3D"">What do you think?</div><div class=3D""><br class=3D""></div><div cla=
ss=3D"">Cheers,</div><div class=3D"">Timur</div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/ADA71213-69E4-40AD-9B9B-9CEF726C9B9B%=
40timur.audio?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/ADA71213-69E4-40AD-9B9B-9CEF726C9B9=
B%40timur.audio</a>.<br />

--Apple-Mail=_D752942A-E4D2-439D-B233-9232985A2256--

.

--001a114a7d3e47f2f0055e972439
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 22, 2017 at 10:29 AM, Timur Doumler <mail@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 =3D 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=E2=80=99t 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 ha=
ck.
>

We reviewed
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3766.html
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.

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

--=20
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 e=
mail 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/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzubf3%2BZ-UPc=
iYj0CkbeQ%40mail.gmail.com.

--001a114a7d3e47f2f0055e972439
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 22, 2017 at 10:29 AM, Timur Doumler <span dir=
=3D"ltr">&lt;<a target=3D"_blank" href=3D"mailto:mail@timur.audio">mail@tim=
ur.audio</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div sty=
le=3D"word-wrap:break-word">actually quite a few people are aware of this t=
echnique and use it also to disable argument deduction for normal templated=
 functions, e.g.:<div><br></div><div><div>template&lt;typename T&gt; struct=
 identity {</div><div>=C2=A0 =C2=A0using T =3D type;</div><div>};</div><div=
><br></div><div>template&lt;typename T&gt; void foo(identity&lt;T&gt;::type=
 x); =C2=A0// TAD disabled</div></div><div><br></div><div>That makes me thi=
nk 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=E2=
=80=99t 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&lt;=
T&gt; or std::enable_if_t&lt;true, T&gt; but that feels like a hack.</div><=
/div></blockquote><div><br></div><div>We reviewed <a href=3D"http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/papers/2013/n3766.html">http://www.open-std.o=
rg/jtc1/sc22/wg21/docs/papers/2013/n3766.html</a><br></div><div>a couple of=
 years ago, but couldn&#39;t decide a name<br>for it.=C2=A0 Maybe you can w=
rite a paper and convince<br>us to stick with some name.<br></div></div><br=
>-- <br><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"lt=
r"><div><div dir=3D"ltr"><div>Zhihao Yuan, ID lichray<br>The best way to pr=
edict the future is to invent it.<br>______________________________________=
_________<br></div></div></div></div></div></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzu=
bf3%2BZ-UPciYj0CkbeQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuAeK%=
2BE55%2BXFUaJPYCq1wTD8Cqzubf3%2BZ-UPciYj0CkbeQ%40mail.gmail.com</a>.<br />

--001a114a7d3e47f2f0055e972439--

.

--Apple-Mail=_91587694-5EF7-4B92-8EB2-6DA8093303C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Thanks for this paper link!

I=E2=80=99d be happy to write a new paper, and my gut feeling says that ide=
ntity<T> is the best name because then I can write identity_t<T> and it=E2=
=80=99d also be consistent with boost::mpl::identity<T> which is exactly th=
e 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 tha=
t discussion and understand why it didn=E2=80=99t happen back then =E2=80=
=93 because there must be good reasons.

Timur

> On 22 Nov 2017, at 20:15, Zhihao Yuan <zy@miator.net> wrote:
>=20
> On Wed, Nov 22, 2017 at 10:29 AM, Timur Doumler <mail@timur.audio <mailto=
:mail@timur.audio>> wrote:
>=20
> actually quite a few people are aware of this technique and use it also t=
o disable argument deduction for normal templated functions, e.g.:
>=20
> template<typename T> struct identity {
>    using T =3D type;
> };
>=20
> template<typename T> void foo(identity<T>::type x);  // TAD disabled
>=20
> 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). T=
hen people don=E2=80=99t have to declare their own structs just for the pur=
pose 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.
>=20
> We reviewed http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3766=
..html <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3766.html>
> 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.
>=20
> --=20
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>=20
> --=20
> You received this message because you are subscribed to a topic in the Go=
ogle 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 <https://groups.google.co=
m/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubscribe@isocpp.or=
g>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzubf3%2BZ-U=
PciYj0CkbeQ%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msgi=
d/std-proposals/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzubf3%2BZ-UPciYj0CkbeQ%4=
0mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter>.

--=20
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 e=
mail 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/775CACA7-EB8F-4EDF-A298-0B102B2AB2F8%40timur.aud=
io.

--Apple-Mail=_91587694-5EF7-4B92-8EB2-6DA8093303C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">Thanks for this pa=
per link!<div class=3D""><br class=3D""></div><div class=3D"">I=E2=80=99d b=
e happy to write a new paper, and my gut feeling says that identity&lt;T&gt=
; is the best name because then I can write identity_t&lt;T&gt; and it=E2=
=80=99d also be consistent with boost::mpl::identity&lt;T&gt; which is exac=
tly the same thing and has been around for ages.</div><div class=3D""><br c=
lass=3D""></div><div class=3D"">But it seems like all of this has already b=
een ruminated by WG21 years ago, so before writing anything I should perhap=
s try to find the minutes of that discussion and understand why it didn=E2=
=80=99t happen back then =E2=80=93 because there must be good reasons.</div=
><div class=3D""><br class=3D""></div><div class=3D"">Timur</div><div class=
=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div class=
=3D"">On 22 Nov 2017, at 20:15, Zhihao Yuan &lt;<a href=3D"mailto:zy@miator=
..net" class=3D"">zy@miator.net</a>&gt; wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On Wed, Nov 22,=
 2017 at 10:29 AM, Timur Doumler <span dir=3D"ltr" class=3D"">&lt;<a target=
=3D"_blank" href=3D"mailto:mail@timur.audio" class=3D"">mail@timur.audio</a=
>&gt;</span> wrote:<br class=3D""><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><br class=3D""><blockquote style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quot=
e"><div style=3D"word-wrap:break-word" class=3D"">actually quite a few peop=
le are aware of this technique and use it also to disable argument deductio=
n for normal templated functions, e.g.:<div class=3D""><br class=3D""></div=
><div class=3D""><div class=3D"">template&lt;typename T&gt; struct identity=
 {</div><div class=3D"">&nbsp; &nbsp;using T =3D type;</div><div class=3D""=
>};</div><div class=3D""><br class=3D""></div><div class=3D"">template&lt;t=
ypename T&gt; void foo(identity&lt;T&gt;::type x); &nbsp;// TAD disabled</d=
iv></div><div class=3D""><br class=3D""></div><div class=3D"">That makes me=
 think whether we should have a little standard utility for this purpose? S=
uch as std::identity (or std::same_type or whatever name). Then people don=
=E2=80=99t have to declare their own structs just for the purpose of disabl=
ing TAD. Of course you could achieve the same effect with std::common_type&=
lt;T&gt; or std::enable_if_t&lt;true, T&gt; but that feels like a hack.</di=
v></div></blockquote><div class=3D""><br class=3D""></div><div class=3D"">W=
e reviewed <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20=
13/n3766.html" class=3D"">http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2013/n3766.html</a><br class=3D""></div><div class=3D"">a couple of years=
 ago, but couldn't decide a name<br class=3D"">for it.&nbsp; Maybe you can =
write a paper and convince<br class=3D"">us to stick with some name.<br cla=
ss=3D""></div></div><br class=3D"">-- <br class=3D""><div class=3D"gmail_si=
gnature"><div dir=3D"ltr" class=3D""><div class=3D""><div dir=3D"ltr" class=
=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Zhihao Yu=
an, ID lichray<br class=3D"">The best way to predict the future is to inven=
t it.<br class=3D"">_______________________________________________<br clas=
s=3D""></div></div></div></div></div></div></div>
</div></div><div class=3D""><br class=3D"webkit-block-placeholder"></div>

-- <br class=3D"">
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe" class=3D"">http=
s://groups.google.com/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubs=
cribe</a>.<br class=3D"">
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">std-proposals+u=
nsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzu=
bf3%2BZ-UPciYj0CkbeQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" class=3D"">https://groups.google.com/a/isocpp.org/d/msgid/std-propos=
als/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzubf3%2BZ-UPciYj0CkbeQ%40mail.gmail.=
com</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/775CACA7-EB8F-4EDF-A298-0B102B2AB2F8%=
40timur.audio?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/775CACA7-EB8F-4EDF-A298-0B102B2AB2F=
8%40timur.audio</a>.<br />

--Apple-Mail=_91587694-5EF7-4B92-8EB2-6DA8093303C7--

.

--Apple-Mail=_A4910452-BAA6-4321-9BEA-A0F1C5D11E3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

OK, now that I have read up on the history of this whole thing, my understa=
nding that this feature is considered very useful is confirmed. Afaiu, std:=
:identity was rejected because of two reasons:

- the name =E2=80=9Cidentity=E2=80=9D can=E2=80=99t be used because it clas=
hes with a legacy SGI extension of the standard library that is still in us=
e,
- the original version also had an operator() which caused all kinds of oth=
er issues.

This <http://wiki.edg.com/bin/view/Wg21chicago2013/N3766?twiki_redirect_cac=
he=3D0e6e2def25a040c026d25c1d149bbee0> discussion said LEWG wants the featu=
re, but it never lead to an updated paper afaics. Later, many people said i=
t should be brought back *without the operator()* and there was bikesheddin=
g on the name here <https://groups.google.com/a/isocpp.org/forum/#!topic/st=
d-proposals/MNLrC_F7BTc>  including identity_of<T>, same<T>, omit_from_dedu=
ction<T>, =E2=80=A6 but no one has actually proposed this thing again since=
 then.

I=E2=80=99d really like to have this, because 1) a standard facility greatl=
y improves teachability of this useful =E2=80=9Cdisable deduction=E2=80=9D =
idiom and 2) the idiom is more relevant than ever because in C++17 we got C=
TAD and you can use it there, too.

I prefer the name same_type because it is consistent with other metafunctio=
ns like common_type and underlying_type, and its usage in code would be ver=
y self-explanatory: =E2=80=9CI am using the same type, but going through th=
is helper struct for a reason=E2=80=9D. I also have reasons for disliking t=
he other proposed names.

I=E2=80=99d be ready to write this all up in a new, concise proposal  =E2=
=80=93 if someone could please confirm that this wouldn=E2=80=99t be a wast=
e of LEWG/LWG=E2=80=99s time?

Thanks,
Timur


> On 22 Nov 2017, at 20:29, Timur Doumler <mail@timur.audio> wrote:
>=20
> Thanks for this paper link!
>=20
> I=E2=80=99d be happy to write a new paper, and my gut feeling says that i=
dentity<T> is the best name because then I can write identity_t<T> and it=
=E2=80=99d also be consistent with boost::mpl::identity<T> which is exactly=
 the same thing and has been around for ages.
>=20
> But it seems like all of this has already been ruminated by WG21 years ag=
o, so before writing anything I should perhaps try to find the minutes of t=
hat discussion and understand why it didn=E2=80=99t happen back then =E2=80=
=93 because there must be good reasons.
>=20
> Timur
>=20
>> On 22 Nov 2017, at 20:15, Zhihao Yuan <zy@miator.net <mailto:zy@miator.n=
et>> wrote:
>>=20
>> On Wed, Nov 22, 2017 at 10:29 AM, Timur Doumler <mail@timur.audio <mailt=
o:mail@timur.audio>> wrote:
>>=20
>> actually quite a few people are aware of this technique and use it also =
to disable argument deduction for normal templated functions, e.g.:
>>=20
>> template<typename T> struct identity {
>>    using T =3D type;
>> };
>>=20
>> template<typename T> void foo(identity<T>::type x);  // TAD disabled
>>=20
>> 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=E2=80=99t have to declare their own structs just for the pu=
rpose of disabling TAD. Of course you could achieve the same effect with st=
d::common_type<T> or std::enable_if_t<true, T> but that feels like a hack.
>>=20
>> We reviewed http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n376=
6.html <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3766.html>
>> 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.
>>=20
>> --=20
>> Zhihao Yuan, ID lichray
>> The best way to predict the future is to invent it.
>> _______________________________________________
>>=20
>> --=20
>> You received this message because you are subscribed to a topic in the G=
oogle 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 <https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe>.
>> To unsubscribe from this group and all its topics, send an email to std-=
proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubscribe@isocpp.o=
rg>.
>> To post to this group, send email to std-proposals@isocpp.org <mailto:st=
d-proposals@isocpp.org>.
>> To view this discussion on the web visit https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzubf3%2BZ-=
UPciYj0CkbeQ%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msg=
id/std-proposals/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzubf3%2BZ-UPciYj0CkbeQ%=
40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter>.
>=20
>=20
> --=20
> You received this message because you are subscribed to a topic in the Go=
ogle 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 <https://groups.google.co=
m/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubscribe@isocpp.or=
g>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/775CACA7-EB8F-4EDF-A298-0B102B2AB2F8%40timur.a=
udio <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/775CACA7=
-EB8F-4EDF-A298-0B102B2AB2F8%40timur.audio?utm_medium=3Demail&utm_source=3D=
footer>.

--=20
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 e=
mail 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/432767FF-E32B-49CA-A0F8-3F376C25BCCE%40timur.aud=
io.

--Apple-Mail=_A4910452-BAA6-4321-9BEA-A0F1C5D11E3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">OK, now that I hav=
e read up on the history of this whole thing, my understanding that this fe=
ature is considered very useful is confirmed. Afaiu, std::identity was reje=
cted because of two reasons:<div class=3D""><br class=3D""></div><div class=
=3D"">- the name =E2=80=9Cidentity=E2=80=9D can=E2=80=99t be used because i=
t clashes with a legacy SGI extension of the standard library that is still=
 in use,</div><div class=3D"">- the original version also had an operator()=
 which caused all kinds of other issues.</div><div class=3D""><br class=3D"=
"></div><div class=3D""><a href=3D"http://wiki.edg.com/bin/view/Wg21chicago=
2013/N3766?twiki_redirect_cache=3D0e6e2def25a040c026d25c1d149bbee0" class=
=3D"">This</a>&nbsp;discussion said LEWG wants the feature, but it never le=
ad to an updated paper afaics. Later, many people said it should be brought=
 back *without the operator()* and there was bikeshedding on the name&nbsp;=
<a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposa=
ls/MNLrC_F7BTc" class=3D"">here</a>&nbsp; including identity_of&lt;T&gt;, s=
ame&lt;T&gt;, omit_from_deduction&lt;T&gt;, =E2=80=A6 but no one has actual=
ly proposed this thing again since then.</div><div class=3D""><br class=3D"=
"></div><div class=3D"">I=E2=80=99d really like to have this, because 1) a =
standard facility greatly improves teachability of this useful =E2=80=9Cdis=
able deduction=E2=80=9D idiom and 2) the idiom is more relevant than ever b=
ecause in C++17 we got CTAD and you can use it there, too.</div><div class=
=3D""><br class=3D""></div><div class=3D"">I prefer the name same_type beca=
use it is consistent with other metafunctions like common_type and underlyi=
ng_type, and its usage in code would be very self-explanatory: =E2=80=9CI a=
m using the <i class=3D"">same type</i>, but going through this helper stru=
ct for a reason=E2=80=9D. I also have reasons for disliking the other propo=
sed names.</div><div class=3D""><br class=3D""></div><div class=3D"">I=E2=
=80=99d be ready to write this all up in a new, concise proposal &nbsp;=E2=
=80=93 if someone could please confirm that this wouldn=E2=80=99t be a wast=
e of LEWG/LWG=E2=80=99s time?</div><div class=3D""><br class=3D""></div><di=
v class=3D"">Thanks,</div><div class=3D"">Timur</div><div class=3D""><br cl=
ass=3D""><div class=3D""><div class=3D""><div class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 22 Nov 2017, at 2=
0:29, Timur Doumler &lt;<a href=3D"mailto:mail@timur.audio" class=3D"">mail=
@timur.audio</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><d=
iv class=3D""><meta http-equiv=3D"Content-Type" content=3D"text/html charse=
t=3Dutf-8" class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mod=
e: space; -webkit-line-break: after-white-space;" class=3D"">Thanks for thi=
s paper link!<div class=3D""><br class=3D""></div><div class=3D"">I=E2=80=
=99d be happy to write a new paper, and my gut feeling says that identity&l=
t;T&gt; is the best name because then I can write identity_t&lt;T&gt; and i=
t=E2=80=99d also be consistent with boost::mpl::identity&lt;T&gt; which is =
exactly the same thing and has been around for ages.</div><div class=3D""><=
br class=3D""></div><div class=3D"">But it seems like all of this has alrea=
dy been ruminated by WG21 years ago, so before writing anything I should pe=
rhaps try to find the minutes of that discussion and understand why it didn=
=E2=80=99t happen back then =E2=80=93 because there must be good reasons.</=
div><div class=3D""><br class=3D""></div><div class=3D"">Timur</div><div cl=
ass=3D""><br class=3D""><div class=3D""><blockquote type=3D"cite" class=3D"=
"><div class=3D"">On 22 Nov 2017, at 20:15, Zhihao Yuan &lt;<a href=3D"mail=
to:zy@miator.net" class=3D"">zy@miator.net</a>&gt; wrote:</div><br class=3D=
"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">On =
Wed, Nov 22, 2017 at 10:29 AM, Timur Doumler <span dir=3D"ltr" class=3D"">&=
lt;<a target=3D"_blank" href=3D"mailto:mail@timur.audio" class=3D"">mail@ti=
mur.audio</a>&gt;</span> wrote:<br class=3D""><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><br class=3D""><blockquote style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=
=3D"gmail_quote"><div style=3D"word-wrap:break-word" class=3D"">actually qu=
ite a few people are aware of this technique and use it also to disable arg=
ument deduction for normal templated functions, e.g.:<div class=3D""><br cl=
ass=3D""></div><div class=3D""><div class=3D"">template&lt;typename T&gt; s=
truct identity {</div><div class=3D"">&nbsp; &nbsp;using T =3D type;</div><=
div class=3D"">};</div><div class=3D""><br class=3D""></div><div class=3D""=
>template&lt;typename T&gt; void foo(identity&lt;T&gt;::type x); &nbsp;// T=
AD disabled</div></div><div class=3D""><br class=3D""></div><div class=3D""=
>That makes me think whether we should have a little standard utility for t=
his purpose? Such as std::identity (or std::same_type or whatever name). Th=
en people don=E2=80=99t have to declare their own structs just for the purp=
ose of disabling TAD. Of course you could achieve the same effect with std:=
:common_type&lt;T&gt; or std::enable_if_t&lt;true, T&gt; but that feels lik=
e a hack.</div></div></blockquote><div class=3D""><br class=3D""></div><div=
 class=3D"">We reviewed <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2013/n3766.html" class=3D"">http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2013/n3766.html</a><br class=3D""></div><div class=3D"">a co=
uple of years ago, but couldn't decide a name<br class=3D"">for it.&nbsp; M=
aybe you can write a paper and convince<br class=3D"">us to stick with some=
 name.<br class=3D""></div></div><br class=3D"">-- <br class=3D""><div clas=
s=3D"gmail_signature"><div dir=3D"ltr" class=3D""><div class=3D""><div dir=
=3D"ltr" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=
=3D"">Zhihao Yuan, ID lichray<br class=3D"">The best way to predict the fut=
ure is to invent it.<br class=3D"">________________________________________=
_______<br class=3D""></div></div></div></div></div></div></div>
</div></div><div class=3D""><br class=3D"webkit-block-placeholder"></div>

-- <br class=3D"">
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe" class=3D"">http=
s://groups.google.com/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubs=
cribe</a>.<br class=3D"">
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">std-proposals+u=
nsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzu=
bf3%2BZ-UPciYj0CkbeQ%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" class=3D"">https://groups.google.com/a/isocpp.org/d/msgid/std-propos=
als/CAGsORuAeK%2BE55%2BXFUaJPYCq1wTD8Cqzubf3%2BZ-UPciYj0CkbeQ%40mail.gmail.=
com</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></div><div class=3D""><br cla=
ss=3D"webkit-block-placeholder"></div>

-- <br class=3D"">
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe" class=3D"">http=
s://groups.google.com/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubs=
cribe</a>.<br class=3D"">
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">std-proposals+u=
nsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/775CACA7-EB8F-4EDF-A298-0B102B2AB2F8%=
40timur.audio?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"">https:=
//groups.google.com/a/isocpp.org/d/msgid/std-proposals/775CACA7-EB8F-4EDF-A=
298-0B102B2AB2F8%40timur.audio</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></div></div></div></body></ht=
ml>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/432767FF-E32B-49CA-A0F8-3F376C25BCCE%=
40timur.audio?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/432767FF-E32B-49CA-A0F8-3F376C25BCC=
E%40timur.audio</a>.<br />

--Apple-Mail=_A4910452-BAA6-4321-9BEA-A0F1C5D11E3D--

.

--001a113d075857f571055e9cb2db
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <mail@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: =E2=80=9CI am using the *same type*, but =
going
> through this helper struct for a reason=E2=80=9D. 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=E2=80=99d be ready to write this all up in a new, concise proposal  =E2=
=80=93 if someone
> could please confirm that this wouldn=E2=80=99t be a waste of LEWG/LWG=E2=
=80=99s time?
>

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

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

--=20
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 e=
mail 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/CAGsORuAOG6YdtQSSwmTZ3O4hLF_O0EA8ZsCKvu-RPFXmaYu=
%2BsA%40mail.gmail.com.

--001a113d075857f571055e9cb2db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mail@timur.audio" target=3D"_blank">mail@tim=
ur.audio</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-w=
ord">I prefer the name same_type because it is consistent with other metafu=
nctions like common_type and underlying_type, and its usage in code would b=
e very self-explanatory: =E2=80=9CI am using the <i>same type</i>, but goin=
g through this helper struct for a reason=E2=80=9D. I also have reasons for=
 disliking the other proposed names.</div></blockquote><div><br></div><div>=
A different same_type, similar to common_type, would be<br>a trait taking a=
 list of types, then define `type` member<br>when they are the same -- I ha=
ve been using this, so I feel<br>that your naming suggestion is ambiguous.<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-w=
ord"><div>I=E2=80=99d be ready to write this all up in a new, concise propo=
sal =C2=A0=E2=80=93 if someone could please confirm that this wouldn=E2=80=
=99t be a waste of LEWG/LWG=E2=80=99s time?</div></div></blockquote><div><b=
r></div><div>Nobody can say yes or no, but given the evidences, it&#39;s cl=
ear<br>that LEWG would love to see that.<br></div><div><br></div></div>-- <=
br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div d=
ir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Zhihao Yuan, ID=
 lichray<br>The best way to predict the future is to invent it.<br>________=
_______________________________________<br></div></div></div></div></div></=
div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAGsORuAOG6YdtQSSwmTZ3O4hLF_O0EA8ZsCK=
vu-RPFXmaYu%2BsA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuAOG6YdtQ=
SSwmTZ3O4hLF_O0EA8ZsCKvu-RPFXmaYu%2BsA%40mail.gmail.com</a>.<br />

--001a113d075857f571055e9cb2db--

.

--Apple-Mail-D0700B58-A1E0-435C-B670-48EF2D7864F2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ok, thanks Zhihao! I=E2=80=99ll think harder about the name and write a pro=
posal for Jacksonville.

> On 23 Nov 2017, at 02:53, Zhihao Yuan <zy@miator.net> wrote:
>=20
>> On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <mail@timur.audio> wrote:
>> I prefer the name same_type because it is consistent with other metafunc=
tions like common_type and underlying_type, and its usage in code would be =
very self-explanatory: =E2=80=9CI am using the same type, but going through=
 this helper struct for a reason=E2=80=9D. I also have reasons for dislikin=
g the other proposed names.
>=20
> 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.
>=20
>> I=E2=80=99d be ready to write this all up in a new, concise proposal  =
=E2=80=93 if someone could please confirm that this wouldn=E2=80=99t be a w=
aste of LEWG/LWG=E2=80=99s time?
>=20
> Nobody can say yes or no, but given the evidences, it's clear
> that LEWG would love to see that.
>=20
> --=20
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
> --=20
> You received this message because you are subscribed to a topic in the Go=
ogle 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-p=
roposals+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/isoc=
pp.org/d/msgid/std-proposals/CAGsORuAOG6YdtQSSwmTZ3O4hLF_O0EA8ZsCKvu-RPFXma=
Yu%2BsA%40mail.gmail.com.

--=20
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 e=
mail 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/02BCAFE2-2224-4945-AD10-BA076B3DE8C4%40timur.aud=
io.

--Apple-Mail-D0700B58-A1E0-435C-B670-48EF2D7864F2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div>Ok, thanks Zhihao! I=E2=
=80=99ll think harder about the name and write a proposal for Jacksonville.=
</div><div><br>On 23 Nov 2017, at 02:53, Zhihao Yuan &lt;<a href=3D"mailto:=
zy@miator.net">zy@miator.net</a>&gt; wrote:<br><br></div><blockquote type=
=3D"cite"><div><div dir=3D"ltr">On Wed, Nov 22, 2017 at 3:43 PM, Timur Doum=
ler <span dir=3D"ltr">&lt;<a href=3D"mailto:mail@timur.audio" target=3D"_bl=
ank">mail@timur.audio</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word=
-wrap:break-word">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: =E2=80=9CI am using the <i>same type<=
/i>, but going through this helper struct for a reason=E2=80=9D. I also hav=
e reasons for disliking the other proposed names.</div></blockquote><div><b=
r></div><div>A different same_type, similar to common_type, would be<br>a t=
rait taking a list of types, then define `type` member<br>when they are the=
 same -- I have been using this, so I feel<br>that your naming suggestion i=
s ambiguous.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word=
-wrap:break-word"><div>I=E2=80=99d be ready to write this all up in a new, =
concise proposal &nbsp;=E2=80=93 if someone could please confirm that this =
wouldn=E2=80=99t be a waste of LEWG/LWG=E2=80=99s time?</div></div></blockq=
uote><div><br></div><div>Nobody can say yes or no, but given the evidences,=
 it's clear<br>that LEWG would love to see that.<br></div><div><br></div></=
div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature=
"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Zhihao =
Yuan, ID lichray<br>The best way to predict the future is to invent it.<br>=
_______________________________________________<br></div></div></div></div>=
</div></div></div>
</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe">https://groups.=
google.com/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe</a>.<=
br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+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/CAGsORuAOG6YdtQSSwmTZ3O4hLF_O0EA8ZsCK=
vu-RPFXmaYu%2BsA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuAOG6=
YdtQSSwmTZ3O4hLF_O0EA8ZsCKvu-RPFXmaYu%2BsA%40mail.gmail.com</a>.<br>
</div></blockquote></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/02BCAFE2-2224-4945-AD10-BA076B3DE8C4%=
40timur.audio?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/02BCAFE2-2224-4945-AD10-BA076B3DE8C=
4%40timur.audio</a>.<br />

--Apple-Mail-D0700B58-A1E0-435C-B670-48EF2D7864F2--

.

--Apple-Mail=_DA3D65AD-5CA9-4F49-99C5-9383A619B696
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

Coming back to the original question: =3Ddelete-ing explicit guides. As Ric=
hard said, they are useful as =E2=80=9Choneypots=E2=80=9D. Here=E2=80=99s 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 f=
loat, double, or long double is unspecified.=E2=80=9D

It might therefore be desirable to disable the deduction, issue a compiler =
error along the lines of =E2=80=9Cargument deduction failed: deduction guid=
e was marked as deleted=E2=80=9D, and force the user to explicitly type out=
 the template arguments if she really wants to instantiate complex<int>. (T=
his example might be flawed but that=E2=80=99s not the point.)

Afaics here <http://wiki.edg.com/bin/view/Wg21kona2017/P0091R4> (last poll)=
, EWG concluded it was an oversight to not have =3Ddelete as a feature in t=
he 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=E2=80=99d b=
e in favour). If no, does anyone know the status of this?

Thanks,
Timur

> On 23 Nov 2017, at 07:36, Timur Doumler <mail@timur.audio> wrote:
>=20
> Ok, thanks Zhihao! I=E2=80=99ll think harder about the name and write a p=
roposal for Jacksonville.
>=20
> On 23 Nov 2017, at 02:53, Zhihao Yuan <zy@miator.net <mailto:zy@miator.ne=
t>> wrote:
>=20
>> On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <mail@timur.audio <mailto=
:mail@timur.audio>> wrote:
>> I prefer the name same_type because it is consistent with other metafunc=
tions like common_type and underlying_type, and its usage in code would be =
very self-explanatory: =E2=80=9CI am using the same type, but going through=
 this helper struct for a reason=E2=80=9D. I also have reasons for dislikin=
g the other proposed names.
>>=20
>> 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.
>>=20
>> I=E2=80=99d be ready to write this all up in a new, concise proposal  =
=E2=80=93 if someone could please confirm that this wouldn=E2=80=99t be a w=
aste of LEWG/LWG=E2=80=99s time?
>>=20
>> Nobody can say yes or no, but given the evidences, it's clear
>> that LEWG would love to see that.
>>=20
>> --=20
>> Zhihao Yuan, ID lichray
>> The best way to predict the future is to invent it.
>> _______________________________________________
>>=20
>> --=20
>> You received this message because you are subscribed to a topic in the G=
oogle 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 <https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe>.
>> To unsubscribe from this group and all its topics, send an email to std-=
proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubscribe@isocpp.o=
rg>.
>> To post to this group, send email to std-proposals@isocpp.org <mailto:st=
d-proposals@isocpp.org>.
>> To view this discussion on the web visit https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/CAGsORuAOG6YdtQSSwmTZ3O4hLF_O0EA8ZsCKvu-RPFXm=
aYu%2BsA%40mail.gmail.com <https://groups.google.com/a/isocpp.org/d/msgid/s=
td-proposals/CAGsORuAOG6YdtQSSwmTZ3O4hLF_O0EA8ZsCKvu-RPFXmaYu%2BsA%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter>.
>=20
>=20
> --=20
> You received this message because you are subscribed to a topic in the Go=
ogle 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 <https://groups.google.co=
m/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to std-p=
roposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubscribe@isocpp.or=
g>.
> To post to this group, send email to std-proposals@isocpp.org <mailto:std=
-proposals@isocpp.org>.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/02BCAFE2-2224-4945-AD10-BA076B3DE8C4%40timur.a=
udio <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02BCAFE2=
-2224-4945-AD10-BA076B3DE8C4%40timur.audio?utm_medium=3Demail&utm_source=3D=
footer>.

--=20
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 e=
mail 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/255A24FC-75B6-4C12-AF80-464723D1945A%40timur.aud=
io.

--Apple-Mail=_DA3D65AD-5CA9-4F49-99C5-9383A619B696
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; line-break: after-white-space;" class=3D"">Coming back to the origina=
l question: =3Ddelete-ing explicit guides. As Richard said, they are useful=
 as =E2=80=9Choneypots=E2=80=9D. Here=E2=80=99s a simple example:<div class=
=3D""><br class=3D""></div><div class=3D"">std::complex c {2, 3}; &nbsp; //=
 deduces std::complex&lt;int&gt;</div><div class=3D""><br class=3D""></div>=
<div class=3D"">However, [complex.numbers] says:</div><div class=3D"">"The =
effect of instantiating the template complex for any type other than float,=
 double, or long double is unspecified.=E2=80=9D</div><div class=3D""><br c=
lass=3D""></div><div class=3D"">It might therefore be desirable to disable =
the deduction, issue a compiler error along the lines of =E2=80=9Cargument =
deduction failed: deduction guide was marked as deleted=E2=80=9D, and force=
 the user to explicitly type out the template arguments if she really wants=
 to instantiate complex&lt;int&gt;. (This example might be flawed but that=
=E2=80=99s not the point.)</div><div class=3D""><br class=3D""></div><div c=
lass=3D"">Afaics&nbsp;<a href=3D"http://wiki.edg.com/bin/view/Wg21kona2017/=
P0091R4" class=3D"">here</a>&nbsp;(last poll),&nbsp;EWG concluded it was an=
 oversight to not have =3Ddelete as a feature in the first place, and decid=
ed that they want to add it as a DR for C++17.</div><div class=3D""><br cla=
ss=3D""></div><div class=3D"">Afaict, nothing happened afterwards.</div><di=
v class=3D""><br class=3D""></div><div class=3D"">Is this correct? If yes, =
should we bring this proposal back? (I=E2=80=99d be in favour). If no, does=
 anyone know the status of this?</div><div class=3D""><br class=3D""></div>=
<div class=3D"">Thanks,</div><div class=3D"">Timur</div><div class=3D""><br=
 class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On 23=
 Nov 2017, at 07:36, Timur Doumler &lt;<a href=3D"mailto:mail@timur.audio" =
class=3D"">mail@timur.audio</a>&gt; wrote:</div><br class=3D"Apple-intercha=
nge-newline"><div class=3D""><meta http-equiv=3D"content-type" content=3D"t=
ext/html; charset=3Dutf-8" class=3D""><div dir=3D"auto" class=3D""><div cla=
ss=3D""></div><div class=3D"">Ok, thanks Zhihao! I=E2=80=99ll think harder =
about the name and write a proposal for Jacksonville.</div><div class=3D"">=
<br class=3D"">On 23 Nov 2017, at 02:53, Zhihao Yuan &lt;<a href=3D"mailto:=
zy@miator.net" class=3D"">zy@miator.net</a>&gt; wrote:<br class=3D""><br cl=
ass=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div di=
r=3D"ltr" class=3D"">On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <span d=
ir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:mail@timur.audio" target=3D"_bl=
ank" class=3D"">mail@timur.audio</a>&gt;</span> wrote:<br class=3D""><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div style=3D"word-wrap:break-word" class=3D"">I prefer the name same_t=
ype because it is consistent with other metafunctions like common_type and =
underlying_type, and its usage in code would be very self-explanatory: =E2=
=80=9CI am using the <i class=3D"">same type</i>, but going through this he=
lper struct for a reason=E2=80=9D. I also have reasons for disliking the ot=
her proposed names.</div></blockquote><div class=3D""><br class=3D""></div>=
<div class=3D"">A different same_type, similar to common_type, would be<br =
class=3D"">a trait taking a list of types, then define `type` member<br cla=
ss=3D"">when they are the same -- I have been using this, so I feel<br clas=
s=3D"">that your naming suggestion is ambiguous.<br class=3D""><br class=3D=
""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"=
 class=3D""><div class=3D"">I=E2=80=99d be ready to write this all up in a =
new, concise proposal &nbsp;=E2=80=93 if someone could please confirm that =
this wouldn=E2=80=99t be a waste of LEWG/LWG=E2=80=99s time?</div></div></b=
lockquote><div class=3D""><br class=3D""></div><div class=3D"">Nobody can s=
ay yes or no, but given the evidences, it's clear<br class=3D"">that LEWG w=
ould love to see that.<br class=3D""></div><div class=3D""><br class=3D""><=
/div></div>-- <br class=3D""><div class=3D"gmail_signature" data-smartmail=
=3D"gmail_signature"><div dir=3D"ltr" class=3D""><div class=3D""><div dir=
=3D"ltr" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=
=3D"">Zhihao Yuan, ID lichray<br class=3D"">The best way to predict the fut=
ure is to invent it.<br class=3D"">________________________________________=
_______<br class=3D""></div></div></div></div></div></div></div>
</div></div><div class=3D""><br class=3D"webkit-block-placeholder"></div>

-- <br class=3D"">
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe" class=3D"">http=
s://groups.google.com/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubs=
cribe</a>.<br class=3D"">
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">std-proposals+u=
nsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGsORuAOG6YdtQSSwmTZ3O4hLF_O0EA8ZsCK=
vu-RPFXmaYu%2BsA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoote=
r" class=3D"">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/=
CAGsORuAOG6YdtQSSwmTZ3O4hLF_O0EA8ZsCKvu-RPFXmaYu%2BsA%40mail.gmail.com</a>.=
<br class=3D"">
</div></blockquote></div><div class=3D""><br class=3D"webkit-block-placehol=
der"></div>

-- <br class=3D"">
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br class=3D"">
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubscribe" class=3D"">http=
s://groups.google.com/a/isocpp.org/d/topic/std-proposals/FGZHgqpYJBk/unsubs=
cribe</a>.<br class=3D"">
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=3D"">std-proposals+u=
nsubscribe@isocpp.org</a>.<br class=3D"">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"">std-proposals@isocpp.org</a>.<br class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/02BCAFE2-2224-4945-AD10-BA076B3DE8C4%=
40timur.audio?utm_medium=3Demail&amp;utm_source=3Dfooter" class=3D"">https:=
//groups.google.com/a/isocpp.org/d/msgid/std-proposals/02BCAFE2-2224-4945-A=
D10-BA076B3DE8C4%40timur.audio</a>.<br class=3D"">
</div></blockquote></div><br class=3D""></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/255A24FC-75B6-4C12-AF80-464723D1945A%=
40timur.audio?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google=
..com/a/isocpp.org/d/msgid/std-proposals/255A24FC-75B6-4C12-AF80-464723D1945=
A%40timur.audio</a>.<br />

--Apple-Mail=_DA3D65AD-5CA9-4F49-99C5-9383A619B696--

.

On 2017-11-23 01:53, Zhihao Yuan wrote:
> On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <mail@timur.audio
> <mailto:mail@timur.audio>> wrote:
>=20
>     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: =E2=80=9CI am using the /same ty=
pe/,
>     but going through this helper struct for a reason=E2=80=9D. I also ha=
ve
>     reasons for disliking the other proposed names.
>=20
>=20
> 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

--=20
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 e=
mail 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/1525021f-a437-14cc-38b1-6051e8860262%40gmail.com=
..

.

--001a11393438dd752e055f9f7366
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 5, 2017 at 3:41 PM, Timur Doumler <mail@timur.audio> wrote:

>
>     same_type_t<>                   // no such type!
>     same_type_t<int>             // int =E2=80=93 this could be used as "=
disable
> TAD=E2=80=9D 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=E2=80=99m even more convinced that this would be a useful standard ut=
ility!
>
> 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.

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

--=20
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 e=
mail 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/CAGsORuDKNz6PSeBME48eC2EypruArh2%2BAZ-Ke75%3DhE4=
0jSGoTg%40mail.gmail.com.

--001a11393438dd752e055f9f7366
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Dec 5, 2017 at 3:41 PM, Timur Doumler <span dir=3D=
"ltr">&lt;<a target=3D"_blank" href=3D"mailto:mail@timur.audio">mail@timur.=
audio</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><br>
=C2=A0 =C2=A0 same_type_t&lt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0// no such type!<br>
=C2=A0 =C2=A0 same_type_t&lt;int&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0// int =E2=80=93 this could be used as &quot;disable TAD=E2=80=9D=
 utility<br>
=C2=A0 =C2=A0 same_type_t&lt;int, int, int&gt;=C2=A0 =C2=A0// int<br>
=C2=A0 =C2=A0 same_type_t&lt;int, int, float&gt; // no such type!<br>
<br></blockquote><div><br></div><div>Well, that&#39;s very mathematical :) =
Thanks jbytheway<wbr>@.<br><br></div><blockquote style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"g=
mail_quote">
Now I=E2=80=99m even more convinced that this would be a useful standard ut=
ility!<br>
<br>
What do you think?<br>
</blockquote></div><br></div><div class=3D"gmail_extra">Both me and STL@ ha=
d use the variadic same_type_t<br>to implement std::array&#39;s deduction g=
uide, but that&#39;s<br>the only concrete use case I found so far.=C2=A0 Us=
ing this<br>to do identity_t&#39;s job is acceptable for me though.<br clea=
r=3D"all"></div><div class=3D"gmail_extra"><br>-- <br><div class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div=
>Zhihao Yuan, ID lichray<br>The best way to predict the future is to invent=
 it.<br>_______________________________________________<br></div></div></di=
v></div></div></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAGsORuDKNz6PSeBME48eC2EypruArh2%2BAZ=
-Ke75%3DhE40jSGoTg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuDKNz6P=
SeBME48eC2EypruArh2%2BAZ-Ke75%3DhE40jSGoTg%40mail.gmail.com</a>.<br />

--001a11393438dd752e055f9f7366--

.

Cool! A very interesting observation I=E2=80=99ve not considered yet.

My original idea was to define the =E2=80=9Cdisable TAD=E2=80=9D utility li=
ke this:

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

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

But now it sounds like the same effect + Zhihao=E2=80=99s 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 {};
   =20
    // one type
    template <typename T>
    struct same_type<T>
    {
       using type =3D T;
    };
   =20
    // two types
    template <typename T1, typename T2>
    struct same_type<T1, T2>
    {
       using type =3D std::enable_if_t<std::is_same_v<T1, T2>, T1>;
    };
   =20
    // 3+ types
    template <typename T1, typename T2, typename... R>
    struct same_type<T1, T2, R...>
    {
       using type =3D typename same_type<T1, typename same_type<T2, R...>::=
type>::type;
    };
   =20
    // helper type
    template <typename... T>
    using same_type_t =3D typename same_type<T...>::type;

Use like this:
  =20
    same_type_t<>                   // no such type!
    same_type_t<int>             // int =E2=80=93 this could be used as "di=
sable TAD=E2=80=9D utility
    same_type_t<int, int, int>   // int
    same_type_t<int, int, float> // no such type!

Now I=E2=80=99m even more convinced that this would be a useful standard ut=
ility!

What do you think?
Timur

> On 5 Dec 2017, at 21:54, John Bytheway <jbytheway@gmail.com> wrote:
>=20
> On 2017-11-23 01:53, Zhihao Yuan wrote:
>> On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <mail@timur.audio
>> <mailto:mail@timur.audio>> wrote:
>>=20
>>    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: =E2=80=9CI am using the /same ty=
pe/,
>>    but going through this helper struct for a reason=E2=80=9D. I also ha=
ve
>>    reasons for disliking the other proposed names.
>>=20
>>=20
>> 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.
>=20
> 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).
>=20
> 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.
>=20
> John Bytheway
>=20
> --=20
> You received this message because you are subscribed to a topic in the Go=
ogle 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-p=
roposals+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/isoc=
pp.org/d/msgid/std-proposals/1525021f-a437-14cc-38b1-6051e8860262%40gmail.c=
om.

--=20
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 e=
mail 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/F80FF425-69C0-4EF6-AD76-6F92FC46C3E2%40timur.aud=
io.

.

=E2=80=A6can be implemented even shorter (below).=20

And it would be really elegant it std::is_same would be variadic (which it =
isn=E2=80=99t).

But that=E2=80=99s not the point. The question is: is this utility useful e=
nough?
Timur

    // primary template (used for zero types)
    template <typename... T>
    struct same_type {};
   =20
    // one type
    template <typename T>
    struct same_type<T>
    {
       using type =3D T;
    };
   =20
    // 2+ types
    template <typename T1, typename... R>
    struct same_type<T1, R...>
    {
       using type =3D std::enable_if_t<std::is_same_v<T1, typename same_typ=
e<R...>::type>, T1>;
    };
   =20
    // helper type
    template <typename... T>
    using same_type_t =3D typename same_type<T...>::type;

> On 5 Dec 2017, at 22:41, Timur Doumler <mail@timur.audio> wrote:
>=20
> Cool! A very interesting observation I=E2=80=99ve not considered yet.
>=20
> My original idea was to define the =E2=80=9Cdisable TAD=E2=80=9D utility =
like this:
>=20
>    template <typename T>
>    struct same_type
>    {
>       using type =3D T;
>    };
>=20
>    // helper type
>    template <typename T>
>    using same_type_t =3D typename same_type<T>::type;
>=20
> But now it sounds like the same effect + Zhihao=E2=80=99s use case could =
be handled by something along the lines of this
> (quickly hacked together, so might not be the perfect implementation):
>=20
>    // primary template (used for zero types)
>    template <typename... T>
>    struct same_type {};
>=20
>    // one type
>    template <typename T>
>    struct same_type<T>
>    {
>       using type =3D T;
>    };
>=20
>    // two types
>    template <typename T1, typename T2>
>    struct same_type<T1, T2>
>    {
>       using type =3D std::enable_if_t<std::is_same_v<T1, T2>, T1>;
>    };
>=20
>    // 3+ types
>    template <typename T1, typename T2, typename... R>
>    struct same_type<T1, T2, R...>
>    {
>       using type =3D typename same_type<T1, typename same_type<T2, R...>:=
:type>::type;
>    };
>=20
>    // helper type
>    template <typename... T>
>    using same_type_t =3D typename same_type<T...>::type;
>=20
> Use like this:
>=20
>    same_type_t<>                   // no such type!
>    same_type_t<int>             // int =E2=80=93 this could be used as "d=
isable TAD=E2=80=9D utility
>    same_type_t<int, int, int>   // int
>    same_type_t<int, int, float> // no such type!
>=20
> Now I=E2=80=99m even more convinced that this would be a useful standard =
utility!
>=20
> What do you think?
> Timur
>=20
>> On 5 Dec 2017, at 21:54, John Bytheway <jbytheway@gmail.com> wrote:
>>=20
>> On 2017-11-23 01:53, Zhihao Yuan wrote:
>>> On Wed, Nov 22, 2017 at 3:43 PM, Timur Doumler <mail@timur.audio
>>> <mailto:mail@timur.audio>> wrote:
>>>=20
>>>   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: =E2=80=9CI am using the /same ty=
pe/,
>>>   but going through this helper struct for a reason=E2=80=9D. I also ha=
ve
>>>   reasons for disliking the other proposed names.
>>>=20
>>>=20
>>> 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.
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> John Bytheway
>>=20
>> --=20
>> You received this message because you are subscribed to a topic in the G=
oogle 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-=
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/iso=
cpp.org/d/msgid/std-proposals/1525021f-a437-14cc-38b1-6051e8860262%40gmail.=
com.
>=20
> --=20
> You received this message because you are subscribed to a topic in the Go=
ogle 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-p=
roposals+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/isoc=
pp.org/d/msgid/std-proposals/F80FF425-69C0-4EF6-AD76-6F92FC46C3E2%40timur.a=
udio.

--=20
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 e=
mail 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/63E499C5-8B92-4474-80BF-0D595AAC5413%40timur.aud=
io.

.

On 2017-12-05 22:35, Zhihao Yuan wrote:
> On Tue, Dec 5, 2017 at 3:41 PM, Timur Doumler <mail@timur.audio
> <mailto:mail@timur.audio>> wrote:
>=20
>=20
>     =C2=A0 =C2=A0 same_type_t<>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0// no such type!
>     =C2=A0 =C2=A0 same_type_t<int>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0// int =E2=80=93 this could be used as
>     "disable TAD=E2=80=9D utility
>     =C2=A0 =C2=A0 same_type_t<int, int, int>=C2=A0 =C2=A0// int
>     =C2=A0 =C2=A0 same_type_t<int, int, float> // no such type!
>=20
>=20
> 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=E2=80=99m even more convinced that this would be a useful stand=
ard
>     utility!
>=20
>     What do you think?
>=20
>=20
> 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.=C2=A0 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

--=20
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 e=
mail 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/a1669b6e-f47e-8633-0b5d-3b394e4acd27%40gmail.com=
..

.

> 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 sho=
uld define *no type* in return. If you=E2=80=99d like to define same_type<>=
::type, what would you define it to? void? But that is same_type<void>::typ=
e. void is a type. void is not no type.
>=20
> 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 sta=
ndardise the variadic version, or just the single-type one. I left this que=
stion open in the current proposal draft. If it=E2=80=99s the variadic one,=
 it can=E2=80=99t be really justified unless there are real-world use cases=
..

Cheers,
Timur

--=20
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 e=
mail 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/DFD5DF16-F870-499C-BFDD-7461593CE514%40timur.aud=
io.

.

>> 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

--
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/9B69078D-D5E8-4860-810C-C5BF61705F44%40timur.audio.

.

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!
>=20
> I disagree: for same_type<> there is *no type* that is passed in, so it
> should define *no type* in return. If you=E2=80=99d like to define same_t=
ype<>::type,
> what would you define it to? void? But that is same_type<void>::type. voi=
d 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

--=20
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 e=
mail 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/fbe0a5ea-d5b0-4e3a-e806-cbc28760bc50%40gmail.com=
..

.

> 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=E2=80=9D. =
=20

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 bo=
ol value. This is essentially std::is_same, which defines ::value, except t=
hat unfortunately std::is_same is not variadic (why not?)

Timur

--=20
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 e=
mail 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/214217A8-F4FB-459E-A452-C5BAA2D57DC8%40timur.aud=
io.

.

> On 7 Dec 2017, at 23:44, Timur Doumler <mail@timur.audio> wrote:
>=20
>> 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=E2=80=9D. =
=20
>=20
> Yes, this is generally what I'd expect metafunctions to do: see enable_if=
, common_type, etc.

The standardese term for this is a =E2=80=9Ctype transformation=E2=80=9D - =
types as input, types as output.

--=20
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 e=
mail 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/239CF989-011D-41F7-8618-5888A51731BB%40timur.aud=
io.

.

On 2017-12-07 22:21, Timur Doumler wrote:
>
>>> 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?

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

--
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/ea77b392-8e28-a16e-3bb8-85624ed77f66%40gmail.com.

.

--001a11411c60b75735055ffb2069
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 7, 2017 at 5:25 PM, John Bytheway <jbytheway@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.

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

--
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/CAGsORuAvXQnf3r-UfCj%3D6ULJCaK6%3DRmRTO0XUZ851gHeC4gT2A%40mail.gmail.com.

--001a11411c60b75735055ffb2069
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Dec 7, 2017 at 5:25 PM, John Bytheway <span dir=3D=
"ltr">&lt;<a target=3D"_blank" href=3D"mailto:jbytheway@gmail.com">jbythewa=
y@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">
I suspect I would have been more likely to<br>
want to static_assert that the argument types were the same (which is<br>
better achieved via a variadic version of std::is_same<br>
</blockquote></div><br>It doesn&#39;t have to be variadic if you can rewrit=
e the<br>template parameters<br><br>=C2=A0 template &lt;typename... T&gt;<b=
r><br>into<br><br>=C2=A0 template &lt;typename T, typename... U&gt;<br><br>=
and use<br><br>=C2=A0 static_assert(std::is_same_v&lt;T, U&gt; &amp;&amp; .=
...);<br><br>or enable_if_t, and that&#39;s how std::array deduction guide<b=
r>being specified in the standard.=C2=A0 For this use case,<br><br>=C2=A0 -=
&gt; same_type_t&lt;T...&gt;<br><br>is a shortcut to<br><br>=C2=A0 -&gt; en=
able_if_t&lt;std::is_same_v&lt;T, U&gt; &amp;&amp; ...&gt;<br><br>Different=
 sfinae traits can function at the same time:<br><br>=C2=A0 template &lt;ty=
pename... T,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 std::enable_if_t&lt;..., int&gt; =3D 0,<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 typename =3D same_type_t&lt;T=
....&gt;&gt;<br><br>, so adding such a trait doesn&#39;t make the &lt;type_t=
raits&gt;<br>less composable.<br></div><div class=3D"gmail_extra"><br>-- <b=
r><div class=3D"gmail-m_-638629901823452546gmail_signature"><div dir=3D"ltr=
"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Zhihao Yuan, ID lichray<=
br>The best way to predict the future is to invent it.<br>_________________=
_____________<wbr>_________________<br></div></div></div></div></div></div>=
</div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CAGsORuAvXQnf3r-UfCj%3D6ULJCaK6%3DRmR=
TO0XUZ851gHeC4gT2A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuAvXQnf=
3r-UfCj%3D6ULJCaK6%3DRmRTO0XUZ851gHeC4gT2A%40mail.gmail.com</a>.<br />

--001a11411c60b75735055ffb2069--

.

------=_Part_623_38205608.1515017444165
Content-Type: multipart/alternative;
 boundary="----=_Part_624_187218937.1515017444166"

------=_Part_624_187218937.1515017444166
Content-Type: text/plain; charset="UTF-8"

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:
https://drive.google.com/open?id=19rrmUCAQhw5_0ONn8qDDliJB3FgVEL7r

Any feedback would be very much appreciated.

Thanks,
Timur

On Sunday, December 10, 2017 at 12:57:59 PM UTC+1, Zhihao Yuan wrote:
>
> On Thu, Dec 7, 2017 at 5:25 PM, John Bytheway <jbyt...@gmail.com
> <javascript:>> 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.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
>

--
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/45f95b4a-2085-4802-b1cb-d63e794316dd%40isocpp.org.

------=_Part_624_187218937.1515017444166
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">After some discussion at the BSI, the consensus was that c=
onflating the identity type transformation and the variadic same_type into =
one thing is confusing and wrong, and that therefore same_type is not a goo=
d name for the former. This was followed by an extended bikeshedding about =
another name, with identity and type emerging as the only viable options.<d=
iv><br></div><div>I have written up the latest state in the current paper d=
raft:</div><div>https://drive.google.com/open?id=3D19rrmUCAQhw5_0ONn8qDDliJ=
B3FgVEL7r</div><div><br></div><div>Any feedback would be very much apprecia=
ted.</div><div><br></div><div>Thanks,</div><div>Timur<br><div><br>On Sunday=
, December 10, 2017 at 12:57:59 PM UTC+1, Zhihao Yuan wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Thu, Dec 7, 2017 at 5:25 =
PM, John Bytheway <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"c3aJHkZ_BQAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">jbyt...@gmail.com</a>&gt;</span> wrote:=
<br><div><div class=3D"gmail_quote"><blockquote style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gm=
ail_quote">
I suspect I would have been more likely to<br>
want to static_assert that the argument types were the same (which is<br>
better achieved via a variadic version of std::is_same<br>
</blockquote></div><br>It doesn&#39;t have to be variadic if you can rewrit=
e the<br>template parameters<br><br>=C2=A0 template &lt;typename... T&gt;<b=
r><br>into<br><br>=C2=A0 template &lt;typename T, typename... U&gt;<br><br>=
and use<br><br>=C2=A0 static_assert(std::is_same_v&lt;<wbr>T, U&gt; &amp;&a=
mp; ...);<br><br>or enable_if_t, and that&#39;s how std::array deduction gu=
ide<br>being specified in the standard.=C2=A0 For this use case,<br><br>=C2=
=A0 -&gt; same_type_t&lt;T...&gt;<br><br>is a shortcut to<br><br>=C2=A0 -&g=
t; enable_if_t&lt;std::is_same_v&lt;T, U&gt; &amp;&amp; ...&gt;<br><br>Diff=
erent sfinae traits can function at the same time:<br><br>=C2=A0 template &=
lt;typename... T,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 std::enable_if_t&lt;..., int&gt; =3D 0,<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 typename =3D same_type_t&l=
t;T...&gt;&gt;<br><br>, so adding such a trait doesn&#39;t make the &lt;typ=
e_traits&gt;<br>less composable.<br></div><div><br>-- <br><div><div dir=3D"=
ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Zhihao Yuan, ID lichr=
ay<br>The best way to predict the future is to invent it.<br>______________=
________________<wbr>_________________<br></div></div></div></div></div></d=
iv></div>
</div></div>
</blockquote></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/45f95b4a-2085-4802-b1cb-d63e794316dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45f95b4a-2085-4802-b1cb-d63e794316dd=
%40isocpp.org</a>.<br />

------=_Part_624_187218937.1515017444166--

------=_Part_623_38205608.1515017444165--

.

This is a multi-part message in MIME format.

--b1_d41bbb7f230ccf265ef9fb93f1bfdefa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> UTC Time: January 3, 2018 10:10 PM
> From: google@timur.audio
>
> After some discussion at the BSI, the consensus was that conflating the i=
dentity type transformation and the variadic same_type into one thing is co=
nfusing 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, w=
ith identity and type emerging as the only viable options.

Works for me :)

> I have written up the latest state in the current paper draft:
> https://drive.google.com/open?id=3D19rrmUCAQhw5_0ONn8qDDliJB3FgVEL7r

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

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

--=20
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 e=
mail 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/SjYcr1ckk-mrQJilHHlc3HO9pBOv4gZg6z2ypkpw2A01ZJY1=
_KfMJAuHEtYfSjR85sPuAWyD0MeFTyTgMSgEiQcgM5BAhLq2nUEYImQ-haM%3D%40miator.net=
..

--b1_d41bbb7f230ccf265ef9fb93f1bfdefa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"><div>UT=
C Time: January 3, 2018 10:10 PM<br></div><div>From: google@timur.audio<br>=
</div><div><br></div><div dir=3D"ltr"><div>After some discussion at the BSI=
, the consensus was that conflating the identity type transformation and th=
e variadic same_type into one thing is confusing and wrong, and that theref=
ore same_type is not a good name for the former. This was followed by an ex=
tended bikeshedding about another name, with identity and type emerging as =
the only viable options.<br></div></div></blockquote><div><br></div><div>Wo=
rks for me :)<br></div><div><br></div><blockquote class=3D"protonmail_quote=
" type=3D"cite"><div dir=3D"ltr"><div>I have written up the latest state in=
 the current paper draft:<br></div><div>https://drive.google.com/open?id=3D=
19rrmUCAQhw5_0ONn8qDDliJB3FgVEL7r<br></div></div></blockquote><div><br></di=
v><div>Nice work, though I'll still vote for "identity."<br></div><div><br>=
</div><div>--<br></div><div class=3D"protonmail_signature_block"><div class=
=3D"protonmail_signature_block-user"><div><div class=3D"protonmail_signatur=
e_block"><div class=3D"protonmail_signature_block-user"><div><span>Zhihao Y=
uan, ID lichray<br>The best way to predict the future is to invent it.<br>_=
______________________________________________</span></div></div><div class=
=3D"protonmail_signature_block-proton protonmail_signature_block-empty"><di=
v><br></div></div></div><div><div><br></div></div></div></div></div><div><b=
r></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/SjYcr1ckk-mrQJilHHlc3HO9pBOv4gZg6z2yp=
kpw2A01ZJY1_KfMJAuHEtYfSjR85sPuAWyD0MeFTyTgMSgEiQcgM5BAhLq2nUEYImQ-haM%3D%4=
0miator.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/SjYcr1ckk-mrQJilHHlc3HO9pBOv4gZg6z2yp=
kpw2A01ZJY1_KfMJAuHEtYfSjR85sPuAWyD0MeFTyTgMSgEiQcgM5BAhLq2nUEYImQ-haM%3D%4=
0miator.net</a>.<br />

--b1_d41bbb7f230ccf265ef9fb93f1bfdefa--


.

------=_Part_2660_920510200.1516316003913
Content-Type: multipart/alternative;
 boundary="----=_Part_2661_974475379.1516316003913"

------=_Part_2661_974475379.1516316003913
Content-Type: text/plain; charset="UTF-8"

Nice Job!

--
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/73ccc6af-79a0-4099-b4fc-57a5c161d22c%40isocpp.org.

------=_Part_2661_974475379.1516316003913
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Nice Job!

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/73ccc6af-79a0-4099-b4fc-57a5c161d22c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73ccc6af-79a0-4099-b4fc-57a5c161d22c=
%40isocpp.org</a>.<br />

------=_Part_2661_974475379.1516316003913--

------=_Part_2660_920510200.1516316003913--

.