------=_Part_177_245179939.1405633221875
Content-Type: text/plain; charset=UTF-8

Consider the following code:

int baz(TS*);
int baz(ST*);

int bar(int) {
  int rc = 0;
  rc += baz(new TS());
  rc += baz(new ST());
  rc += baz(new MS()); //calls baz(ST*)
  return rc;
}

This code works as expected.

Now try it with smart pointers:

#include <memory>

class TS {};
class ST : public TS {};
class MS : public ST {};

int foo(std::unique_ptr<TS>);
int foo(std::unique_ptr<ST>);

int bar() {
  int rc = 0;
  rc += foo(std::make_unique<TS>());
  rc += foo(std::make_unique<ST>());
  rc += foo(std::make_unique<MS>()); //Compiler error, ambiguous overload!
  return rc;
}

The desired behavior would be for foo(std::make_unique<MS>()) to call
foo(std::unique_ptr<ST>), but instead it results in a compiler error due to
ambiguous overload.

Have there been any proposals to address this issue? It seems like a huge
leak in the smart pointer abstraction.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Consider the following code:<br><br>int baz(TS*);<br>int b=
az(ST*);<br><br>int bar(int) {<br>&nbsp; int rc =3D 0;<br>&nbsp; rc +=3D ba=
z(new TS());<br>&nbsp; rc +=3D baz(new ST());<br>&nbsp; rc +=3D baz(new MS(=
)); //calls baz(ST*)<br>&nbsp; return rc;<br>}<br><br>This code works as ex=
pected.<br><br>Now try it with smart pointers:<br><br>#include &lt;memory&g=
t;<br><br>class TS {};<br>class ST : public TS {};<br>class MS : public ST =
{};<br><br>int foo(std::unique_ptr&lt;TS&gt;);<br>int foo(std::unique_ptr&l=
t;ST&gt;);<br><br>int bar() {<br>&nbsp; int rc =3D 0;<br>&nbsp; rc +=3D foo=
(std::make_unique&lt;TS&gt;());<br>&nbsp; rc +=3D foo(std::make_unique&lt;S=
T&gt;());<br><span style=3D"color: rgb(0, 0, 255);">&nbsp; <span style=3D"c=
olor: rgb(0, 0, 0);">rc +=3D foo(std::make_unique&lt;MS&gt;());</span></spa=
n> //Compiler error, ambiguous overload!<br>&nbsp; return rc;<br>}<br><br>T=
he desired behavior would be for foo(std::make_unique&lt;MS&gt;()) to call =
foo(std::unique_ptr&lt;ST&gt;), but instead it results in a compiler error =
due to ambiguous overload. <br><br>Have there been any proposals to address=
 this issue? It seems like a huge leak in the smart pointer abstraction.<br=
></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_177_245179939.1405633221875--

.

On 2014-07-18, at 5:40 AM, Matthew Fioravante <fmatthew5876@gmail.com> wrot=
e:

> Have there been any proposals to address this issue? It seems like a huge=
 leak in the smart pointer abstraction.

Considering that these Google searches return very little, I suspect not.

https://www.google.com/search?q=3D"smart+pointer+covariance"+c%2B%2B
https://www.google.com/search?q=3D"covariant+smart+pointers"+c%2B%2B

You can, of course, hack around it using the naked pointer type as a dispat=
ch tag (by passing an unused pointer value of that type), and ensuring that=
 a user-defined conversion is always performed on the smart pointer so it w=
on't interfere with the overload resolution tournament.

I think that concepts might help improve expressiveness in this area, makin=
g it more fertile ground in the future (perhaps within the C++17 cycle?). I=
nstead of merely specifying that a function parameter template argument typ=
e must satisfy some criteria to vie for the title of best candidate functio=
n, the concept might also specify that it is mapped to something else befor=
e the tournament begins.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

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

I think it should be a property of unique_ptr itself, not some extra cruft=
=20
you have to tack onto every function accepting a unique_ptr. This would=20
mean adding something to the unique_ptr class which specifies a priority=20
for overloads, possibly inheriting the priority from the underlying pointer=
=20
type.

On Thursday, July 17, 2014 7:10:43 PM UTC-4, David Krauss wrote:
>
>
> On 2014=E2=80=9307=E2=80=9318, at 5:40 AM, Matthew Fioravante <fmatth...@=
gmail.com=20
> <javascript:>> wrote:=20
>
> > Have there been any proposals to address this issue? It seems like a=20
> huge leak in the smart pointer abstraction.=20
>
> Considering that these Google searches return very little, I suspect not.=
=20
>
> https://www.google.com/search?q=3D"smart+pointer+covariance"+c%2B%2B=20
> https://www.google.com/search?q=3D"covariant+smart+pointers"+c%2B%2B=20
>
> You can, of course, hack around it using the naked pointer type as a=20
> dispatch tag (by passing an unused pointer value of that type), and=20
> ensuring that a user-defined conversion is always performed on the smart=
=20
> pointer so it won=E2=80=99t interfere with the overload resolution tourna=
ment.=20
>
> I think that concepts might help improve expressiveness in this area,=20
> making it more fertile ground in the future (perhaps within the C++17=20
> cycle?). Instead of merely specifying that a function parameter template=
=20
> argument type must satisfy some criteria to vie for the title of best=20
> candidate function, the concept might also specify that it is mapped to=
=20
> something else before the tournament begins.=20
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">I think it should be a property of unique_ptr itself, not =
some extra cruft you have to tack onto every function accepting a unique_pt=
r. This would mean adding something to the unique_ptr class which specifies=
 a priority for overloads, possibly inheriting the priority from the underl=
ying pointer type.<br><br>On Thursday, July 17, 2014 7:10:43 PM UTC-4, Davi=
d Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On 2014=E2=80=9307=E2=80=9318, at 5:40 AM, Matthew Fioravante &lt;<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"hYacLs0bbqkJ"=
 onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">fmatth...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; Have there been any proposals to address this issue? It seems like=
 a huge leak in the smart pointer abstraction.
<br>
<br>Considering that these Google searches return very little, I suspect no=
t.
<br>
<br><a href=3D"https://www.google.com/search?q=3D" target=3D"_blank" onmous=
edown=3D"this.href=3D'https://www.google.com/search?q\075';return true;" on=
click=3D"this.href=3D'https://www.google.com/search?q\075';return true;">ht=
tps://www.google.com/search?<wbr>q=3D</a>"smart+pointer+covariance"+<wbr>c%=
2B%2B
<br><a href=3D"https://www.google.com/search?q=3D" target=3D"_blank" onmous=
edown=3D"this.href=3D'https://www.google.com/search?q\075';return true;" on=
click=3D"this.href=3D'https://www.google.com/search?q\075';return true;">ht=
tps://www.google.com/search?<wbr>q=3D</a>"covariant+smart+pointers"+<wbr>c%=
2B%2B
<br>
<br>You can, of course, hack around it using the naked pointer type as a di=
spatch tag (by passing an unused pointer value of that type), and ensuring =
that a user-defined conversion is always performed on the smart pointer so =
it won=E2=80=99t interfere with the overload resolution tournament.
<br>
<br>I think that concepts might help improve expressiveness in this area, m=
aking it more fertile ground in the future (perhaps within the C++17 cycle?=
). Instead of merely specifying that a function parameter template argument=
 type must satisfy some criteria to vie for the title of best candidate fun=
ction, the concept might also specify that it is mapped to something else b=
efore the tournament begins.
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_210_793832922.1405643783492--

.

--Apple-Mail=_A5A84965-5C3D-4AE9-B295-3B8A42547882
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1

I disagree. It does no harm for user-defined covariance to be specified sep=
arately from the type. This allows the covariance spec to be reusable, wher=
e defining covariance correctly might be beyond the average metaprogrammer =
-- if not in fact of their ability, then in their confidence. It also provi=
des an escape route when current behavior is desired instead, which is impo=
rtant for a breaking change.

It would be essential to be able to specify that such concept adjustments s=
hould be applied to a parameter type. If concept names are allowed as type-=
names in a template context, they might be allowed as combining simple-type=
-specifiers in a non-template context. So it would look like

void f( std::covariant std::unique_ptr< thing > q ); // syntactically analo=
gous to "unsigned int"
void f( std::covariant std::shared_ptr< thing > q ); // apply same concept-=
adaptation to another type

void f( std::covariant int q ); // error: concept failure

The same syntax could be back-ported to regular concepts. (Perhaps this has=
 already been considered?)

template< typename pointer_type >
void f( std::covariant pointer_type q );
 // same as:
template< typename pointer_type >
void f( pointer_type q )
 requires std::covariant< pointer_type >();

This is pretty radical, but so is anything making concepts more than a Bool=
ean test or pretty SFINAE. :)


On 2014-07-18, at 8:36 AM, Matthew Fioravante <fmatthew5876@gmail.com> wrot=
e:

> I think it should be a property of unique_ptr itself, not some extra cruf=
t you have to tack onto every function accepting a unique_ptr. This would m=
ean adding something to the unique_ptr class which specifies a priority for=
 overloads, possibly inheriting the priority from the underlying pointer ty=
pe.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_A5A84965-5C3D-4AE9-B295-3B8A42547882
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><div>I disagree. It do=
es no harm for user-defined covariance to be specified separately from the =
type. This allows the covariance spec to be reusable, where defining covari=
ance correctly might be beyond the average metaprogrammer &mdash; if not in=
 fact of their ability, then in their confidence. It also provides an escap=
e route when current behavior is desired instead, which is important for a =
breaking change.</div><div><br></div><div>It would be essential to be able =
to specify that such concept adjustments should be applied to a parameter t=
ype. If concept names are allowed as <i>type-names</i> in a template contex=
t, they might be allowed as combining <i>simple-type-specifiers</i> in a no=
n-template context. So it would look like</div><div><br></div><div><font fa=
ce=3D"Courier">void f( std::covariant std::unique_ptr&lt; thing &gt; q ); /=
/ syntactically analogous to &ldquo;unsigned int&rdquo;</font></div><font f=
ace=3D"Courier">void f( std::covariant std::shared_ptr&lt; thing &gt; q ); =
// apply same concept-adaptation to another type</font><div><font face=3D"C=
ourier"><br></font><div><div><font face=3D"Courier">void f( std::covariant =
int q ); // error: concept failure</font></div><div><br></div><div>The same=
 syntax could be back-ported to regular concepts. (Perhaps this has already=
 been considered?)</div><div><br></div><div><font face=3D"Courier">template=
&lt; typename pointer_type &gt;</font></div><div><div><font face=3D"Courier=
">void f( std::covariant pointer_type q );</font></div><div><font face=3D"C=
ourier"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span></=
font><span style=3D"font-family: Courier;">// same as:</span></div><div><di=
v><font face=3D"Courier">template&lt; typename pointer_type &gt;</font></di=
v><div><font face=3D"Courier">void f( pointer_type q )</font></div></div><d=
iv><font face=3D"Courier"><span class=3D"Apple-tab-span" style=3D"white-spa=
ce:pre"> </span>requires std::covariant&lt; pointer_type &gt;();</font></di=
v><div><br></div><div>This is pretty radical, but so is anything making con=
cepts more than a Boolean test or pretty SFINAE. :)</div><div><br></div><di=
v><br></div><div><div>On 2014&ndash;07&ndash;18, at 8:36 AM, Matthew Fiorav=
ante &lt;<a href=3D"mailto:fmatthew5876@gmail.com">fmatthew5876@gmail.com</=
a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote type=
=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px; font-style=
: normal; font-variant: normal; font-weight: normal; letter-spacing: normal=
; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px;=
 -webkit-text-stroke-width: 0px;"><div dir=3D"ltr">I think it should be a p=
roperty of unique_ptr itself, not some extra cruft you have to tack onto ev=
ery function accepting a unique_ptr. This would mean adding something to th=
e unique_ptr class which specifies a priority for overloads, possibly inher=
iting the priority from the underlying pointer type.<br></div></div></block=
quote></div><br></div></div></div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_A5A84965-5C3D-4AE9-B295-3B8A42547882--

.