------=_Part_14391_1539532526.1515417521458
Content-Type: multipart/alternative;
 boundary="----=_Part_14392_1778025886.1515417521458"

------=_Part_14392_1778025886.1515417521458
Content-Type: text/plain; charset="UTF-8"

I'd like to relax the requirements of [unique.ptr.single.ctor]/16 to allow
class template argument deduction in the case of a raw pointer and a user
provided deleter.

I propose adding a deduction guide: template<typename T, typename D>
unique_ptr(T* p, D d) -> unique_ptr<T,D>;
In this case the raw pointer type T* shall default to a *non-array* pointer
and operator[] shall be *not *generated.
For raw array pointers, the user will still have to explicitly specify the
template arguments as before if operator[] support is desired.

An initial proposal with more details and based on discussions in the C++
Slack #future_standard, is
here: https://github.com/adishavit/ctad_for_unique_ptr







--
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/9a45af04-2799-45a7-859d-f92b534a2a40%40isocpp.org.

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

<div dir=3D"ltr"><div>I&#39;d like to relax the requirements of [unique.ptr=
..single.ctor]/16 to allow class template argument deduction in the case of =
a raw pointer and a user provided deleter.</div><div><br></div><div>I propo=
se adding a deduction guide: <font face=3D"courier new, monospace">template=
&lt;typename T, typename D&gt; unique_ptr(T* p, D d) -&gt; unique_ptr&lt;T,=
D&gt;;</font></div><div>In this case the raw pointer type <font face=3D"cou=
rier new, monospace">T*</font> shall default to a <i>non-array</i> pointer =
and <font face=3D"courier new, monospace">operator[]</font> shall be <i><b>=
not </b></i>generated.</div><div>For raw array pointers, the user will stil=
l have to explicitly specify the template arguments as before if <font face=
=3D"courier new, monospace">operator[]</font> support is desired.=C2=A0<br>=
</div><div>=C2=A0</div><div>An initial proposal with more details and based=
 on discussions in the C++ Slack #future_standard, is here:=C2=A0https://gi=
thub.com/adishavit/ctad_for_unique_ptr</div><div><br></div><div><br></div><=
div><br></div><div><br></div><div><br></div><div><br></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/9a45af04-2799-45a7-859d-f92b534a2a40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a45af04-2799-45a7-859d-f92b534a2a40=
%40isocpp.org</a>.<br />

------=_Part_14392_1778025886.1515417521458--

------=_Part_14391_1539532526.1515417521458--

.

------=_Part_7217_2047803988.1515426386611
Content-Type: multipart/alternative;
 boundary="----=_Part_7218_191921717.1515426386611"

------=_Part_7218_191921717.1515426386611
Content-Type: text/plain; charset="UTF-8"



On Monday, January 8, 2018 at 8:18:41 AM UTC-5, Adi Shavit wrote:
>
> I'd like to relax the requirements of [unique.ptr.single.ctor]/16 to allow
> class template argument deduction in the case of a raw pointer and a user
> provided deleter.
>
> I propose adding a deduction guide: template<typename T, typename D>
> unique_ptr(T* p, D d) -> unique_ptr<T,D>;
> In this case the raw pointer type T* shall default to a *non-array*
> pointer and operator[] shall be *not *generated.
> For raw array pointers, the user will still have to explicitly specify the
> template arguments as before if operator[] support is desired.
>
> An initial proposal with more details and based on discussions in the C++
> Slack #future_standard, is here:
> https://github.com/adishavit/ctad_for_unique_ptr
>

Besides the problem specified by your proposal, the other big problem is
that if `D` is a deleter that provides a `::pointer` member, your deduction
guide will* ignore it*, instead deducing the pointer type from the
parameter. That's bad.


--
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/e59c9e40-185f-452d-a156-ac8ae4ff489f%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, January 8, 2018 at 8:18:41 AM UTC-5, Ad=
i Shavit wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>I&#39;d like to relax the requirements of [unique.ptr.single.ctor]/1=
6 to allow class template argument deduction in the case of a raw pointer a=
nd a user provided deleter.</div><div><br></div><div>I propose adding a ded=
uction guide: <font face=3D"courier new, monospace">template&lt;typename T,=
 typename D&gt; unique_ptr(T* p, D d) -&gt; unique_ptr&lt;T,D&gt;;</font></=
div><div>In this case the raw pointer type <font face=3D"courier new, monos=
pace">T*</font> shall default to a <i>non-array</i> pointer and <font face=
=3D"courier new, monospace">operator[]</font> shall be <i><b>not </b></i>ge=
nerated.</div><div>For raw array pointers, the user will still have to expl=
icitly specify the template arguments as before if <font face=3D"courier ne=
w, monospace">operator[]</font> support is desired.=C2=A0<br></div><div>=C2=
=A0</div><div>An initial proposal with more details and based on discussion=
s in the C++ Slack #future_standard, is here:=C2=A0<a onmousedown=3D"this.h=
ref=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fadish=
avit%2Fctad_for_unique_ptr\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHfbxZ5pA=
Sdr4u_UJJk1gsxXdQ0Mw&#39;;return true;" onclick=3D"this.href=3D&#39;https:/=
/www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fadishavit%2Fctad_for_un=
ique_ptr\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHfbxZ5pASdr4u_UJJk1gsxXdQ0=
Mw&#39;;return true;" href=3D"https://github.com/adishavit/ctad_for_unique_=
ptr" target=3D"_blank" rel=3D"nofollow">https://github.com/<wbr>adishavit/c=
tad_for_unique_ptr</a></div></div></blockquote><div><br></div><div>Besides =
the problem specified by your proposal, the other big problem is that if `D=
` is a deleter that provides a `::pointer` member, your deduction guide wil=
l<i> ignore it</i>, instead deducing the pointer type from the parameter. T=
hat&#39;s bad.</div><div><i></i>=C2=A0</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/e59c9e40-185f-452d-a156-ac8ae4ff489f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e59c9e40-185f-452d-a156-ac8ae4ff489f=
%40isocpp.org</a>.<br />

------=_Part_7218_191921717.1515426386611--

------=_Part_7217_2047803988.1515426386611--

.

------=_Part_7822_1528770489.1515426806421
Content-Type: multipart/alternative;
 boundary="----=_Part_7823_1315548145.1515426806421"

------=_Part_7823_1315548145.1515426806421
Content-Type: text/plain; charset="UTF-8"


>
>
> Besides the problem specified by your proposal,
>

Which problem are you referring to?


> the other big problem is that if `D` is a deleter that provides a
> `::pointer` member, your deduction guide will* ignore it*, instead
> deducing the pointer type from the parameter. That's bad.
>

As I stated in (the latest revision of) the proposal, I haven't addressed
the `D::pointer` case yet. It was brought up today on Slack - I'm working
on addressing it.
Besides that, I wanted to get the general feel for the proposal and any
comments.

--
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/8cd052c8-4559-4eba-95c0-8e62f05973c0%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><div>Besides the problem specified by your proposal, </d=
iv></div></blockquote><div><br></div><div>Which problem are you referring t=
o?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>the other big problem is that if `D` is a deleter that provides a=
 `::pointer` member, your deduction guide will<i> ignore it</i>, instead de=
ducing the pointer type from the parameter. That&#39;s bad.</div></div></bl=
ockquote><div><br></div><div>As I stated in (the latest revision of) the pr=
oposal, I haven&#39;t addressed the <font face=3D"courier new, monospace">`=
D::pointer`</font> case yet. It was brought up today on Slack - I&#39;m wor=
king on addressing it.</div><div>Besides that, I wanted to get the general =
feel for the proposal and any comments.</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/8cd052c8-4559-4eba-95c0-8e62f05973c0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8cd052c8-4559-4eba-95c0-8e62f05973c0=
%40isocpp.org</a>.<br />

------=_Part_7823_1315548145.1515426806421--

------=_Part_7822_1528770489.1515426806421--

.

------=_Part_1981_785236925.1515441026764
Content-Type: multipart/alternative;
 boundary="----=_Part_1982_563566751.1515441026764"

------=_Part_1982_563566751.1515441026764
Content-Type: text/plain; charset="UTF-8"

The latest revision adds a second deduction guide that correctly handles
`D::pointer` deleters for "fancy pointers".

--
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/d276841c-377b-4da3-816e-a6b67ccfe49a%40isocpp.org.

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

<div dir=3D"ltr">The latest revision adds a second deduction guide that cor=
rectly handles=C2=A0<span style=3D"font-family: &quot;courier new&quot;, mo=
nospace;">`D::pointer`</span><font face=3D"arial, sans-serif"> deleters for=
 &quot;fancy pointers&quot;.</font></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/d276841c-377b-4da3-816e-a6b67ccfe49a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d276841c-377b-4da3-816e-a6b67ccfe49a=
%40isocpp.org</a>.<br />

------=_Part_1982_563566751.1515441026764--

------=_Part_1981_785236925.1515441026764--

.

------=_Part_15627_1181224730.1515442372284
Content-Type: multipart/alternative;
 boundary="----=_Part_15628_1739729704.1515442372284"

------=_Part_15628_1739729704.1515442372284
Content-Type: text/plain; charset="UTF-8"

One problem I see is any side effects when the user uses array which will
be deduced as non-array.

Right now it is only the lack of operator[], but what about in the future?
The standard must be very specific what happen if you "lie" and preferably
promise it will not be a problem.

--
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/0d5efb36-bf92-4938-a5ee-68a567162e6f%40isocpp.org.

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

<div dir=3D"ltr"><div>One problem I see is any side effects when the user u=
ses array which will be deduced as non-array.</div><div><br></div><div>Righ=
t now it is only the lack of operator[], but what about in the future? The =
standard must be very specific what happen if you &quot;lie&quot; and prefe=
rably promise it will not be a problem.<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/0d5efb36-bf92-4938-a5ee-68a567162e6f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0d5efb36-bf92-4938-a5ee-68a567162e6f=
%40isocpp.org</a>.<br />

------=_Part_15628_1739729704.1515442372284--

------=_Part_15627_1181224730.1515442372284--

.

------=_Part_15643_207675202.1515447823366
Content-Type: multipart/alternative;
 boundary="----=_Part_15644_288960240.1515447823366"

------=_Part_15644_288960240.1515447823366
Content-Type: text/plain; charset="UTF-8"


>
> One problem I see is any side effects when the user uses array which will
> be deduced as non-array.
>

What side-effects can these be? You get access to the first element. No ub.
If you want an array pointer, explicitly specify the template type
parameter, like you do today.


> Right now it is only the lack of operator[], but what about in the future?
> The standard must be very specific what happen if you "lie" and preferably
> promise it will not be a problem.
>

I do not know what the future holds.
A raw-pointer has a reduced interface relative to the array pointer.
Using deduction guides gives you clear and concise syntax with the
reduced/subset interface. You cannot have this today anyway.
If you want the extended array-pointer interface, specify the types
explicitly.

I do suggest a hypothetical as_array() function (a-la as_const) that would
be used to indicate a pointer as an array pointer type, but it is unclear
at this time if this is at all possible to implement.


--
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/a20b5ff6-d379-43eb-bc43-4c61253108f2%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>One problem I see is any side effects when the user uses array whi=
ch will be deduced as non-array.</div></div></blockquote><div><br></div><di=
v>What side-effects can these be? You get access to the first element. No u=
b.</div><div>If you want an array pointer, explicitly specify the template =
type parameter, like you do today.</div><div>=C2=A0=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Right now it is only=
 the lack of operator[], but what about in the future? The standard must be=
 very specific what happen if you &quot;lie&quot; and preferably promise it=
 will not be a problem.<br></div></div></blockquote><div><br></div><div>I d=
o not know what the future holds.</div><div>A raw-pointer has a reduced int=
erface relative to the array pointer.</div><div>Using deduction guides give=
s you clear and concise syntax with the reduced/subset interface. You canno=
t have this today anyway.</div><div>If you want the extended array-pointer =
interface, specify the types explicitly.</div><div><br></div><div>I do sugg=
est a hypothetical <font face=3D"courier new, monospace">as_array()</font> =
function (a-la <font face=3D"courier new, monospace">as_const</font>) that =
would be used to indicate a pointer as an array pointer type, but it is unc=
lear at this time if this is at all possible to implement.</div><div>=C2=A0=
=C2=A0</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/a20b5ff6-d379-43eb-bc43-4c61253108f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a20b5ff6-d379-43eb-bc43-4c61253108f2=
%40isocpp.org</a>.<br />

------=_Part_15644_288960240.1515447823366--

------=_Part_15643_207675202.1515447823366--

.

------=_Part_15963_1708677922.1515452618262
Content-Type: multipart/alternative;
 boundary="----=_Part_15964_1496227018.1515452618262"

------=_Part_15964_1496227018.1515452618262
Content-Type: text/plain; charset="UTF-8"

The standard must clear it is fine and always be fine to use array in non
array ptr (as long as you supply the deleter). If the standard does not
have such text already.
It might be obvious to you now, but what if someone proposes to include
this in some "anti-pattern" list as "legacy, before we had array support"?

As for the as_array, I believe a simple tag can solve this.



--
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/78880fd8-b930-4c98-ba32-10ec6d342e4e%40isocpp.org.

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

<div dir=3D"ltr"><div><span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">The standard must clear it is fine and always be fine to use=
 array in non array ptr (as long as you supply the deleter)</span>. If the =
standard does not have such text already. </div><div>It might be obvious to=
 you now, but what if someone proposes to include this in some &quot;anti-p=
attern&quot; list as &quot;legacy, before we had array support&quot;?=C2=A0=
</div><div><br></div><div>As for the as_array, I believe a simple tag can s=
olve this.</div><div><br></div><div><br></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/78880fd8-b930-4c98-ba32-10ec6d342e4e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/78880fd8-b930-4c98-ba32-10ec6d342e4e=
%40isocpp.org</a>.<br />

------=_Part_15964_1496227018.1515452618262--

------=_Part_15963_1708677922.1515452618262--

.

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

>
> The standard must clear it is fine and always be fine to use array in non
> array ptr (as long as you supply the deleter). If the standard does not
> have such text already.
> It might be obvious to you now, but what if someone proposes to include
> this in some "anti-pattern" list as "legacy, before we had array support"?
>

Well, fwiw, raw C pointers double as array pointers. There is no getting
around that and I'm not sure if/how C++ is willing to change that.
This ambiguity/duplicity is inherent in the C[++] type system.

My proposal, lets you have the reduced non-array interface - or first
element only access, if you will.
If you want to *opt-in* to the *array* interface, you should explicitly
state so - just as you do today in C++.

Remember, I am not proposing any changes to unique_ptr or any mistakes
users may make using it.
Today, when you pass a raw pointer, to responsibility to specify T or T[]
is still on the user.
All I am proposing if adding a deduction guide to make the T case more
legible and less error prone.
I do this without to possibility of incurring UB in case of wrong usage -
but there is a limit to how much you can prevent wrong usage.


> As for the as_array, I believe a simple tag can solve this.
>

Only at the deduction guide level without adding new unique_ptr ctor?
Can you show a snippet of how this can work?

--
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/CAEWUs4h1Aovu_1%2B%2BFO_43SCZGwtK7akZRws38_p-FiBkpvxUCg%40mail.gmail.com.

--001a1143e550007f4d0562545673
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><span s=
tyle=3D"float:none;background-color:transparent;color:rgb(34,34,34);font-fa=
mily:Arial,Helvetica,sans-serif;font-size:13px;font-style:normal;font-varia=
nt-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing=
:normal;text-align:left;text-decoration:none;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px;display:inline">The standard must=
 clear it is fine and always be fine to use array in non array ptr (as long=
 as you supply the deleter)</span>. If the standard does not have such text=
 already. </div><div>It might be obvious to you now, but what if someone pr=
oposes to include this in some &quot;anti-pattern&quot; list as &quot;legac=
y, before we had array support&quot;?=C2=A0</div></div></blockquote><div><b=
r></div><div>Well, fwiw, raw C pointers double as array pointers. There is =
no getting around that and I&#39;m not sure if/how C++ is willing to change=
 that.</div><div>This ambiguity/duplicity is inherent in the C[++] type sys=
tem.</div><div><br></div><div>My proposal, lets you have the reduced non-ar=
ray interface=C2=A0- or first element only access, if you will.</div><div>I=
f you want to <i>opt-in</i> to the <i>array</i> interface, you should expli=
citly state so - just as you do today in C++.</div><div><br></div><div>Reme=
mber, I am not proposing any changes to unique_ptr or any mistakes users ma=
y make using it.=C2=A0</div><div>Today, when you pass a raw pointer, to res=
ponsibility to specify T or T[] is still on the user.</div><div>All I am pr=
oposing if adding a deduction guide to make the T case more legible and les=
s error prone.<br></div><div>I do this without to possibility of incurring =
UB in case of wrong usage - but there is a limit to how much you can preven=
t wrong usage.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div>As for the as_array, I believe a simple t=
ag can solve this.<br></div></div></blockquote><div><br></div><div>Only at =
the deduction guide level without adding new unique_ptr ctor?</div><div>Can=
 you show a snippet of how this can work?</div><div><br></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/CAEWUs4h1Aovu_1%2B%2BFO_43SCZGwtK7akZ=
Rws38_p-FiBkpvxUCg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEWUs4h1Aovu=
_1%2B%2BFO_43SCZGwtK7akZRws38_p-FiBkpvxUCg%40mail.gmail.com</a>.<br />

--001a1143e550007f4d0562545673--

.

------=_Part_17081_1139874409.1515490291754
Content-Type: multipart/alternative;
 boundary="----=_Part_17082_991780740.1515490291754"

------=_Part_17082_991780740.1515490291754
Content-Type: text/plain; charset="UTF-8"

unique_ptr<T[]> forbids most implicit pointer conversions, which is an
important safety feature. I don't see that being discussed at all in the
proposal:

struct B {}; struct D : B {};

unique_ptr<B[]> upb(new B[10]);
upb.reset(new D[10]); // error

unique_ptr upb2(new B[10], [](B* p) { delete [] p; });  // unique_ptr<B,
lambda> per proposal
upb2.reset(new D[10]); // UB on destruction


--
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/2ae4cb4c-2b19-42dd-b02b-a7295ba2ea5b%40isocpp.org.

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

<div dir=3D"ltr">unique_ptr&lt;T[]&gt; forbids most implicit pointer conver=
sions, which is an important safety feature. I don&#39;t see that being dis=
cussed at all in the proposal:<div><br></div><div>struct B {}; struct D : B=
 {};=C2=A0</div><div><br></div><div>unique_ptr&lt;B[]&gt; upb(new B[10]);</=
div><div>upb.reset(new D[10]); // error</div><div><br></div><div>unique_ptr=
 upb2(new B[10], [](B* p) { delete [] p; });=C2=A0 // unique_ptr&lt;B, lamb=
da&gt; per proposal</div><div>upb2.reset(new D[10]); // UB on destruction</=
div><div>=C2=A0</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/2ae4cb4c-2b19-42dd-b02b-a7295ba2ea5b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2ae4cb4c-2b19-42dd-b02b-a7295ba2ea5b=
%40isocpp.org</a>.<br />

------=_Part_17082_991780740.1515490291754--

------=_Part_17081_1139874409.1515490291754--

.

------=_Part_7342_263686170.1515493518468
Content-Type: multipart/alternative;
 boundary="----=_Part_7343_1105300062.1515493518468"

------=_Part_7343_1105300062.1515493518468
Content-Type: text/plain; charset="UTF-8"



On Tuesday, January 9, 2018 at 11:14:05 AM UTC+2, Adi Shavit wrote:
>
> The standard must clear it is fine and always be fine to use array in non
>> array ptr (as long as you supply the deleter). If the standard does not
>> have such text already.
>> It might be obvious to you now, but what if someone proposes to include
>> this in some "anti-pattern" list as "legacy, before we had array support"?
>>
>
> Well, fwiw, raw C pointers double as array pointers. There is no getting
> around that and I'm not sure if/how C++ is willing to change that.
> This ambiguity/duplicity is inherent in the C[++] type system.
>
> My proposal, lets you have the reduced non-array interface - or first
> element only access, if you will.
> If you want to *opt-in* to the *array* interface, you should explicitly
> state so - just as you do today in C++.
>
> Remember, I am not proposing any changes to unique_ptr or any mistakes
> users may make using it.
>

The difference is - ATM it is clearly a mistake - the user typed wrong
things on one of the places (the type or the new statement). It is clearly
(literally "clearly") his fault.

With the proposal the mistake is hidden (again, literally) - the user must
*know* guides are for non-arrays only.

Let me be clear - *I am for the proposal to be adopted! *If CTAD arrived
before arrays support, unique_ptr would have gotten a guide.

*However*, "lets just add a guide now" will not cut it am afraid. If that
was the case it would have been done.

There two way to make it work.
One is add a guide, but be very specific (spelled out) it is for non-array
and be clear future standards will not break you or shame you if you use it
for an array (with the risks and limitations involved).
You insist these are implied, but they are not if not written down.

Second (from the top of my head) is to add an tag-based overload and add
guide for arrays as well. Using a tag is better then the fragile types
spelling out.
Also the tag is better then the hypothetical as_array because it is clear
interface (part of the signature). With the as_array the user must know it
exists and must be used in order to get the array version (in other words
to have read the documentaion).


--
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/35200644-4dfe-4af2-9bc4-9f0d63a2a284%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 9, 2018 at 11:14:05 AM UTC+2, =
Adi Shavit wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div><span style=3D"float:none;background-color=
:transparent;color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;fon=
t-size:13px;font-style:normal;font-weight:400;letter-spacing:normal;text-al=
ign:left;text-decoration:none;text-indent:0px;text-transform:none;white-spa=
ce:normal;word-spacing:0px;display:inline">The standard must clear it is fi=
ne and always be fine to use array in non array ptr (as long as you supply =
the deleter)</span>. If the standard does not have such text already. </div=
><div>It might be obvious to you now, but what if someone proposes to inclu=
de this in some &quot;anti-pattern&quot; list as &quot;legacy, before we ha=
d array support&quot;?=C2=A0</div></div></blockquote><div><br></div><div>We=
ll, fwiw, raw C pointers double as array pointers. There is no getting arou=
nd that and I&#39;m not sure if/how C++ is willing to change that.</div><di=
v>This ambiguity/duplicity is inherent in the C[++] type system.</div><div>=
<br></div><div>My proposal, lets you have the reduced non-array interface=
=C2=A0- or first element only access, if you will.</div><div>If you want to=
 <i>opt-in</i> to the <i>array</i> interface, you should explicitly state s=
o - just as you do today in C++.</div><div><br></div><div>Remember, I am no=
t proposing any changes to unique_ptr or any mistakes users may make using =
it.=C2=A0</div></div></div></div></blockquote><div><br></div><div>The diffe=
rence is - ATM it is clearly a mistake - the user typed wrong things on one=
 of the places (the type or the new statement). It is clearly (literally &q=
uot;clearly&quot;) his fault.</div><div><br></div><div>With the proposal th=
e mistake is hidden (again, literally) - the user must <i>know</i> guides a=
re for non-arrays only.=C2=A0</div><div><br></div><div>Let me be clear - <i=
>I am for the proposal to be adopted! </i>If CTAD arrived before arrays sup=
port, unique_ptr would have gotten a guide.</div><div><br></div><div><i>How=
ever</i>, &quot;lets just add a guide now&quot; will not cut it am afraid. =
If that was the case it would have been done.</div><div><br></div><div>Ther=
e two way to make it work. </div><div>One is add a guide, but be very speci=
fic (spelled out) it is for non-array and be clear future standards will no=
t break you or shame you if you use it for an array (with the risks and lim=
itations involved). </div><div>You insist these are implied, but they are n=
ot if not written down.</div><div><br></div><div>Second (from the top of my=
 head) is to add an tag-based overload and add guide for arrays as well. Us=
ing a tag is better then the fragile types spelling out. </div><div>Also th=
e tag is better then the hypothetical as_array because it is clear interfac=
e (part of the signature). With the as_array the user must know it exists a=
nd must be used in order to get the array version (in other words to have r=
ead the documentaion).</div><div><i><br></i></div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">
</blockquote></div>

<p></p>

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

------=_Part_7343_1105300062.1515493518468--

------=_Part_7342_263686170.1515493518468--

.

------=_Part_5154_350747529.1515496903234
Content-Type: multipart/alternative;
 boundary="----=_Part_5155_98709815.1515496903234"

------=_Part_5155_98709815.1515496903234
Content-Type: text/plain; charset="UTF-8"


>
> unique_ptr<T[]> forbids most implicit pointer conversions, which is an
> important safety feature. I don't see that being discussed at all in the
> proposal:
>
> struct B {}; struct D : B {};
>
> unique_ptr<B[]> upb(new B[10]);
> upb.reset(new D[10]); // error
>
> unique_ptr upb2(new B[10], [](B* p) { delete [] p; });  // unique_ptr<B,
> lambda> per proposal
> upb2.reset(new D[10]); // UB on destruction
>

I wasn't aware of this. This means that the non-array interface is not a
reduced API but should be treated as a separate independent API.
TC, thanks for the very important feedback.

The proposal is just a draft and does not have any formal wording yet.

It does say:

"For raw *array pointers*, the user will *still* have to explicitly specify
the template arguments as before if operator[] support is desired."


Are you suggesting the the wording must be made stricter and explicitly
state that this should not be used with array pointers?

(This is my first attempt at a proposal, so I really appreciate your
constructive feedback and example.)


--
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/9f2845b4-e544-482f-beb8-ba6de0a4bc1a%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">unique_ptr&lt;T[]&gt; forbids most implicit pointer conversions, which =
is an important safety feature. I don&#39;t see that being discussed at all=
 in the proposal:<div><br></div><div>struct B {}; struct D : B {};=C2=A0</d=
iv><div><br></div><div>unique_ptr&lt;B[]&gt; upb(new B[10]);</div><div>upb.=
reset(new D[10]); // error</div><div><br></div><div>unique_ptr upb2(new B[1=
0], [](B* p) { delete [] p; });=C2=A0 // unique_ptr&lt;B, lambda&gt; per pr=
oposal</div><div>upb2.reset(new D[10]); // UB on destruction</div></div></b=
lockquote><div><br></div><div>I wasn&#39;t aware of this. This means that t=
he non-array interface is not a reduced API but should be treated as a sepa=
rate independent API.</div><div>TC, thanks for the very important feedback.=
=C2=A0<br></div><div><br></div><div>The proposal is just a draft and does n=
ot have any formal wording yet.</div><div><br></div><div>It does say:</div>=
<div><br></div><blockquote style=3D"margin: 0 0 0 40px; border: none; paddi=
ng: 0px;"><font size=3D"2"><span style=3D"color: rgb(36, 41, 46); font-fami=
ly: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Ari=
al, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, =
&quot;Segoe UI Symbol&quot;;">&quot;For raw=C2=A0</span><em style=3D"box-si=
zing: border-box; color: rgb(36, 41, 46); font-family: -apple-system, Blink=
MacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Ap=
ple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&qu=
ot;;">array pointers</em><span style=3D"color: rgb(36, 41, 46); font-family=
: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial=
, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &q=
uot;Segoe UI Symbol&quot;;">, the user will=C2=A0</span><em style=3D"box-si=
zing: border-box; color: rgb(36, 41, 46); font-family: -apple-system, Blink=
MacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Ap=
ple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&qu=
ot;;">still</em><span style=3D"color: rgb(36, 41, 46); font-family: -apple-=
system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans-se=
rif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe=
 UI Symbol&quot;;">=C2=A0have to explicitly specify the template arguments =
as before if=C2=A0</span><code style=3D"box-sizing: border-box; padding: 0.=
2em 0.4em; background-color: rgba(27, 31, 35, 0.05); border-radius: 3px; co=
lor: rgb(36, 41, 46); font-family: SFMono-Regular, Consolas, &quot;Liberati=
on Mono&quot;, Menlo, Courier, monospace;">operator[]</code><span style=3D"=
color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, &qu=
ot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&qu=
ot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;;">=C2=A0suppor=
t is desired.&quot;</span></font></blockquote><div><br></div><div>Are you s=
uggesting the the wording must be made stricter and explicitly state that t=
his should not be used with array pointers?</div><div><br></div><div>(This =
is my first attempt at a proposal, so I really appreciate your constructive=
 feedback and example.)</div><div>=C2=A0</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/9f2845b4-e544-482f-beb8-ba6de0a4bc1a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9f2845b4-e544-482f-beb8-ba6de0a4bc1a=
%40isocpp.org</a>.<br />

------=_Part_5155_98709815.1515496903234--

------=_Part_5154_350747529.1515496903234--

.

------=_Part_17312_337785912.1515497889877
Content-Type: multipart/alternative;
 boundary="----=_Part_17313_1057309340.1515497889878"

------=_Part_17313_1057309340.1515497889878
Content-Type: text/plain; charset="UTF-8"


>
>
> The difference is - ATM it is clearly a mistake - the user typed wrong
> things on one of the places (the type or the new statement). It is clearly
> (literally "clearly") his fault.
> With the proposal the mistake is hidden (again, literally) - the user must
> *know* guides are for non-arrays only.
>

That's true however I can see several "mitigating" factors:

   1. If the pointer is an array type, it seems reasonable to assume that
   the user would actually like to use operator[] which will be flagged as
   a compilation error if using the wrong declaration.
   2. Since this proposal is limited *only* to the case of custom deleters,
   the user is paying much more attention the the declaration line and is thus
   less likely to misuse the feature.
   3. When used with 3rd party APIs that return some pointer, the user may
   not even always be aware of the array-ness of the pointer.
   In this case, even the example that TC showed might happen with the
   existing unique_ptr implementation.
   Presumably, in this case the user does not really count on any implicit
   type conversions.



> Let me be clear - *I am for the proposal to be adopted! *If CTAD arrived
> before arrays support, unique_ptr would have gotten a guide.
>


*However*, "lets just add a guide now" will not cut it am afraid. If that
> was the case it would have been done.
>

IIUC from discussions on Slack, the committee was short on time and left
[some of] the deduction guide discussions to later (e.g. now).


> There two way to make it work.
> One is add a guide, but be very specific (spelled out) it is for non-array
> and be clear future standards will not break you or shame you if you use it
> for an array (with the risks and limitations involved).
> You insist these are implied, but they are not if not written down.
>

Is what you are suggesting here to make the wording firmer and more
explicit that one should not ever use the guide with array pointers?
(the draft is just a draft and far from any final submission-ready wording.)
Currently I have the description (not standardese wording): "For raw *array
pointers*, the user will *still* have to explicitly specify the template
arguments as before if operator[] support is desired."

be clear future standards will not break you or shame you if you use it for
> an array (with the risks and limitations involved).
>

I'm not sure I understand what you mean here.


> Second (from the top of my head) is to add an tag-based overload and add
> guide for arrays as well. Using a tag is better then the fragile types
> spelling out.
> Also the tag is better then the hypothetical as_array because it is clear
> interface (part of the signature). With the as_array the user must know it
> exists and must be used in order to get the array version (in other words
> to have read the documentaion).
>

I don't understand what you mean by a tag-based overload.
Can you show a short *usage *snippet of what that might look like?



--
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/afbce9d2-15c3-42e8-87e3-850fb68435c1%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br></div><div>The difference is - ATM it is clearly a mistake - t=
he user typed wrong things on one of the places (the type or the new statem=
ent). It is clearly (literally &quot;clearly&quot;) his fault.</div><div>Wi=
th the proposal the mistake is hidden (again, literally) - the user must <i=
>know</i> guides are for non-arrays only.=C2=A0</div></div></blockquote><di=
v><br></div><div>That&#39;s true however I can see several &quot;mitigating=
&quot; factors:</div><div><ol><li>If the pointer is an array type, it seems=
 reasonable to assume that the user would actually like to use=C2=A0<font f=
ace=3D"courier new, monospace">operator[]</font>=C2=A0which will be flagged=
 as a compilation error if using the wrong declaration.</li><li>Since this =
proposal is limited <i>only</i> to the case of custom deleters, the user is=
 paying much more attention the the declaration line and is thus less likel=
y to misuse the feature.<br></li><li>When used with 3rd party APIs that ret=
urn some pointer, the user may not even always be aware of the array-ness o=
f the pointer.<br>In this case, even the example that TC showed might happe=
n with the existing unique_ptr implementation.<br>Presumably, in this case =
the user does not really count on any implicit type conversions.</li></ol><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Let me be clear - <i>I am for the proposal to be adopted! </i=
>If CTAD arrived before arrays support, unique_ptr would have gotten a guid=
e.</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le=
ft: 1ex;">=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><i>However</i>, &quot;lets just add a guide now&quot; =
will not cut it am afraid. If that was the case it would have been done.</d=
iv></div></blockquote><div><br></div><div>IIUC from discussions on Slack, t=
he committee was short on time and left [some of] the deduction guide discu=
ssions to later (e.g. now).</div><div>=C2=A0 =C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>There two way to make it =
work.<br></div><div>One is add a guide, but be very specific (spelled out) =
it is for non-array and be clear future standards will not break you or sha=
me you if you use it for an array (with the risks and limitations involved)=
.. </div><div>You insist these are implied, but they are not if not written =
down.</div></div></blockquote><div><br></div><div>Is what you are suggestin=
g here to make the wording firmer and more explicit that one should not eve=
r use the guide with array pointers?</div><div>(the draft is just a draft a=
nd far from any final submission-ready wording.)</div><div><font size=3D"2"=
>Currently I have the description (not standardese wording): &quot;<span st=
yle=3D"color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFo=
nt, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color E=
moji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;;">For r=
aw=C2=A0</span><em style=3D"box-sizing: border-box; color: rgb(36, 41, 46);=
 font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helv=
etica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emo=
ji&quot;, &quot;Segoe UI Symbol&quot;;">array pointers</em><span style=3D"c=
olor: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, &quo=
t;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quo=
t;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;;">, the user wi=
ll=C2=A0</span><em style=3D"box-sizing: border-box; color: rgb(36, 41, 46);=
 font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helv=
etica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emo=
ji&quot;, &quot;Segoe UI Symbol&quot;;">still</em><span style=3D"color: rgb=
(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe U=
I&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot=
;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;;">=C2=A0have to explicit=
ly specify the template arguments as before if=C2=A0</span><code style=3D"b=
ox-sizing: border-box; font-family: SFMono-Regular, Consolas, &quot;Liberat=
ion Mono&quot;, Menlo, Courier, monospace; padding: 0.2em 0.4em; background=
-color: rgba(27, 31, 35, 0.05); border-radius: 3px; color: rgb(36, 41, 46);=
">operator[]</code><span style=3D"color: rgb(36, 41, 46); font-family: -app=
le-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans=
-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Se=
goe UI Symbol&quot;;">=C2=A0support is desired.</span>&quot;</font></div><d=
iv><font size=3D"2"><br></font></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); =
padding-left: 1ex;">be clear future standards will not break you or shame y=
ou if you use it for an array (with the risks and limitations involved).<fo=
nt size=3D"2"><br></font></blockquote><div><font size=3D"2"><br></font></di=
v><div>I&#39;m not sure I understand what you mean here.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Seco=
nd (from the top of my head) is to add an tag-based overload and add guide =
for arrays as well. Using a tag is better then the fragile types spelling o=
ut.<br></div><div>Also the tag is better then the hypothetical as_array bec=
ause it is clear interface (part of the signature). With the as_array the u=
ser must know it exists and must be used in order to get the array version =
(in other words to have read the documentaion).</div></div></blockquote><di=
v><br></div><div>I don&#39;t understand what you mean by a tag-based overlo=
ad.</div><div>Can you show a short <i>usage </i>snippet of what that might =
look like?</div><div><br></div><div>=C2=A0</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/afbce9d2-15c3-42e8-87e3-850fb68435c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/afbce9d2-15c3-42e8-87e3-850fb68435c1=
%40isocpp.org</a>.<br />

------=_Part_17313_1057309340.1515497889878--

------=_Part_17312_337785912.1515497889877--

.

------=_Part_17807_223085724.1515500629571
Content-Type: multipart/alternative;
 boundary="----=_Part_17808_862713854.1515500629572"

------=_Part_17808_862713854.1515500629572
Content-Type: text/plain; charset="UTF-8"



On Tuesday, January 9, 2018 at 1:38:09 PM UTC+2, Adi Shavit wrote:
>
>
>> The difference is - ATM it is clearly a mistake - the user typed wrong
>> things on one of the places (the type or the new statement). It is clearly
>> (literally "clearly") his fault.
>> With the proposal the mistake is hidden (again, literally) - the user
>> must *know* guides are for non-arrays only.
>>
>
> That's true however I can see several "mitigating" factors:
>
>    1. If the pointer is an array type, it seems reasonable to assume that
>    the user would actually like to use operator[] which will be flagged
>    as a compilation error if using the wrong declaration.
>    2. Since this proposal is limited *only* to the case of custom
>    deleters, the user is paying much more attention the the declaration line
>    and is thus less likely to misuse the feature.
>
> First time user will never knew arrays are not supported or he can simply
forget this. He might upgrade existing non-array CTAD enabled ptr to an
array one again without a though of an issue.


>
>    1.
>    2. When used with 3rd party APIs that return some pointer, the user
>    may not even always be aware of the array-ness of the pointer.
>    In this case, even the example that TC showed might happen with the
>    existing unique_ptr implementation.
>    Presumably, in this case the user does not really count on any
>    implicit type conversions.
>
>
>
>> Let me be clear - *I am for the proposal to be adopted! *If CTAD arrived
>> before arrays support, unique_ptr would have gotten a guide.
>>
>
>
> *However*, "lets just add a guide now" will not cut it am afraid. If that
>> was the case it would have been done.
>>
>
> IIUC from discussions on Slack, the committee was short on time and left
> [some of] the deduction guide discussions to later (e.g. now).
>
>
>> There two way to make it work.
>> One is add a guide, but be very specific (spelled out) it is for
>> non-array and be clear future standards will not break you or shame you if
>> you use it for an array (with the risks and limitations involved).
>> You insist these are implied, but they are not if not written down.
>>
>
> Is what you are suggesting here to make the wording firmer and more
> explicit that one should not ever use the guide with array pointers?
>
(the draft is just a draft and far from any final submission-ready wording.)
> Currently I have the description (not standardese wording): "For raw *array
> pointers*, the user will *still* have to explicitly specify the template
> arguments as before if operator[] support is desired."
>
> be clear future standards will not break you or shame you if you use it
>> for an array (with the risks and limitations involved).
>>
>
> I'm not sure I understand what you mean here.
>

Either way - forbid or allow - it must be written out what is expected
behavior. That is not an easy answer (to allow or not). If it is disallowed
the standard "ensures" the programmer writes more correct code and is
easier to keep unique_ptr  to arrays and objects separate semantically and
otherwise. If it allows it, it will be more close to C/C++ view on the
matter and, to some extend, closer to the programmer expectations - the
alloc and dealloc is all it matters, the downside is - the standard must
assume some unique_ptrs are arrays and carry that dependency forward. Right
now there is such a assumption as the array support came later and surely
there is old code, not updated to the array version, however with this
proposal + not forbidding arrays, then it is not just old code, but new one
as well. It will be official from now on and must be respected in the
future.


>
>
>> Second (from the top of my head) is to add an tag-based overload and add
>> guide for arrays as well. Using a tag is better then the fragile types
>> spelling out.
>> Also the tag is better then the hypothetical as_array because it is clear
>> interface (part of the signature). With the as_array the user must know it
>> exists and must be used in order to get the array version (in other words
>> to have read the documentaion).
>>
>
> I don't understand what you mean by a tag-based overload.
> Can you show a short *usage *snippet of what that might look like?
>
>
namespace std {
inline constexpr struct construct_from_array_t {} construct_from_array;
}

// usage

std::unique_ptr up(std::construct_from_array, new B[10], [](B* p) { delete
[] p; } );
up.reset(new D[10]); *//< fails to compile, no member reset()*
*up[5] = B{2};*


And BTW, the shared_ptr has the same limitations - it does not have
deduction guide for raw pointers. Why not fix that as well?

--
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/51e5a471-cdc6-4a2a-b2c6-ea965e98a3bc%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 9, 2018 at 1:38:09 PM UTC+2, A=
di Shavit wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div>=
<div>The difference is - ATM it is clearly a mistake - the user typed wrong=
 things on one of the places (the type or the new statement). It is clearly=
 (literally &quot;clearly&quot;) his fault.</div><div>With the proposal the=
 mistake is hidden (again, literally) - the user must <i>know</i> guides ar=
e for non-arrays only.=C2=A0</div></div></blockquote><div><br></div><div>Th=
at&#39;s true however I can see several &quot;mitigating&quot; factors:</di=
v><div><ol><li>If the pointer is an array type, it seems reasonable to assu=
me that the user would actually like to use=C2=A0<font face=3D"courier new,=
 monospace">operator[]</font>=C2=A0which will be flagged as a compilation e=
rror if using the wrong declaration.</li><li>Since this proposal is limited=
 <i>only</i> to the case of custom deleters, the user is paying much more a=
ttention the the declaration line and is thus less likely to misuse the fea=
ture.<br></li></ol></div></div></blockquote><div>First time user will never=
 knew arrays are not supported or he can simply forget this. He might upgra=
de existing non-array CTAD enabled ptr to an array one again without a thou=
gh of an issue.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><ol><li></li><li>When used with 3rd party API=
s that return some pointer, the user may not even always be aware of the ar=
ray-ness of the pointer.<br>In this case, even the example that TC showed m=
ight happen with the existing unique_ptr implementation.<br>Presumably, in =
this case the user does not really count on any implicit type conversions.<=
/li></ol></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>Let me be clear - <i>I am for the proposal to be adopted=
! </i>If CTAD arrived before arrays support, unique_ptr would have gotten a=
 guide.</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><i>However</i>, &quot;lets just add a guide now&quot; will no=
t cut it am afraid. If that was the case it would have been done.</div></di=
v></blockquote><div><br></div><div>IIUC from discussions on Slack, the comm=
ittee was short on time and left [some of] the deduction guide discussions =
to later (e.g. now).</div><div>=C2=A0 =C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>There two way to make it work.<br></di=
v><div>One is add a guide, but be very specific (spelled out) it is for non=
-array and be clear future standards will not break you or shame you if you=
 use it for an array (with the risks and limitations involved). </div><div>=
You insist these are implied, but they are not if not written down.</div></=
div></blockquote><div><br></div><div>Is what you are suggesting here to mak=
e the wording firmer and more explicit that one should not ever use the gui=
de with array pointers?=C2=A0</div></div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>(the draft is just a draft an=
d far from any final submission-ready wording.)</div><div><font size=3D"2">=
Currently I have the description (not standardese wording): &quot;<span sty=
le=3D"color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&quo=
t;Segoe UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&=
quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;">For raw=C2=A0</span>=
<em style=3D"color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFo=
nt,&quot;Segoe UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&=
quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;">array pointer=
s</em><span style=3D"color:rgb(36,41,46);font-family:-apple-system,BlinkMac=
SystemFont,&quot;Segoe UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Colo=
r Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;">, the=
 user will=C2=A0</span><em style=3D"color:rgb(36,41,46);font-family:-apple-=
system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Helvetica,Arial,sans-serif,&=
quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symb=
ol&quot;">still</em><span style=3D"color:rgb(36,41,46);font-family:-apple-s=
ystem,BlinkMacSystemFont,&quot;Segoe UI&quot;,Helvetica,Arial,sans-serif,&q=
uot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbo=
l&quot;">=C2=A0have to explicitly specify the template arguments as before =
if=C2=A0</span><code style=3D"font-family:SFMono-Regular,Consolas,&quot;Lib=
eration Mono&quot;,Menlo,Courier,monospace;padding:0.2em 0.4em;background-c=
olor:rgba(27,31,35,0.05);border-radius:3px;color:rgb(36,41,46)">operator[]<=
/code><span style=3D"color:rgb(36,41,46);font-family:-apple-system,BlinkMac=
SystemFont,&quot;Segoe UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Colo=
r Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;">=C2=
=A0support is desired.</span>&quot;</font></div><div><font size=3D"2"><br><=
/font></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">be clear futu=
re standards will not break you or shame you if you use it for an array (wi=
th the risks and limitations involved).<font size=3D"2"><br></font></blockq=
uote><div><font size=3D"2"><br></font></div><div>I&#39;m not sure I underst=
and what you mean here.</div></div></blockquote><div><br></div><div>Either =
way - forbid or allow - it must be written out what is expected behavior. T=
hat is not an easy answer (to allow or not). If it is disallowed the standa=
rd &quot;ensures&quot; the programmer writes more correct code and is easie=
r to keep unique_ptr=C2=A0 to arrays and objects separate semantically and =
otherwise. If it allows it, it will be more close to C/C++ view on the matt=
er and, to some extend, closer to the programmer expectations - the alloc a=
nd dealloc is all it matters, the downside is - the standard must assume so=
me unique_ptrs are arrays and carry that dependency forward. Right now ther=
e is such a assumption as the array support came later and surely there is =
old code, not updated to the array version, however with this proposal + no=
t forbidding arrays, then it is not just old code, but new one as well. It =
will be official from now on and must be respected in the future.=C2=A0</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div>Second (from the top of my head) is to add an tag-based overload =
and add guide for arrays as well. Using a tag is better then the fragile ty=
pes spelling out.<br></div><div>Also the tag is better then the hypothetica=
l as_array because it is clear interface (part of the signature). With the =
as_array the user must know it exists and must be used in order to get the =
array version (in other words to have read the documentaion).</div></div></=
blockquote><div><br></div><div>I don&#39;t understand what you mean by a ta=
g-based overload.</div><div>Can you show a short <i>usage </i>snippet of wh=
at that might look like?</div><div><br></div></div></blockquote><div><font =
face=3D"courier new,monospace"><br></font></div><div><font face=3D"courier =
new,monospace">namespace std {</font></div><div><font face=3D"courier new,m=
onospace">inline constexpr struct=C2=A0<span style=3D"text-align: left; col=
or: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing=
: normal; font-size: 13px; font-style: normal; font-variant: normal; font-w=
eight: 400; text-decoration: none; word-spacing: 0px; display: inline !impo=
rtant; white-space: normal; orphans: 2; float: none; -webkit-text-stroke-wi=
dth: 0px; background-color: transparent;">construct_from_array_t {}=C2=A0<s=
pan style=3D"text-align: left; color: rgb(34, 34, 34); text-transform: none=
; text-indent: 0px; letter-spacing: normal; font-size: 13px; font-style: no=
rmal; font-variant: normal; font-weight: 400; text-decoration: none; word-s=
pacing: 0px; display: inline !important; white-space: normal; orphans: 2; f=
loat: none; -webkit-text-stroke-width: 0px; background-color: transparent;"=
>construct_from_array;</span></span></font></div><div><span style=3D"text-a=
lign: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px;=
 letter-spacing: normal; font-size: 13px; font-style: normal; font-variant:=
 normal; font-weight: 400; text-decoration: none; word-spacing: 0px; displa=
y: inline !important; white-space: normal; orphans: 2; float: none; -webkit=
-text-stroke-width: 0px; background-color: transparent;"><span style=3D"tex=
t-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0=
px; letter-spacing: normal; font-size: 13px; font-style: normal; font-varia=
nt: normal; font-weight: 400; text-decoration: none; word-spacing: 0px; dis=
play: inline !important; white-space: normal; orphans: 2; float: none; -web=
kit-text-stroke-width: 0px; background-color: transparent;"><font face=3D"c=
ourier new,monospace">}</font></span></span></div><div><b></b><i></i><u></u=
><sub></sub><sup></sup><strike></strike><b></b><i></i><u></u><sub></sub><su=
p></sup><strike></strike><font face=3D"courier new,monospace"></font><font =
face=3D"courier new,monospace"><br></font></div><div><font face=3D"courier =
new,monospace">// usage</font></div><div><font face=3D"courier new,monospac=
e"></font><br></div><div><font face=3D"courier new,monospace">std::unique_p=
tr up(std::construct_from_array,=C2=A0</font><font face=3D"courier new,mono=
space">new B[10], [](B* p) { delete [] p; } ); </font></div><div><font face=
=3D"courier new,monospace">up.reset(new D[10]); <i>//&lt; fails to compile,=
 no member reset()</i></font></div><div><i><font face=3D"courier new,monosp=
ace">up[5] =3D B{2};</font></i></div><div><i><font face=3D"courier new"><br=
></font></i></div><div><i><font face=3D"courier new"><br></font></i></div><=
div><font face=3D"arial,sans-serif">And BTW, the shared_ptr has the same li=
mitations - it does not have deduction guide for raw pointers. Why not fix =
that as well?</font></div><div><i><font face=3D"arial,sans-serif"><br></fon=
t></i></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/51e5a471-cdc6-4a2a-b2c6-ea965e98a3bc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/51e5a471-cdc6-4a2a-b2c6-ea965e98a3bc=
%40isocpp.org</a>.<br />

------=_Part_17808_862713854.1515500629572--

------=_Part_17807_223085724.1515500629571--

.

------=_Part_17914_1865688142.1515504638166
Content-Type: multipart/alternative;
 boundary="----=_Part_17915_1073903035.1515504638167"

------=_Part_17915_1073903035.1515504638167
Content-Type: text/plain; charset="UTF-8"


>
> First time user will never knew arrays are not supported or he can simply
> forget this. He might upgrade existing non-array CTAD enabled ptr to an
> array one again without a though of an issue.
>

As I said - I think there are mitigating factors. It's difficult to make
progress and still protect all newbies.


> Either way - forbid or allow - it must be written out what is expected
> behavior. That is not an easy answer (to allow or not). If it is disallowed
> the standard "ensures" the programmer writes more correct code and is
> easier to keep unique_ptr  to arrays and objects separate semantically and
> otherwise. If it allows it, it will be more close to C/C++ view on the
> matter and, to some extend, closer to the programmer expectations - the
> alloc and dealloc is all it matters, the downside is - the standard must
> assume some unique_ptrs are arrays and carry that dependency forward. Right
> now there is such a assumption as the array support came later and surely
> there is old code, not updated to the array version, however with this
> proposal + not forbidding arrays, then it is not just old code, but new one
> as well. It will be official from now on and must be respected in the
> future.
>

Good points. I would like to wait for more input and suggestions on this
matter from others here.

namespace std {
> inline constexpr struct construct_from_array_t {} construct_from_array;
> }
>
> // usage
>
> std::unique_ptr up(std::construct_from_array, new B[10], [](B* p) {
> delete [] p; } );
> up.reset(new D[10]); *//< fails to compile, no member reset()*
> *up[5] = B{2};*
>
>
Ah, yes.
I think I asked about this earlier:


As for the as_array, I believe a simple tag can solve this.
>
> Only at the deduction guide level without adding new unique_ptr ctor?


This can only be done by adding a new ctor to unique_ptr. Something that I
had hoped to avoid.

This gives me an interesting idea (for another thread I guess) - make it
possible to declare guides as "friend"s, so that they can call a private
ctor with e.g. a tag or a hint.... hmm..


And BTW, the shared_ptr has the same limitations - it does not have
> deduction guide for raw pointers. Why not fix that as well?
>

Well, custom deleters are not part of the shared_ptr type, so they can be
directly passed to the ctor.
Most often specifying the pointer type is not the problem - it is the
deleter type that is difficult and repetitive to declare.

--
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/6d95fd79-1056-4bd9-99be-c76b9b485c2a%40isocpp.org.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div dir=3D"ltr"><div>First time user will never knew arrays are not su=
pported or he can simply forget this. He might upgrade existing non-array C=
TAD enabled ptr to an array one again without a though of an issue.<br></di=
v></div></div></blockquote><div><br></div><div>As I said - I think there ar=
e mitigating factors. It&#39;s difficult to make progress and still protect=
 all newbies.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>Either way - forbid or allow - it must be writt=
en out what is expected behavior. That is not an easy answer (to allow or n=
ot). If it is disallowed the standard &quot;ensures&quot; the programmer wr=
ites more correct code and is easier to keep unique_ptr=C2=A0 to arrays and=
 objects separate semantically and otherwise. If it allows it, it will be m=
ore close to C/C++ view on the matter and, to some extend, closer to the pr=
ogrammer expectations - the alloc and dealloc is all it matters, the downsi=
de is - the standard must assume some unique_ptrs are arrays and carry that=
 dependency forward. Right now there is such a assumption as the array supp=
ort came later and surely there is old code, not updated to the array versi=
on, however with this proposal + not forbidding arrays, then it is not just=
 old code, but new one as well. It will be official from now on and must be=
 respected in the future.=C2=A0</div></div></blockquote><div><br></div><div=
>Good points. I would like to wait for more input and suggestions on this m=
atter from others here.</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><span style=3D"font-family: &quot;couri=
er new&quot;, monospace;">namespace std {</span><br></div><div><font face=
=3D"courier new,monospace">inline constexpr struct=C2=A0<span style=3D"text=
-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-=
spacing:normal;font-size:13px;font-style:normal;font-variant:normal;font-we=
ight:400;text-decoration:none;word-spacing:0px;display:inline!important;whi=
te-space:normal;float:none;background-color:transparent">construct_from_arr=
ay_t {}=C2=A0<span style=3D"text-align:left;color:rgb(34,34,34);text-transf=
orm:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:no=
rmal;font-variant:normal;font-weight:400;text-decoration:none;word-spacing:=
0px;display:inline!important;white-space:normal;float:none;background-color=
:transparent">construct_from_array;</span></span></font></div><div><span st=
yle=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:=
0px;letter-spacing:normal;font-size:13px;font-style:normal;font-variant:nor=
mal;font-weight:400;text-decoration:none;word-spacing:0px;display:inline!im=
portant;white-space:normal;float:none;background-color:transparent"><span s=
tyle=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent=
:0px;letter-spacing:normal;font-size:13px;font-style:normal;font-variant:no=
rmal;font-weight:400;text-decoration:none;word-spacing:0px;display:inline!i=
mportant;white-space:normal;float:none;background-color:transparent"><font =
face=3D"courier new,monospace">}</font></span></span></div><div><b></b><i><=
/i><u></u><sub></sub><sup></sup><strike></strike><b></b><i></i><u></u><sub>=
</sub><sup></sup><strike></strike><font face=3D"courier new,monospace"></fo=
nt><font face=3D"courier new,monospace"><br></font></div><div><font face=3D=
"courier new,monospace">// usage</font></div><div><font face=3D"courier new=
,monospace"></font><br></div><div><font face=3D"courier new,monospace">std:=
:unique_ptr up(std::construct_from_array,=C2=A0</font><font face=3D"courier=
 new,monospace"><wbr>new B[10], [](B* p) { delete [] p; } ); </font></div><=
div><font face=3D"courier new,monospace">up.reset(new D[10]); <i>//&lt; fai=
ls to compile, no member reset()</i></font></div><div><i><font face=3D"cour=
ier new,monospace">up[5] =3D B{2};</font></i></div><div><i><font face=3D"co=
urier new"><br></font></i></div></div></blockquote><div><br></div><div>Ah, =
yes.=C2=A0=C2=A0</div><div>I think I asked about this earlier:</div><div><b=
lockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div><b=
r></div><div><div class=3D"F0XO1GC-Db-b"><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left:=
 1ex;">As for the as_array, I believe a simple tag can solve this.</blockqu=
ote></blockquote></div></div><div><div class=3D"F0XO1GC-Db-b"><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;">Only at the deduction guide le=
vel without adding new unique_ptr ctor?</blockquote></div></div></blockquot=
e></div><div><div class=3D"F0XO1GC-Db-b"><div><br></div><div><font color=3D=
"#222222">This can only be done by adding a new ctor to unique_ptr. Somethi=
ng that I had hoped to avoid.</font></div><div><font color=3D"#222222"><br>=
</font></div><div><font color=3D"#222222">This gives me an interesting idea=
 (for another thread I guess) - make it possible to declare guides as &quot=
;friend&quot;s, so that they can call a private ctor with e.g. a tag or a h=
int.... hmm..</font></div><div><br></div></div></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><i><font face=
=3D"courier new"></font></i></div><div><span style=3D"font-family: arial, s=
ans-serif;">And BTW, the shared_ptr has the same limitations - it does not =
have deduction guide for raw pointers. Why not fix that as well?</span></di=
v></div></blockquote><div><br></div><div>Well, custom deleters are not part=
 of the shared_ptr type, so they can be directly passed to the ctor.</div><=
div>Most often specifying the pointer type is not the problem - it is the d=
eleter type that is difficult and repetitive to declare.</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/6d95fd79-1056-4bd9-99be-c76b9b485c2a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6d95fd79-1056-4bd9-99be-c76b9b485c2a=
%40isocpp.org</a>.<br />

------=_Part_17915_1073903035.1515504638167--

------=_Part_17914_1865688142.1515504638166--

.

------=_Part_5074_2145203884.1515506615183
Content-Type: multipart/alternative;
 boundary="----=_Part_5075_1010681233.1515506615183"

------=_Part_5075_1010681233.1515506615183
Content-Type: text/plain; charset="UTF-8"



On Tuesday, January 9, 2018 at 3:30:38 PM UTC+2, Adi Shavit wrote:
>
> First time user will never knew arrays are not supported or he can simply
>> forget this. He might upgrade existing non-array CTAD enabled ptr to an
>> array one again without a though of an issue.
>>
>
> As I said - I think there are mitigating factors. It's difficult to make
> progress and still protect all newbies.
>
>
>> Either way - forbid or allow - it must be written out what is expected
>> behavior. That is not an easy answer (to allow or not). If it is disallowed
>> the standard "ensures" the programmer writes more correct code and is
>> easier to keep unique_ptr  to arrays and objects separate semantically and
>> otherwise. If it allows it, it will be more close to C/C++ view on the
>> matter and, to some extend, closer to the programmer expectations - the
>> alloc and dealloc is all it matters, the downside is - the standard must
>> assume some unique_ptrs are arrays and carry that dependency forward. Right
>> now there is such a assumption as the array support came later and surely
>> there is old code, not updated to the array version, however with this
>> proposal + not forbidding arrays, then it is not just old code, but new one
>> as well. It will be official from now on and must be respected in the
>> future.
>>
>
> Good points. I would like to wait for more input and suggestions on this
> matter from others here.
>
> namespace std {
>> inline constexpr struct construct_from_array_t {} construct_from_array;
>> }
>>
>> // usage
>>
>> std::unique_ptr up(std::construct_from_array, new B[10], [](B* p) {
>> delete [] p; } );
>> up.reset(new D[10]); *//< fails to compile, no member reset()*
>> *up[5] = B{2};*
>>
>>
> Ah, yes.
> I think I asked about this earlier:
>
>
> As for the as_array, I believe a simple tag can solve this.
>>
>> Only at the deduction guide level without adding new unique_ptr ctor?
>
>
> This can only be done by adding a new ctor to unique_ptr. Something that I
> had hoped to avoid.
>
> This gives me an interesting idea (for another thread I guess) - make it
> possible to declare guides as "friend"s, so that they can call a private
> ctor with e.g. a tag or a hint.... hmm..
>

It is the user that must pass the tag, you can't hide this away. It is the
user that must spell out (one way or another), it is an array he is passing
in - no trick can be done around that.

The tag has other benefits outside CTAD as well

// c.h

struct C
{
  unique_ptr<int[]> a;
};

// c.cpp

C::C() : a{new int[12]} *//< first deprecated, later fails to
compile: construct_from_array must be used *
{}

This way intended ptr type is side by side with actual data creation (not
in separate places - declaration and construction) AND the compiler can
also check for mismatches


>
> And BTW, the shared_ptr has the same limitations - it does not have
>> deduction guide for raw pointers. Why not fix that as well?
>>
>
> Well, custom deleters are not part of the shared_ptr type, so they can be
> directly passed to the ctor.
> Most often specifying the pointer type is not the problem - it is the
> deleter type that is difficult and repetitive to declare.
>

This will create asymmetry in the API, though, people will be surprised,
especially considering there is no logic behind the inclusion of one and
the lack of the other.
At least now the same logic is applies to both.

--
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/f2b8837e-e517-4441-b224-172c3f1e50c6%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 9, 2018 at 3:30:38 PM UTC+2, A=
di Shavit wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr=
"><div>First time user will never knew arrays are not supported or he can s=
imply forget this. He might upgrade existing non-array CTAD enabled ptr to =
an array one again without a though of an issue.<br></div></div></div></blo=
ckquote><div><br></div><div>As I said - I think there are mitigating factor=
s. It&#39;s difficult to make progress and still protect all newbies.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div>Either way - forbid or allow - it must be written out what is expected =
behavior. That is not an easy answer (to allow or not). If it is disallowed=
 the standard &quot;ensures&quot; the programmer writes more correct code a=
nd is easier to keep unique_ptr=C2=A0 to arrays and objects separate semant=
ically and otherwise. If it allows it, it will be more close to C/C++ view =
on the matter and, to some extend, closer to the programmer expectations - =
the alloc and dealloc is all it matters, the downside is - the standard mus=
t assume some unique_ptrs are arrays and carry that dependency forward. Rig=
ht now there is such a assumption as the array support came later and surel=
y there is old code, not updated to the array version, however with this pr=
oposal + not forbidding arrays, then it is not just old code, but new one a=
s well. It will be official from now on and must be respected in the future=
..=C2=A0</div></div></blockquote><div><br></div><div>Good points. I would li=
ke to wait for more input and suggestions on this matter from others here.<=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><span style=3D"font-family:&quot;courier new&quot;,monospace">namesp=
ace std {</span><br></div><div><font face=3D"courier new,monospace">inline =
constexpr struct=C2=A0<span style=3D"text-align:left;color:rgb(34,34,34);te=
xt-transform:none;text-indent:0px;letter-spacing:normal;font-size:13px;font=
-style:normal;font-variant:normal;font-weight:400;text-decoration:none;word=
-spacing:0px;display:inline!important;white-space:normal;float:none;backgro=
und-color:transparent">construct_from_array_t {}=C2=A0<span style=3D"text-a=
lign:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-sp=
acing:normal;font-size:13px;font-style:normal;font-variant:normal;font-weig=
ht:400;text-decoration:none;word-spacing:0px;display:inline!important;white=
-space:normal;float:none;background-color:transparent">construct_from_array=
;</span></span></font></div><div><span style=3D"text-align:left;color:rgb(3=
4,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-siz=
e:13px;font-style:normal;font-variant:normal;font-weight:400;text-decoratio=
n:none;word-spacing:0px;display:inline!important;white-space:normal;float:n=
one;background-color:transparent"><span style=3D"text-align:left;color:rgb(=
34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-si=
ze:13px;font-style:normal;font-variant:normal;font-weight:400;text-decorati=
on:none;word-spacing:0px;display:inline!important;white-space:normal;float:=
none;background-color:transparent"><font face=3D"courier new,monospace">}</=
font></span></span></div><div><b></b><i></i><u></u><sub></sub><sup></sup><s=
trike></strike><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike>=
<font face=3D"courier new,monospace"></font><font face=3D"courier new,monos=
pace"><br></font></div><div><font face=3D"courier new,monospace">// usage</=
font></div><div><font face=3D"courier new,monospace"></font><br></div><div>=
<font face=3D"courier new,monospace">std::unique_ptr up(std::construct_from=
_array,=C2=A0</font><font face=3D"courier new,monospace"><wbr>new B[10], []=
(B* p) { delete [] p; } ); </font></div><div><font face=3D"courier new,mono=
space">up.reset(new D[10]); <i>//&lt; fails to compile, no member reset()</=
i></font></div><div><i><font face=3D"courier new,monospace">up[5] =3D B{2};=
</font></i></div><div><i><font face=3D"courier new"><br></font></i></div></=
div></blockquote><div><br></div><div>Ah, yes.=C2=A0=C2=A0</div><div>I think=
 I asked about this earlier:</div><div><blockquote style=3D"margin:0 0 0 40=
px;border:none;padding:0px"><div><br></div><div><div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">As for the as_array, I believe a simple tag can solve this.</blockquote>=
</blockquote></div></div><div><div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Only at the deduction guide level without adding new unique_ptr =
ctor?</blockquote></div></div></blockquote></div><div><div><div><br></div><=
div><font color=3D"#222222">This can only be done by adding a new ctor to u=
nique_ptr. Something that I had hoped to avoid.</font></div><div><font colo=
r=3D"#222222"><br></font></div><div><font color=3D"#222222">This gives me a=
n interesting idea (for another thread I guess) - make it possible to decla=
re guides as &quot;friend&quot;s, so that they can call a private ctor with=
 e.g. a tag or a hint.... hmm..</font></div></div></div></div></blockquote>=
<div><br></div><div>It is the user that must pass the tag, you can&#39;t hi=
de this away. It is the user that must spell out<span style=3D"display: inl=
ine !important; float: none; background-color: transparent; color: rgb(34, =
34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; f=
ont-size: 13px; font-style: normal; font-variant: normal; font-weight: 400;=
 letter-spacing: normal; orphans: 2; text-align: left; text-decoration: non=
e; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; =
white-space: normal; word-spacing: 0px;"> (one way or another)</span>, it i=
s an array he is passing in - no trick can be done around that.=C2=A0</div>=
<div><br></div><div>The tag has other benefits outside CTAD as well</div><d=
iv><br></div><div>// c.h</div><div><br></div><div><font face=3D"courier new=
,monospace">struct C</font></div><div><font face=3D"courier new,monospace">=
{</font></div><div><font face=3D"courier new,monospace">=C2=A0 unique_ptr&l=
t;int[]&gt; a;</font></div><div><font face=3D"courier new,monospace">};</fo=
nt></div><div><font face=3D"courier new,monospace"><br></font></div><div><f=
ont face=3D"courier new,monospace">// c.cpp</font></div><div><font face=3D"=
courier new,monospace"><br></font></div><div><font face=3D"courier new,mono=
space">C::C() : a{new int[12]} <i>//&lt; first deprecated, later fails to c=
ompile:=C2=A0<span style=3D"text-align: left; color: rgb(34, 34, 34); text-=
transform: none; text-indent: 0px; letter-spacing: normal; font-size: 13px;=
 font-variant: normal; font-weight: 400; text-decoration: none; word-spacin=
g: 0px; display: inline !important; white-space: normal; orphans: 2; float:=
 none; -webkit-text-stroke-width: 0px; background-color: transparent;">cons=
truct_from_array must be used=C2=A0</span></i></font></div><div><font face=
=3D"courier new,monospace">{}</font></div><div><font face=3D"courier new"><=
br></font></div><div><font face=3D"arial,sans-serif">This way intended ptr =
type is side by side with actual data creation (not in separate places - de=
claration and construction) </font><font face=3D"arial,sans-serif">AND the =
compiler can also check for mismatches=C2=A0</font></div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div><=
br></div></div></div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><i><font face=3D"courier new"></font></i></div><div>=
<span style=3D"font-family:arial,sans-serif">And BTW, the shared_ptr has th=
e same limitations - it does not have deduction guide for raw pointers. Why=
 not fix that as well?</span></div></div></blockquote><div><br></div><div>W=
ell, custom deleters are not part of the shared_ptr type, so they can be di=
rectly passed to the ctor.</div><div>Most often specifying the pointer type=
 is not the problem - it is the deleter type that is difficult and repetiti=
ve to declare.</div></div></blockquote><div><br></div><div>This will create=
 asymmetry in the API, though, people will be surprised, especially conside=
ring there is no logic behind the inclusion of one and the lack of the othe=
r. </div><div>At least now the same logic is applies to both.=C2=A0</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/f2b8837e-e517-4441-b224-172c3f1e50c6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f2b8837e-e517-4441-b224-172c3f1e50c6=
%40isocpp.org</a>.<br />

------=_Part_5075_1010681233.1515506615183--

------=_Part_5074_2145203884.1515506615183--

.

------=_Part_18505_1791819031.1515509618462
Content-Type: multipart/alternative;
 boundary="----=_Part_18506_760370998.1515509618463"

------=_Part_18506_760370998.1515509618463
Content-Type: text/plain; charset="UTF-8"

On Tuesday, January 9, 2018 at 7:23:49 AM UTC-5, mihailn...@gmail.com wrote:
>
> On Tuesday, January 9, 2018 at 1:38:09 PM UTC+2, Adi Shavit wrote:
>>
>>
>>> The difference is - ATM it is clearly a mistake - the user typed wrong
>>> things on one of the places (the type or the new statement). It is clearly
>>> (literally "clearly") his fault.
>>> With the proposal the mistake is hidden (again, literally) - the user
>>> must *know* guides are for non-arrays only.
>>>
>>
>> That's true however I can see several "mitigating" factors:
>>
>>    1. If the pointer is an array type, it seems reasonable to assume
>>    that the user would actually like to use operator[] which will be
>>    flagged as a compilation error if using the wrong declaration.
>>    2. Since this proposal is limited *only* to the case of custom
>>    deleters, the user is paying much more attention the the declaration line
>>    and is thus less likely to misuse the feature.
>>
>> First time user will never knew arrays are not supported or he can simply
> forget this. He might upgrade existing non-array CTAD enabled ptr to an
> array one again without a though of an issue.
>
>
>>
>>    1.
>>    2. When used with 3rd party APIs that return some pointer, the user
>>    may not even always be aware of the array-ness of the pointer.
>>    In this case, even the example that TC showed might happen with the
>>    existing unique_ptr implementation.
>>    Presumably, in this case the user does not really count on any
>>    implicit type conversions.
>>
>>
>>
>>> Let me be clear - *I am for the proposal to be adopted! *If CTAD
>>> arrived before arrays support, unique_ptr would have gotten a guide.
>>>
>>
>>
>> *However*, "lets just add a guide now" will not cut it am afraid. If
>>> that was the case it would have been done.
>>>
>>
>> IIUC from discussions on Slack, the committee was short on time and left
>> [some of] the deduction guide discussions to later (e.g. now).
>>
>>
>>> There two way to make it work.
>>> One is add a guide, but be very specific (spelled out) it is for
>>> non-array and be clear future standards will not break you or shame you if
>>> you use it for an array (with the risks and limitations involved).
>>> You insist these are implied, but they are not if not written down.
>>>
>>
>> Is what you are suggesting here to make the wording firmer and more
>> explicit that one should not ever use the guide with array pointers?
>>
> (the draft is just a draft and far from any final submission-ready
>> wording.)
>> Currently I have the description (not standardese wording): "For raw *array
>> pointers*, the user will *still* have to explicitly specify the template
>> arguments as before if operator[] support is desired."
>>
>> be clear future standards will not break you or shame you if you use it
>>> for an array (with the risks and limitations involved).
>>>
>>
>> I'm not sure I understand what you mean here.
>>
>
> Either way - forbid or allow - it must be written out what is expected
> behavior. That is not an easy answer (to allow or not). If it is disallowed
> the standard "ensures" the programmer writes more correct code and is
> easier to keep unique_ptr  to arrays and objects separate semantically and
> otherwise. If it allows it, it will be more close to C/C++ view on the
> matter and, to some extend, closer to the programmer expectations - the
> alloc and dealloc is all it matters, the downside is - the standard must
> assume some unique_ptrs are arrays and carry that dependency forward. Right
> now there is such a assumption as the array support came later and surely
> there is old code, not updated to the array version, however with this
> proposal + not forbidding arrays, then it is not just old code, but new one
> as well. It will be official from now on and must be respected in the
> future.
>
>
>>
>>
>>> Second (from the top of my head) is to add an tag-based overload and add
>>> guide for arrays as well. Using a tag is better then the fragile types
>>> spelling out.
>>> Also the tag is better then the hypothetical as_array because it is
>>> clear interface (part of the signature). With the as_array the user must
>>> know it exists and must be used in order to get the array version (in other
>>> words to have read the documentaion).
>>>
>>
>> I don't understand what you mean by a tag-based overload.
>> Can you show a short *usage *snippet of what that might look like?
>>
>>
> namespace std {
> inline constexpr struct construct_from_array_t {} construct_from_array;
> }
>
> // usage
>
> std::unique_ptr up(std::construct_from_array, new B[10], [](B* p) {
> delete [] p; } );
> up.reset(new D[10]); *//< fails to compile, no member reset()*
> *up[5] = B{2};*
>
>
> And BTW, the shared_ptr has the same limitations - it does not have
> deduction guide for raw pointers. Why not fix that as well?
>

On the question of how such a tag should look, that is way too verbose. It
also requires a deprecation cycle. There's a better way. Observe:

template<typename T>
class from_array_t
{
  T *ptr_;

public:
  from_array_t(T *ptr) : ptr_(ptr) {}

  operator T*() const {return ptr;}
};

template<typename T>
from_array_t from_array(T *ptr) {return from_array_t<T>(ptr);}

template<typename T>
unique_ptr(from_array_t<T>) -> unique_ptr<T[]>;

This allows us to not have to change anything about `unique_ptr` itself (no
new constructors, no new specialization, and no deprecation of the
pointer-based constructors). It's not nearly as verbose as the other
version.

--
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/3ff53b5b-a315-4bfb-81fb-1f846c257732%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, January 9, 2018 at 7:23:49 AM UTC-5, mihailn..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Tuesday, January 9, 2018 at 1:38:09 PM UTC+2, Adi Shavit wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>The difference is - =
ATM it is clearly a mistake - the user typed wrong things on one of the pla=
ces (the type or the new statement). It is clearly (literally &quot;clearly=
&quot;) his fault.</div><div>With the proposal the mistake is hidden (again=
, literally) - the user must <i>know</i> guides are for non-arrays only.=C2=
=A0</div></div></blockquote><div><br></div><div>That&#39;s true however I c=
an see several &quot;mitigating&quot; factors:</div><div><ol><li>If the poi=
nter is an array type, it seems reasonable to assume that the user would ac=
tually like to use=C2=A0<font face=3D"courier new, monospace">operator[]</f=
ont>=C2=A0which will be flagged as a compilation error if using the wrong d=
eclaration.</li><li>Since this proposal is limited <i>only</i> to the case =
of custom deleters, the user is paying much more attention the the declarat=
ion line and is thus less likely to misuse the feature.<br></li></ol></div>=
</div></blockquote><div>First time user will never knew arrays are not supp=
orted or he can simply forget this. He might upgrade existing non-array CTA=
D enabled ptr to an array one again without a though of an issue.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<ol><li></li><li>When used with 3rd party APIs that return some pointer, th=
e user may not even always be aware of the array-ness of the pointer.<br>In=
 this case, even the example that TC showed might happen with the existing =
unique_ptr implementation.<br>Presumably, in this case the user does not re=
ally count on any implicit type conversions.</li></ol></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Let me be c=
lear - <i>I am for the proposal to be adopted! </i>If CTAD arrived before a=
rrays support, unique_ptr would have gotten a guide.</div></div></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0</blockquote><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><i>However</i>, &=
quot;lets just add a guide now&quot; will not cut it am afraid. If that was=
 the case it would have been done.</div></div></blockquote><div><br></div><=
div>IIUC from discussions on Slack, the committee was short on time and lef=
t [some of] the deduction guide discussions to later (e.g. now).</div><div>=
=C2=A0 =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>There two way to make it work.<br></div><div>One is add a guide, but =
be very specific (spelled out) it is for non-array and be clear future stan=
dards will not break you or shame you if you use it for an array (with the =
risks and limitations involved). </div><div>You insist these are implied, b=
ut they are not if not written down.</div></div></blockquote><div><br></div=
><div>Is what you are suggesting here to make the wording firmer and more e=
xplicit that one should not ever use the guide with array pointers?=C2=A0</=
div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div>(the draft is just a draft and far from any final submission-read=
y wording.)</div><div><font size=3D"2">Currently I have the description (no=
t standardese wording): &quot;<span style=3D"color:rgb(36,41,46);font-famil=
y:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Helvetica,Arial,san=
s-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Sego=
e UI Symbol&quot;">For raw=C2=A0</span><em style=3D"color:rgb(36,41,46);fon=
t-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Helvetica,Ar=
ial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&qu=
ot;Segoe UI Symbol&quot;">array pointers</em><span style=3D"color:rgb(36,41=
,46);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Helv=
etica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&q=
uot;,&quot;Segoe UI Symbol&quot;">, the user will=C2=A0</span><em style=3D"=
color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&quot;Sego=
e UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;S=
egoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;">still</em><span style=3D"c=
olor:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe=
 UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Se=
goe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;">=C2=A0have to explicitly sp=
ecify the template arguments as before if=C2=A0</span><code style=3D"font-f=
amily:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,Courier,mon=
ospace;padding:0.2em 0.4em;background-color:rgba(27,31,35,0.05);border-radi=
us:3px;color:rgb(36,41,46)">operator[]</code><span style=3D"color:rgb(36,41=
,46);font-family:-apple-system,BlinkMacSystemFont,&quot;Segoe UI&quot;,Helv=
etica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&q=
uot;,&quot;Segoe UI Symbol&quot;">=C2=A0support is desired.</span>&quot;</f=
ont></div><div><font size=3D"2"><br></font></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">be clear future standards will not break you or sha=
me you if you use it for an array (with the risks and limitations involved)=
..<font size=3D"2"><br></font></blockquote><div><font size=3D"2"><br></font>=
</div><div>I&#39;m not sure I understand what you mean here.</div></div></b=
lockquote><div><br></div><div>Either way - forbid or allow - it must be wri=
tten out what is expected behavior. That is not an easy answer (to allow or=
 not). If it is disallowed the standard &quot;ensures&quot; the programmer =
writes more correct code and is easier to keep unique_ptr=C2=A0 to arrays a=
nd objects separate semantically and otherwise. If it allows it, it will be=
 more close to C/C++ view on the matter and, to some extend, closer to the =
programmer expectations - the alloc and dealloc is all it matters, the down=
side is - the standard must assume some unique_ptrs are arrays and carry th=
at dependency forward. Right now there is such a assumption as the array su=
pport came later and surely there is old code, not updated to the array ver=
sion, however with this proposal + not forbidding arrays, then it is not ju=
st old code, but new one as well. It will be official from now on and must =
be respected in the future.=C2=A0</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Second (from the top of my hea=
d) is to add an tag-based overload and add guide for arrays as well. Using =
a tag is better then the fragile types spelling out.<br></div><div>Also the=
 tag is better then the hypothetical as_array because it is clear interface=
 (part of the signature). With the as_array the user must know it exists an=
d must be used in order to get the array version (in other words to have re=
ad the documentaion).</div></div></blockquote><div><br></div><div>I don&#39=
;t understand what you mean by a tag-based overload.</div><div>Can you show=
 a short <i>usage </i>snippet of what that might look like?</div><div><br><=
/div></div></blockquote><div><font face=3D"courier new,monospace"><br></fon=
t></div><div><font face=3D"courier new,monospace">namespace std {</font></d=
iv><div><font face=3D"courier new,monospace">inline constexpr struct=C2=A0<=
span style=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-=
indent:0px;letter-spacing:normal;font-size:13px;font-style:normal;font-vari=
ant:normal;font-weight:400;text-decoration:none;word-spacing:0px;display:in=
line!important;white-space:normal;float:none;background-color:transparent">=
construct_from_array_t {}=C2=A0<span style=3D"text-align:left;color:rgb(34,=
34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-size:=
13px;font-style:normal;font-variant:normal;font-weight:400;text-decoration:=
none;word-spacing:0px;display:inline!important;white-space:normal;float:non=
e;background-color:transparent">construct_from_array;</span></span></font><=
/div><div><span style=3D"text-align:left;color:rgb(34,34,34);text-transform=
:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:norma=
l;font-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px=
;display:inline!important;white-space:normal;float:none;background-color:tr=
ansparent"><span style=3D"text-align:left;color:rgb(34,34,34);text-transfor=
m:none;text-indent:0px;letter-spacing:normal;font-size:13px;font-style:norm=
al;font-variant:normal;font-weight:400;text-decoration:none;word-spacing:0p=
x;display:inline!important;white-space:normal;float:none;background-color:t=
ransparent"><font face=3D"courier new,monospace">}</font></span></span></di=
v><div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike><b></b><=
i></i><u></u><sub></sub><sup></sup><strike></strike><font face=3D"courier n=
ew,monospace"></font><font face=3D"courier new,monospace"><br></font></div>=
<div><font face=3D"courier new,monospace">// usage</font></div><div><font f=
ace=3D"courier new,monospace"></font><br></div><div><font face=3D"courier n=
ew,monospace">std::unique_ptr up(std::construct_from_array,=C2=A0</font><fo=
nt face=3D"courier new,monospace"><wbr>new B[10], [](B* p) { delete [] p; }=
 ); </font></div><div><font face=3D"courier new,monospace">up.reset(new D[1=
0]); <i>//&lt; fails to compile, no member reset()</i></font></div><div><i>=
<font face=3D"courier new,monospace">up[5] =3D B{2};</font></i></div><div><=
i><font face=3D"courier new"><br></font></i></div><div><i><font face=3D"cou=
rier new"><br></font></i></div><div><font face=3D"arial,sans-serif">And BTW=
, the shared_ptr has the same limitations - it does not have deduction guid=
e for raw pointers. Why not fix that as well?</font></div></div></blockquot=
e><div><br></div><div>On the question of how such a tag should look, that i=
s way too verbose. It also requires a deprecation cycle. There&#39;s a bett=
er way. Observe:</div><div><br></div><div class=3D"prettyprint" style=3D"bo=
rder: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color=
: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span class=3D"styled-by-prettify" style=3D"color: #008;">template</s=
pan><span class=3D"styled-by-prettify" style=3D"color: #660;">&lt;</span><s=
pan class=3D"styled-by-prettify" style=3D"color: #008;">typename</span><spa=
n class=3D"styled-by-prettify" style=3D"color: #000;"> T</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">&gt;</span><span class=3D"st=
yled-by-prettify" style=3D"color: #000;"><br></span><span class=3D"styled-b=
y-prettify" style=3D"color: #008;">class</span><span class=3D"styled-by-pre=
ttify" style=3D"color: #000;"> from_array_t<br></span><span class=3D"styled=
-by-prettify" style=3D"color: #660;">{</span><span class=3D"styled-by-prett=
ify" style=3D"color: #000;"><br>=C2=A0 T </span><span class=3D"styled-by-pr=
ettify" style=3D"color: #660;">*</span><span class=3D"styled-by-prettify" s=
tyle=3D"color: #000;">ptr_</span><span class=3D"styled-by-prettify" style=
=3D"color: #660;">;</span><span class=3D"styled-by-prettify" style=3D"color=
: #000;"><br><br></span><span class=3D"styled-by-prettify" style=3D"color: =
#008;">public</span><span class=3D"styled-by-prettify" style=3D"color: #660=
;">:</span><span class=3D"styled-by-prettify" style=3D"color: #000;"><br>=
=C2=A0 from_array_t</span><span class=3D"styled-by-prettify" style=3D"color=
: #660;">(</span><span class=3D"styled-by-prettify" style=3D"color: #000;">=
T </span><span class=3D"styled-by-prettify" style=3D"color: #660;">*</span>=
<span class=3D"styled-by-prettify" style=3D"color: #000;">ptr</span><span c=
lass=3D"styled-by-prettify" style=3D"color: #660;">)</span><span class=3D"s=
tyled-by-prettify" style=3D"color: #000;"> </span><span class=3D"styled-by-=
prettify" style=3D"color: #660;">:</span><span class=3D"styled-by-prettify"=
 style=3D"color: #000;"> ptr_</span><span class=3D"styled-by-prettify" styl=
e=3D"color: #660;">(</span><span class=3D"styled-by-prettify" style=3D"colo=
r: #000;">ptr</span><span class=3D"styled-by-prettify" style=3D"color: #660=
;">)</span><span class=3D"styled-by-prettify" style=3D"color: #000;"> </spa=
n><span class=3D"styled-by-prettify" style=3D"color: #660;">{}</span><span =
class=3D"styled-by-prettify" style=3D"color: #000;"><br><br>=C2=A0 </span><=
span class=3D"styled-by-prettify" style=3D"color: #008;">operator</span><sp=
an class=3D"styled-by-prettify" style=3D"color: #000;"> T</span><span class=
=3D"styled-by-prettify" style=3D"color: #660;">*()</span><span class=3D"sty=
led-by-prettify" style=3D"color: #000;"> </span><span class=3D"styled-by-pr=
ettify" style=3D"color: #008;">const</span><span class=3D"styled-by-prettif=
y" style=3D"color: #000;"> </span><span class=3D"styled-by-prettify" style=
=3D"color: #660;">{</span><span class=3D"styled-by-prettify" style=3D"color=
: #008;">return</span><span class=3D"styled-by-prettify" style=3D"color: #0=
00;"> ptr</span><span class=3D"styled-by-prettify" style=3D"color: #660;">;=
}</span><span class=3D"styled-by-prettify" style=3D"color: #000;"><br></spa=
n><span class=3D"styled-by-prettify" style=3D"color: #660;">};</span><span =
class=3D"styled-by-prettify" style=3D"color: #000;"><br><br></span><span cl=
ass=3D"styled-by-prettify" style=3D"color: #008;">template</span><span clas=
s=3D"styled-by-prettify" style=3D"color: #660;">&lt;</span><span class=3D"s=
tyled-by-prettify" style=3D"color: #008;">typename</span><span class=3D"sty=
led-by-prettify" style=3D"color: #000;"> T</span><span class=3D"styled-by-p=
rettify" style=3D"color: #660;">&gt;</span><span class=3D"styled-by-prettif=
y" style=3D"color: #000;"><br>from_array_t from_array</span><span class=3D"=
styled-by-prettify" style=3D"color: #660;">(</span><span class=3D"styled-by=
-prettify" style=3D"color: #000;">T </span><span class=3D"styled-by-prettif=
y" style=3D"color: #660;">*</span><span class=3D"styled-by-prettify" style=
=3D"color: #000;">ptr</span><span class=3D"styled-by-prettify" style=3D"col=
or: #660;">)</span><span class=3D"styled-by-prettify" style=3D"color: #000;=
"> </span><span class=3D"styled-by-prettify" style=3D"color: #660;">{</span=
><span class=3D"styled-by-prettify" style=3D"color: #008;">return</span><sp=
an class=3D"styled-by-prettify" style=3D"color: #000;"> from_array_t</span>=
<span class=3D"styled-by-prettify" style=3D"color: #660;">&lt;</span><span =
class=3D"styled-by-prettify" style=3D"color: #000;">T</span><span class=3D"=
styled-by-prettify" style=3D"color: #660;">&gt;(</span><span class=3D"style=
d-by-prettify" style=3D"color: #000;">ptr</span><span class=3D"styled-by-pr=
ettify" style=3D"color: #660;">);}</span><span class=3D"styled-by-prettify"=
 style=3D"color: #000;"><br><br></span><span class=3D"styled-by-prettify" s=
tyle=3D"color: #008;">template</span><span class=3D"styled-by-prettify" sty=
le=3D"color: #660;">&lt;</span><span class=3D"styled-by-prettify" style=3D"=
color: #008;">typename</span><span class=3D"styled-by-prettify" style=3D"co=
lor: #000;"> T</span><span class=3D"styled-by-prettify" style=3D"color: #66=
0;">&gt;</span><span class=3D"styled-by-prettify" style=3D"color: #000;"><b=
r>unique_ptr</span><span class=3D"styled-by-prettify" style=3D"color: #660;=
">(</span><span class=3D"styled-by-prettify" style=3D"color: #000;">from_ar=
ray_t</span><span class=3D"styled-by-prettify" style=3D"color: #660;">&lt;<=
/span><span class=3D"styled-by-prettify" style=3D"color: #000;">T</span><sp=
an class=3D"styled-by-prettify" style=3D"color: #660;">&gt;)</span><span cl=
ass=3D"styled-by-prettify" style=3D"color: #000;"> </span><span class=3D"st=
yled-by-prettify" style=3D"color: #660;">-&gt;</span><span class=3D"styled-=
by-prettify" style=3D"color: #000;"> unique_ptr</span><span class=3D"styled=
-by-prettify" style=3D"color: #660;">&lt;</span><span class=3D"styled-by-pr=
ettify" style=3D"color: #000;">T</span><span class=3D"styled-by-prettify" s=
tyle=3D"color: #660;">[]&gt;;</span></div></code></div><div><br></div><div>=
This allows us to not have to change anything about `unique_ptr` itself (no=
 new constructors, no new specialization, and no deprecation of the pointer=
-based constructors). It&#39;s not nearly as verbose as the other version.<=
/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/3ff53b5b-a315-4bfb-81fb-1f846c257732%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3ff53b5b-a315-4bfb-81fb-1f846c257732=
%40isocpp.org</a>.<br />

------=_Part_18506_760370998.1515509618463--

------=_Part_18505_1791819031.1515509618462--

.

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

>
> On the question of how such a tag should look, that is way too verbose. It
> also requires a deprecation cycle. There's a better way. Observe:
>
> template<typename T>
> class from_array_t
> {
>   T *ptr_;
>
> public:
>   from_array_t(T *ptr) : ptr_(ptr) {}
>
>   operator T*() const {return ptr;}
> };
>
> template<typename T>
> from_array_t from_array(T *ptr) {return from_array_t<T>(ptr);}
>
> template<typename T>
> unique_ptr(from_array_t<T>) -> unique_ptr<T[]>;
>
> This allows us to not have to change anything about `unique_ptr` itself
> (no new constructors, no new specialization, and no deprecation of the
> pointer-based constructors). It's not nearly as verbose as the other
> version.
>

Neat! Thanks!
That's what I had in mind - just couldn't formulate it properly (still not
very proficient with deduction guides).
I really didn't want/intend to touch unique_ptr.

This solves the case for creation and support for array pointer (my
proposal just discussed custom deleters, but this is even more general)
giving us completeness.

There remains a philosophical question of misuse.
If a user forgets to add from_array_t then they are risking UB as mentioned
above.

--
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/CAEWUs4h1s04Qvob7FVFsUN6QR6AvTacpJWgrbmVCJSN0%2BCmMUg%40mail.gmail.com.

--001a113f837e6162cc0562596b50
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail-h5"><div><span style=3D"color:rgb(34,34,34)">On the question o=
f how such a tag should look, that is way too verbose. It also requires a d=
eprecation cycle. There&#39;s a better way. Observe:</span><br></div></div>=
</div><div><br></div><div class=3D"gmail-m_-6233632668019750158prettyprint"=
 style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background=
-color:rgb(250,250,250)"><code class=3D"gmail-m_-6233632668019750158prettyp=
rint"><div class=3D"gmail-m_-6233632668019750158subprettyprint"><span class=
=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,=
136)">template</span><span class=3D"gmail-m_-6233632668019750158styled-by-p=
rettify" style=3D"color:rgb(102,102,0)">&lt;</span><span class=3D"gmail-m_-=
6233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,136)">typenam=
e</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" styl=
e=3D"color:rgb(0,0,0)"> T</span><span class=3D"gmail-m_-6233632668019750158=
styled-by-prettify" style=3D"color:rgb(102,102,0)">&gt;</span><span class=
=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,=
0)"><br></span><span class=3D"gmail-m_-6233632668019750158styled-by-prettif=
y" style=3D"color:rgb(0,0,136)">class</span><span class=3D"gmail-m_-6233632=
668019750158styled-by-prettify" style=3D"color:rgb(0,0,0)"> from_array_t<br=
></span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" styl=
e=3D"color:rgb(102,102,0)">{</span><span class=3D"gmail-m_-6233632668019750=
158styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 T </span><span=
 class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rg=
b(102,102,0)">*</span><span class=3D"gmail-m_-6233632668019750158styled-by-=
prettify" style=3D"color:rgb(0,0,0)">ptr_</span><span class=3D"gmail-m_-623=
3632668019750158styled-by-prettify" style=3D"color:rgb(102,102,0)">;</span>=
<span class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"col=
or:rgb(0,0,0)"><br><br></span><span class=3D"gmail-m_-6233632668019750158st=
yled-by-prettify" style=3D"color:rgb(0,0,136)">public</span><span class=3D"=
gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(102,102,=
0)">:</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" =
style=3D"color:rgb(0,0,0)"><br>=C2=A0 from_array_t</span><span class=3D"gma=
il-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(102,102,0)"=
>(</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" sty=
le=3D"color:rgb(0,0,0)">T </span><span class=3D"gmail-m_-623363266801975015=
8styled-by-prettify" style=3D"color:rgb(102,102,0)">*</span><span class=3D"=
gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,0)">=
ptr</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" st=
yle=3D"color:rgb(102,102,0)">)</span><span class=3D"gmail-m_-62336326680197=
50158styled-by-prettify" style=3D"color:rgb(0,0,0)"> </span><span class=3D"=
gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(102,102,=
0)">:</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" =
style=3D"color:rgb(0,0,0)"> ptr_</span><span class=3D"gmail-m_-623363266801=
9750158styled-by-prettify" style=3D"color:rgb(102,102,0)">(</span><span cla=
ss=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,=
0,0)">ptr</span><span class=3D"gmail-m_-6233632668019750158styled-by-pretti=
fy" style=3D"color:rgb(102,102,0)">)</span><span class=3D"gmail-m_-62336326=
68019750158styled-by-prettify" style=3D"color:rgb(0,0,0)"> </span><span cla=
ss=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(10=
2,102,0)">{}</span><span class=3D"gmail-m_-6233632668019750158styled-by-pre=
ttify" style=3D"color:rgb(0,0,0)"><br><br>=C2=A0 </span><span class=3D"gmai=
l-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,136)">op=
erator</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify"=
 style=3D"color:rgb(0,0,0)"> T</span><span class=3D"gmail-m_-62336326680197=
50158styled-by-prettify" style=3D"color:rgb(102,102,0)">*()</span><span cla=
ss=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,=
0,0)"> </span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify=
" style=3D"color:rgb(0,0,136)">const</span><span class=3D"gmail-m_-62336326=
68019750158styled-by-prettify" style=3D"color:rgb(0,0,0)"> </span><span cla=
ss=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(10=
2,102,0)">{</span><span class=3D"gmail-m_-6233632668019750158styled-by-pret=
tify" style=3D"color:rgb(0,0,136)">return</span><span class=3D"gmail-m_-623=
3632668019750158styled-by-prettify" style=3D"color:rgb(0,0,0)"> ptr</span><=
span class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"colo=
r:rgb(102,102,0)">;}</span><span class=3D"gmail-m_-6233632668019750158style=
d-by-prettify" style=3D"color:rgb(0,0,0)"><br></span><span class=3D"gmail-m=
_-6233632668019750158styled-by-prettify" style=3D"color:rgb(102,102,0)">};<=
/span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=
=3D"color:rgb(0,0,0)"><br><br></span><span class=3D"gmail-m_-62336326680197=
50158styled-by-prettify" style=3D"color:rgb(0,0,136)">template</span><span =
class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb=
(102,102,0)">&lt;</span><span class=3D"gmail-m_-6233632668019750158styled-b=
y-prettify" style=3D"color:rgb(0,0,136)">typename</span><span class=3D"gmai=
l-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,0)"> T</=
span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=
=3D"color:rgb(102,102,0)">&gt;</span><span class=3D"gmail-m_-62336326680197=
50158styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>from_array_t from_a=
rray</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" s=
tyle=3D"color:rgb(102,102,0)">(</span><span class=3D"gmail-m_-6233632668019=
750158styled-by-prettify" style=3D"color:rgb(0,0,0)">T </span><span class=
=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(102,=
102,0)">*</span><span class=3D"gmail-m_-6233632668019750158styled-by-pretti=
fy" style=3D"color:rgb(0,0,0)">ptr</span><span class=3D"gmail-m_-6233632668=
019750158styled-by-prettify" style=3D"color:rgb(102,102,0)">)</span><span c=
lass=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(=
0,0,0)"> </span><span class=3D"gmail-m_-6233632668019750158styled-by-pretti=
fy" style=3D"color:rgb(102,102,0)">{</span><span class=3D"gmail-m_-62336326=
68019750158styled-by-prettify" style=3D"color:rgb(0,0,136)">return</span><s=
pan class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color=
:rgb(0,0,0)"> from_array_t</span><span class=3D"gmail-m_-623363266801975015=
8styled-by-prettify" style=3D"color:rgb(102,102,0)">&lt;</span><span class=
=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,=
0)">T</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" =
style=3D"color:rgb(102,102,0)">&gt;(</span><span class=3D"gmail-m_-62336326=
68019750158styled-by-prettify" style=3D"color:rgb(0,0,0)">ptr</span><span c=
lass=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(=
102,102,0)">);}</span><span class=3D"gmail-m_-6233632668019750158styled-by-=
prettify" style=3D"color:rgb(0,0,0)"><br><br></span><span class=3D"gmail-m_=
-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,136)">templa=
te</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" sty=
le=3D"color:rgb(102,102,0)">&lt;</span><span class=3D"gmail-m_-623363266801=
9750158styled-by-prettify" style=3D"color:rgb(0,0,136)">typename</span><spa=
n class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:r=
gb(0,0,0)"> T</span><span class=3D"gmail-m_-6233632668019750158styled-by-pr=
ettify" style=3D"color:rgb(102,102,0)">&gt;</span><span class=3D"gmail-m_-6=
233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>unique=
_ptr</span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" s=
tyle=3D"color:rgb(102,102,0)">(</span><span class=3D"gmail-m_-6233632668019=
750158styled-by-prettify" style=3D"color:rgb(0,0,0)">from_array_t</span><sp=
an class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:=
rgb(102,102,0)">&lt;</span><span class=3D"gmail-m_-6233632668019750158style=
d-by-prettify" style=3D"color:rgb(0,0,0)">T</span><span class=3D"gmail-m_-6=
233632668019750158styled-by-prettify" style=3D"color:rgb(102,102,0)">&gt;)<=
/span><span class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=
=3D"color:rgb(0,0,0)"> </span><span class=3D"gmail-m_-6233632668019750158st=
yled-by-prettify" style=3D"color:rgb(102,102,0)">-&gt;</span><span class=3D=
"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:rgb(0,0,0)"=
> unique_ptr</span><span class=3D"gmail-m_-6233632668019750158styled-by-pre=
ttify" style=3D"color:rgb(102,102,0)">&lt;</span><span class=3D"gmail-m_-62=
33632668019750158styled-by-prettify" style=3D"color:rgb(0,0,0)">T</span><sp=
an class=3D"gmail-m_-6233632668019750158styled-by-prettify" style=3D"color:=
rgb(102,102,0)">[]&gt;;</span></div></code></div><div><br></div><div>This a=
llows us to not have to change anything about `unique_ptr` itself (no new c=
onstructors, no new specialization, and no deprecation of the pointer-based=
 constructors). It&#39;s not nearly as verbose as the other version.</div><=
/div></blockquote><div><br></div><div>Neat! Thanks!</div><div>That&#39;s wh=
at I had in mind - just couldn&#39;t formulate it properly (still not very =
proficient with deduction guides).</div><div>I really didn&#39;t want/inten=
d to touch unique_ptr.</div><div><br></div><div>This solves the case for cr=
eation and support for array pointer (my proposal just discussed custom del=
eters, but this is even more general) giving us completeness.</div><div><br=
></div><div>There remains a philosophical question of misuse.=C2=A0</div><d=
iv>If a user forgets to add=C2=A0<span style=3D"background-color:rgb(250,25=
0,250);color:rgb(0,0,0);font-family:monospace">from_array_t</span>=C2=A0the=
n they are risking UB as mentioned above.</div><div><br></div><div>=C2=A0</=
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/CAEWUs4h1s04Qvob7FVFsUN6QR6AvTacpJWgr=
bmVCJSN0%2BCmMUg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEWUs4h1s04Qvo=
b7FVFsUN6QR6AvTacpJWgrbmVCJSN0%2BCmMUg%40mail.gmail.com</a>.<br />

--001a113f837e6162cc0562596b50--

.

------=_Part_18350_1996565483.1515511519224
Content-Type: multipart/alternative;
 boundary="----=_Part_18351_1900932648.1515511519224"

------=_Part_18351_1900932648.1515511519224
Content-Type: text/plain; charset="UTF-8"



On Tuesday, January 9, 2018 at 4:53:38 PM UTC+2, Nicol Bolas wrote:
>
> ...
>>
>>
> On the question of how such a tag should look, that is way too verbose. It
> also requires a deprecation cycle. There's a better way. Observe:
>
> template<typename T>
> class from_array_t
> {
>   T *ptr_;
>
> public:
>   from_array_t(T *ptr) : ptr_(ptr) {}
>
>   operator T*() const {return ptr;}
> };
>
> template<typename T>
> from_array_t from_array(T *ptr) {return from_array_t<T>(ptr);}
>
> template<typename T>
> unique_ptr(from_array_t<T>) -> unique_ptr<T[]>;
>
> This allows us to not have to change anything about `unique_ptr` itself
> (no new constructors, no new specialization, and no deprecation of the
> pointer-based constructors). It's not nearly as verbose as the other
> version.
>
>
Yeah, nice trick. However changing the unique/shared ptr is not a bad
thing, as we can remove constructors (or warn) if the ptr is declared as
T[], but not constructed with some_tag/from_array_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/b7ebd37d-6b3a-4629-998f-f9549e2d2d88%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 9, 2018 at 4:53:38 PM UTC+2, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">...<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div>=
</div></blockquote><div><br></div><div>On the question of how such a tag sh=
ould look, that is way too verbose. It also requires a deprecation cycle. T=
here&#39;s a better way. Observe:</div><div><br></div><div style=3D"border:=
1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,25=
0,250)"><code><div><span style=3D"color:#008">template</span><span style=3D=
"color:#660">&lt;</span><span style=3D"color:#008">typename</span><span sty=
le=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#008">class</span><span st=
yle=3D"color:#000"> from_array_t<br></span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"><br>=C2=A0 T </span><span style=3D"color:#660=
">*</span><span style=3D"color:#000">ptr_</span><span style=3D"color:#660">=
;</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#008=
">public</span><span style=3D"color:#660">:</span><span style=3D"color:#000=
"><br>=C2=A0 from_array_t</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#000">T </span><span style=3D"color:#660">*</span><span style=
=3D"color:#000">ptr</span><span style=3D"color:#660">)</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">:</span><span style=3D"colo=
r:#000"> ptr_</span><span style=3D"color:#660">(</span><span style=3D"color=
:#000">ptr</span><span style=3D"color:#660">)</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#660">{}</span><span style=3D"color:#000">=
<br><br>=C2=A0 </span><span style=3D"color:#008">operator</span><span style=
=3D"color:#000"> T</span><span style=3D"color:#660">*()</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">const</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#008">return</span><span style=3D"color:#000"> ptr</span><span style=
=3D"color:#660">;}</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">};</span><span style=3D"color:#000"><br><br></span><span st=
yle=3D"color:#008">template</span><span style=3D"color:#660">&lt;</span><sp=
an style=3D"color:#008">typename</span><span style=3D"color:#000"> T</span>=
<span style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br>from_a=
rray_t from_array</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">T </span><span style=3D"color:#660">*</span><span style=3D"color=
:#000">ptr</span><span style=3D"color:#660">)</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#660">{</span><span style=3D"color:#008">r=
eturn</span><span style=3D"color:#000"> from_array_t</span><span style=3D"c=
olor:#660">&lt;</span><span style=3D"color:#000">T</span><span style=3D"col=
or:#660">&gt;(</span><span style=3D"color:#000">ptr</span><span style=3D"co=
lor:#660">);}</span><span style=3D"color:#000"><br><br></span><span style=
=3D"color:#008">template</span><span style=3D"color:#660">&lt;</span><span =
style=3D"color:#008">typename</span><span style=3D"color:#000"> T</span><sp=
an style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br>unique_pt=
r</span><span style=3D"color:#660">(</span><span style=3D"color:#000">from_=
array_t</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#0=
00">T</span><span style=3D"color:#660">&gt;)</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">-&gt;</span><span style=3D"color:#000=
"> unique_ptr</span><span style=3D"color:#660">&lt;</span><span style=3D"co=
lor:#000">T</span><span style=3D"color:#660">[]&gt;;</span></div></code></d=
iv><div><br></div><div>This allows us to not have to change anything about =
`unique_ptr` itself (no new constructors, no new specialization, and no dep=
recation of the pointer-based constructors). It&#39;s not nearly as verbose=
 as the other version.</div><div><br></div></div></blockquote><div><br></di=
v><div>Yeah, nice trick. However changing the unique/shared ptr is not a ba=
d thing, as we can remove constructors (or warn) if the ptr is declared as =
T[], but not constructed with some_tag/from_array_t. =C2=A0</div><div><br><=
/div><div><br></div><div>=C2=A0</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/b7ebd37d-6b3a-4629-998f-f9549e2d2d88%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b7ebd37d-6b3a-4629-998f-f9549e2d2d88=
%40isocpp.org</a>.<br />

------=_Part_18351_1900932648.1515511519224--

------=_Part_18350_1996565483.1515511519224--

.

------=_Part_19065_703808713.1515521951235
Content-Type: multipart/alternative;
 boundary="----=_Part_19066_1271864444.1515521951235"

------=_Part_19066_1271864444.1515521951235
Content-Type: text/plain; charset="UTF-8"



On Tuesday, January 9, 2018 at 5:17:59 PM UTC+2, Adi Shavit wrote:
>
> On the question of how such a tag should look, that is way too verbose. It
>> also requires a deprecation cycle. There's a better way. Observe:
>> ...
>>
>
> There remains a philosophical question of misuse.
> If a user forgets to add from_array_t then they are risking UB as
> mentioned above.
>

This question  becomes non existent if explicit array construction is part
of the public interface of the class
Then there will be one right way tor create arrays and we can signal a
warning or error if used otherwise.

Having official support will allow us to create better versions not just of
the constructors, but for reset() as well.

unique_ptr<int[]> arr;
arr.reset(expr); *//< fails to compile, must be explicit: from_array(*expr
*)*

In general I don't see the point of adding complex machinery to mark array
creation and not improve unique and share ptr classes with these.

--
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/5a8fa916-757d-4164-baff-4a0aa5244181%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 9, 2018 at 5:17:59 PM UTC+2, A=
di Shavit wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div><div><div><span style=3D"color:rgb(34,34,3=
4)">On the question of how such a tag should look, that is way too verbose.=
 It also requires a deprecation cycle. There&#39;s a better way. Observe:</=
span><br></div></div></div><div>...</div></div></blockquote><div><br></div>=
<div>There remains a philosophical question of misuse.=C2=A0</div><div>If a=
 user forgets to add=C2=A0<span style=3D"background-color:rgb(250,250,250);=
color:rgb(0,0,0);font-family:monospace">from_array_t</span>=C2=A0then they =
are risking UB as mentioned above.</div><div></div></div></div></div></bloc=
kquote><div><br></div><div>This question=C2=A0 becomes non existent if expl=
icit array construction is part of the public interface of the class</div><=
div>Then there will be one right way tor create arrays and we can signal a =
warning or error if used otherwise.=C2=A0</div><div><br></div><div>Having o=
fficial support will allow us to create better versions not just of the con=
structors, but for <font face=3D"courier new,monospace">reset()</font><font=
 face=3D"arial,sans-serif"> </font>as well.</div><div><br></div><div><font =
face=3D"courier new,monospace">unique_ptr&lt;int[]&gt; arr;</font></div><di=
v><font face=3D"courier new,monospace">arr.reset(expr); <i>//&lt; fails to =
compile, must be explicit: from_array(</i><span style=3D"display: inline !i=
mportant; float: none; background-color: transparent; color: rgb(34, 34, 34=
); font-family: courier new,monospace; font-size: 13px; font-style: normal;=
 font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2=
; text-align: left; text-decoration: none; text-indent: 0px; text-transform=
: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: =
0px;">expr</span><i>)</i></font></div><div><br></div><div><font face=3D"ari=
al,sans-serif">In general I don&#39;t see the point of adding complex machi=
nery to mark array creation and not improve unique and share ptr classes wi=
th these.</font></div><div><font face=3D"arial,sans-serif"><br></font></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/5a8fa916-757d-4164-baff-4a0aa5244181%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5a8fa916-757d-4164-baff-4a0aa5244181=
%40isocpp.org</a>.<br />

------=_Part_19066_1271864444.1515521951235--

------=_Part_19065_703808713.1515521951235--

.

------=_Part_5578_1355765914.1515526949044
Content-Type: multipart/alternative;
 boundary="----=_Part_5579_42972725.1515526949044"

------=_Part_5579_42972725.1515526949044
Content-Type: text/plain; charset="UTF-8"



On Tuesday, January 9, 2018 at 1:19:11 PM UTC-5, mihailn...@gmail.com wrote:
>
>
>
> On Tuesday, January 9, 2018 at 5:17:59 PM UTC+2, Adi Shavit wrote:
>>
>> On the question of how such a tag should look, that is way too verbose.
>>> It also requires a deprecation cycle. There's a better way. Observe:
>>> ...
>>>
>>
>> There remains a philosophical question of misuse.
>> If a user forgets to add from_array_t then they are risking UB as
>> mentioned above.
>>
>
> This question  becomes non existent if explicit array construction is part
> of the public interface of the class
> Then there will be one right way tor create arrays and we can signal a
> warning or error if used otherwise.
>
> Having official support will allow us to create better versions not just
> of the constructors, but for reset() as well.
>
> unique_ptr<int[]> arr;
> arr.reset(expr); *//< fails to compile, must be explicit: from_array(*expr
> *)*
>
> In general I don't see the point of adding complex machinery to mark array
> creation and not improve unique and share ptr classes with these.
>

Here's the problem you run into:

unique_ptr ptr1(new int);
unique_ptr ptr2(new int[5]);
unique_ptr ptr3(from_array(new int));
unique_ptr ptr4(from_array(new int[5]));

What do we want to happen here? Well, in a perfect world, ptr1 would deduce
an `int`, while ptr2&4 would deduce `int[]`. And ptr3 would be a compile
error.

Obviously we don't exist in a perfect world. So long as `new T[]` returns a
`T*`, you *cannot* use deduction to solve all of our problems. There's no
way to differentiate ptr3 from 4, nor is there a way to differentiate ptr1
from 2.

What are our alternatives?

A) Make ptr1&2 compile errors. That is, never deduce from single pointers.
Make ptr3&4 deduce the same array type.
B) Allow ptr1&2 to compile, deducing the same type (`unique_ptr<int>`).
Make ptr3&4 deduce the same array type.
C) Add a `from_obj`, which is like `from_array`, except that it comes from
a single object. Thus, you would use that for ptr1.

Solutions B and C still allow you to accidentally use arrays in
single-object deduction and single-objects in array deduction. You haven't
truly fixed the problem; you've just stated your intent explicitly.

--
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/2c7b8924-2e84-42bf-8287-76b5c49a7188%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 9, 2018 at 1:19:11 PM UTC-5, m=
ihailn...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><br><br>On Tuesday, January 9, 2018 at 5:17:59 PM UTC+2, Adi S=
havit wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div><div><div><span style=3D"color:rgb(34,34,34)">On the=
 question of how such a tag should look, that is way too verbose. It also r=
equires a deprecation cycle. There&#39;s a better way. Observe:</span><br><=
/div></div></div><div>...</div></div></blockquote><div><br></div><div>There=
 remains a philosophical question of misuse.=C2=A0</div><div>If a user forg=
ets to add=C2=A0<span style=3D"background-color:rgb(250,250,250);color:rgb(=
0,0,0);font-family:monospace">from_array_t</span>=C2=A0then they are riskin=
g UB as mentioned above.</div><div></div></div></div></div></blockquote><di=
v><br></div><div>This question=C2=A0 becomes non existent if explicit array=
 construction is part of the public interface of the class</div><div>Then t=
here will be one right way tor create arrays and we can signal a warning or=
 error if used otherwise.=C2=A0</div><div><br></div><div>Having official su=
pport will allow us to create better versions not just of the constructors,=
 but for <font face=3D"courier new,monospace">reset()</font><font face=3D"a=
rial,sans-serif"> </font>as well.</div><div><br></div><div><font face=3D"co=
urier new,monospace">unique_ptr&lt;int[]&gt; arr;</font></div><div><font fa=
ce=3D"courier new,monospace">arr.reset(expr); <i>//&lt; fails to compile, m=
ust be explicit: from_array(</i><span style=3D"display:inline!important;flo=
at:none;background-color:transparent;color:rgb(34,34,34);font-family:courie=
r new,monospace;font-size:13px;font-style:normal;font-variant:normal;font-w=
eight:400;letter-spacing:normal;text-align:left;text-decoration:none;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px">expr</sp=
an><i>)</i></font></div><div><br></div><div><font face=3D"arial,sans-serif"=
>In general I don&#39;t see the point of adding complex machinery to mark a=
rray creation and not improve unique and share ptr classes with these.</fon=
t></div></div></blockquote><div><br></div><div>Here&#39;s the problem you r=
un into:</div><div><br></div><div>unique_ptr ptr1(new int);</div><div>uniqu=
e_ptr ptr2(new int[5]);</div><div>unique_ptr ptr3(from_array(new int));</di=
v><div>unique_ptr ptr4(from_array(new int[5]));</div><div><br></div><div>Wh=
at do we want to happen here? Well, in a perfect world, ptr1 would deduce a=
n `int`, while ptr2&amp;4 would deduce `int[]`. And ptr3 would be a compile=
 error.</div><div><br></div><div>Obviously we don&#39;t exist in a perfect =
world. So long as `new T[]` returns a `T*`, you <i style=3D"background-atta=
chment: scroll; background-clip: border-box; background-color: transparent;=
 background-image: none; background-origin: padding-box; background-positio=
n-x: 0%; background-position-y: 0%; background-repeat: repeat; background-s=
ize: auto; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none;=
 border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: str=
etch; border-image-slice: 100%; border-image-source: none; border-image-wid=
th: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-=
left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: n=
one; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top=
-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &=
amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-siz=
e: 13px; height: auto; margin-bottom: 0px; margin-left: 0px; margin-right: =
0px; margin-top: 0px; min-width: 0px; overflow: visible; overflow-x: visibl=
e; overflow-y: visible; padding-bottom: 0px; padding-left: 0px; padding-rig=
ht: 0px; padding-top: 0px;">cannot</i> use deduction to solve all of our pr=
oblems.=C2=A0There&#39;s no way to differentiate ptr3 from 4, nor is there =
a way to differentiate ptr1 from 2.</div><div><br></div><div>What are our a=
lternatives?</div><div><br></div><div>A) Make ptr1&amp;2 compile errors. Th=
at is, never deduce from single pointers. Make ptr3&amp;4 deduce the same a=
rray type.</div><div>B) Allow ptr1&amp;2 to compile, deducing the same type=
 (`unique_ptr&lt;int&gt;`). Make ptr3&amp;4 deduce the same array type.</di=
v><div>C) Add a `from_obj`, which is like `from_array`, except that it come=
s from a single object. Thus, you would use that for ptr1.</div><div><br></=
div><div>Solutions B and C still allow you to accidentally use arrays in si=
ngle-object deduction and single-objects in array deduction. You haven&#39;=
t truly fixed the problem; you&#39;ve just stated your intent explicitly.</=
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/2c7b8924-2e84-42bf-8287-76b5c49a7188%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2c7b8924-2e84-42bf-8287-76b5c49a7188=
%40isocpp.org</a>.<br />

------=_Part_5579_42972725.1515526949044--

------=_Part_5578_1355765914.1515526949044--

.

------=_Part_18674_369662209.1515528799422
Content-Type: multipart/alternative;
 boundary="----=_Part_18675_1204697993.1515528799422"

------=_Part_18675_1204697993.1515528799422
Content-Type: text/plain; charset="UTF-8"

From the small sample of folks who replied here and on Slack, I think the
atmosphere is that syntactic convenience does *not *trump misuse (iirc,
terse lambda syntax proposals had a similar disagreement).
I can understand that.

   1. Due to the inherent legacy C behavior there is no way to
   automatically deduce an array pointer.
   2. I do not plan on proposing a change to the unique_ptr interface.

However, the issues raised with this proposal are still valid.

Thus, I think this proposal would need to be significantly revised to
accommodate these concerns.
Based on discussions on Slack I have a direction for such a change. I will
post back here when they are made.

Nicol, @mihailn..., T.C. I appreciate your patience, suggestions, inputs
and comments.
Thanks to you I learned new things about unique_ptr<> and about what
considerations are taken into account for new proposals.
-- Adi

--
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/64d81863-3b38-4290-bf48-11d390d89116%40isocpp.org.

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

<div dir=3D"ltr">From the small sample of folks who replied here and on Sla=
ck, I think the atmosphere is that syntactic convenience does <b><i>not </i=
></b>trump misuse (iirc, terse lambda syntax proposals had a similar disagr=
eement).<div>I can understand that.<br><div><div><ol><li>Due to the inheren=
t legacy C behavior there is no way to automatically deduce an array pointe=
r.</li><li>I do not plan on proposing a change to the <font face=3D"courier=
 new, monospace">unique_ptr</font> interface.<br></li></ol><div>However, th=
e issues raised with this proposal are still valid.</div><div><br></div><di=
v>Thus, I think this proposal would need to be significantly revised to acc=
ommodate these concerns.</div></div></div></div><div>Based on discussions o=
n Slack I have a direction for such a change. I will post back here when th=
ey are made.</div><div><br></div><div><span style=3D"white-space: nowrap;">=
Nicol,=C2=A0</span><span style=3D"white-space: nowrap;">@mihailn...,=C2=A0<=
/span>T.C. I appreciate your patience, suggestions, inputs and=C2=A0comment=
s.=C2=A0</div><div>Thanks to you I learned new things about unique_ptr&lt;&=
gt; and about what considerations are taken into account for new proposals.=
</div><div>-- Adi</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/64d81863-3b38-4290-bf48-11d390d89116%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/64d81863-3b38-4290-bf48-11d390d89116=
%40isocpp.org</a>.<br />

------=_Part_18675_1204697993.1515528799422--

------=_Part_18674_369662209.1515528799422--

.

------=_Part_19530_191898288.1515533954242
Content-Type: multipart/alternative;
 boundary="----=_Part_19531_1895161002.1515533954243"

------=_Part_19531_1895161002.1515533954243
Content-Type: text/plain; charset="UTF-8"



On Tuesday, January 9, 2018 at 9:42:29 PM UTC+2, Nicol Bolas wrote:
>
>
>
> On Tuesday, January 9, 2018 at 1:19:11 PM UTC-5, mihailn...@gmail.com
> wrote:
>>
>>
>>
>> On Tuesday, January 9, 2018 at 5:17:59 PM UTC+2, Adi Shavit wrote:
>>>
>>> On the question of how such a tag should look, that is way too verbose.
>>>> It also requires a deprecation cycle. There's a better way. Observe:
>>>> ...
>>>>
>>>
>>> There remains a philosophical question of misuse.
>>> If a user forgets to add from_array_t then they are risking UB as
>>> mentioned above.
>>>
>>
>> This question  becomes non existent if explicit array construction is
>> part of the public interface of the class
>> Then there will be one right way tor create arrays and we can signal a
>> warning or error if used otherwise.
>>
>> Having official support will allow us to create better versions not just
>> of the constructors, but for reset() as well.
>>
>> unique_ptr<int[]> arr;
>> arr.reset(expr); *//< fails to compile, must be explicit: from_array(*
>> expr*)*
>>
>> In general I don't see the point of adding complex machinery to mark
>> array creation and not improve unique and share ptr classes with these.
>>
>
> Here's the problem you run into:
>
> unique_ptr ptr1(new int);
> unique_ptr ptr2(new int[5]);
> unique_ptr ptr3(from_array(new int));
> unique_ptr ptr4(from_array(new int[5]));
>
> What do we want to happen here? Well, in a perfect world, ptr1 would
> deduce an `int`, while ptr2&4 would deduce `int[]`. And ptr3 would be a
> compile error.
>
> Obviously we don't exist in a perfect world. So long as `new T[]` returns
> a `T*`, you *cannot* use deduction to solve all of our problems. There's
> no way to differentiate ptr3 from 4, nor is there a way to differentiate
> ptr1 from 2.
>
> What are our alternatives?
>
> A) Make ptr1&2 compile errors. That is, never deduce from single pointers.
> Make ptr3&4 deduce the same array type.
> B) Allow ptr1&2 to compile, deducing the same type (`unique_ptr<int>`).
> Make ptr3&4 deduce the same array type.
> C) Add a `from_obj`, which is like `from_array`, except that it comes from
> a single object. Thus, you would use that for ptr1.
>
> Solutions B and C still allow you to accidentally use arrays in
> single-object deduction and single-objects in array deduction. You haven't
> truly fixed the problem; you've just stated your intent explicitly.
>
>
The point was, if we go and bother to add explicit array syntax, the
classes will have some measurable benefits. It will not fix all issue, I am
perfectly aware of that.

As for the quiz - ptr1 and 4 compile fine with appropriate default dtors.

ptr2 and ptr3 are errors on the part of the programmer - he misused the API
provided.
He is not using the interface for arrays in 2 (one of the reasons to have a
ctor with a appropriately named type/tag) and he is lying blatantly in 3.

Now, if the types were specified, with the said improvements, then 2 would
have been a compile time error.
3 (and 4) could be improved if the function itself creates the array (still
returning the from_array-t token). (And have separate function/overload for
the (more rarer) cases when an existing array is to be moved in)

I am no making suggestions/proposals, just pointing out possible
consequences of a more explicit array construction.


--
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/3c5b5033-929a-4c9b-901a-bb3c405c02db%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, January 9, 2018 at 9:42:29 PM UTC+2, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><br>On Tuesday, January 9, 2018 at 1:19:11 PM UTC-5, <a>mihailn...@=
gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><br><br>On Tuesday, January 9, 2018 at 5:17:59 PM UTC+2, Adi Shavit wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div><div><div><span style=3D"color:rgb(34,34,34)">On the question=
 of how such a tag should look, that is way too verbose. It also requires a=
 deprecation cycle. There&#39;s a better way. Observe:</span><br></div></di=
v></div><div>...</div></div></blockquote><div><br></div><div>There remains =
a philosophical question of misuse.=C2=A0</div><div>If a user forgets to ad=
d=C2=A0<span style=3D"background-color:rgb(250,250,250);color:rgb(0,0,0);fo=
nt-family:monospace">from_array_t</span>=C2=A0then they are risking UB as m=
entioned above.</div><div></div></div></div></div></blockquote><div><br></d=
iv><div>This question=C2=A0 becomes non existent if explicit array construc=
tion is part of the public interface of the class</div><div>Then there will=
 be one right way tor create arrays and we can signal a warning or error if=
 used otherwise.=C2=A0</div><div><br></div><div>Having official support wil=
l allow us to create better versions not just of the constructors, but for =
<font face=3D"courier new,monospace">reset()</font><font face=3D"arial,sans=
-serif"> </font>as well.</div><div><br></div><div><font face=3D"courier new=
,monospace">unique_ptr&lt;int[]&gt; arr;</font></div><div><font face=3D"cou=
rier new,monospace">arr.reset(expr); <i>//&lt; fails to compile, must be ex=
plicit: from_array(</i><span style=3D"display:inline!important;float:none;b=
ackground-color:transparent;color:rgb(34,34,34);font-family:courier new,mon=
ospace;font-size:13px;font-style:normal;font-variant:normal;font-weight:400=
;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px">expr</span><i>)</=
i></font></div><div><br></div><div><font face=3D"arial,sans-serif">In gener=
al I don&#39;t see the point of adding complex machinery to mark array crea=
tion and not improve unique and share ptr classes with these.</font></div><=
/div></blockquote><div><br></div><div>Here&#39;s the problem you run into:<=
/div><div><br></div><div>unique_ptr ptr1(new int);</div><div>unique_ptr ptr=
2(new int[5]);</div><div>unique_ptr ptr3(from_array(new int));</div><div>un=
ique_ptr ptr4(from_array(new int[5]));</div><div><br></div><div>What do we =
want to happen here? Well, in a perfect world, ptr1 would deduce an `int`, =
while ptr2&amp;4 would deduce `int[]`. And ptr3 would be a compile error.</=
div><div><br></div><div>Obviously we don&#39;t exist in a perfect world. So=
 long as `new T[]` returns a `T*`, you <i>cannot</i> use deduction to solve=
 all of our problems.=C2=A0There&#39;s no way to differentiate ptr3 from 4,=
 nor is there a way to differentiate ptr1 from 2.</div><div><br></div><div>=
What are our alternatives?</div><div><br></div><div>A) Make ptr1&amp;2 comp=
ile errors. That is, never deduce from single pointers. Make ptr3&amp;4 ded=
uce the same array type.</div><div>B) Allow ptr1&amp;2 to compile, deducing=
 the same type (`unique_ptr&lt;int&gt;`). Make ptr3&amp;4 deduce the same a=
rray type.</div><div>C) Add a `from_obj`, which is like `from_array`, excep=
t that it comes from a single object. Thus, you would use that for ptr1.</d=
iv><div><br></div><div>Solutions B and C still allow you to accidentally us=
e arrays in single-object deduction and single-objects in array deduction. =
You haven&#39;t truly fixed the problem; you&#39;ve just stated your intent=
 explicitly.</div><div><br></div></div></blockquote><div><br></div><div>The=
 point was, if we go and bother to add explicit array syntax, the classes w=
ill have some measurable benefits. It will not fix all issue, I am perfectl=
y aware of that.</div><div><br></div><div>As for the quiz - ptr1 and 4 comp=
ile fine with appropriate default dtors.</div><div><br></div><div> ptr2 and=
 ptr3 are errors on the part of the programmer - he misused the API provide=
d. </div><div>He is not using the interface for arrays in 2 (one of the rea=
sons to have a ctor with a appropriately named type/tag) and he is lying bl=
atantly in 3.</div><div><br></div><div>Now, if the types were specified, <s=
pan style=3D"display: inline !important; float: none; background-color: tra=
nsparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helv=
etica&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: =
normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: l=
eft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit=
-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">with the =
said improvements</span>, then 2 would have been a compile time error.</div=
><div>3 (and 4) could be improved if the function itself creates the array =
(still returning the from_array-t token). (And have separate function/overl=
oad for the (more rarer) cases when an existing array is to be moved in)=C2=
=A0</div><div><br></div><div>I am no making suggestions/proposals, just poi=
nting out possible consequences of a more explicit array construction.</div=
><div>=C2=A0</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/3c5b5033-929a-4c9b-901a-bb3c405c02db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c5b5033-929a-4c9b-901a-bb3c405c02db=
%40isocpp.org</a>.<br />

------=_Part_19531_1895161002.1515533954243--

------=_Part_19530_191898288.1515533954242--

.