Consider the following code:

struct foo
{
    foo() = default;
 foo(int) {}
};

struct bar {};


foo operator+(foo, foo);
bar operator+(bar, int);

When writing an expression such as `foo{} + 3`, the first overload is
picked and `3` converted to `foo`.

But when we add the following constructor to bar:

bar(foo) = delete;

The overloads are ambiguous, as it can also convert `foo` to `bar` and
use the second overload, none is a better match.
This happens even though the constructor is deleted, it still
participates in overload resolution - by design.

However, I often want to use a deleted constructor to improve the error
message if bar has a lot of constructors with SFINAE. A "use of deleted
constructor" message is often a lot clearer than "no matching
constructor, this one doesn't work because ...., that one doesn't work
because ...". This is especially true if a delete with message is
supported one day.

But because of situations like the one above, I can't really do that as
it will provide a conversion considered by overload resolution.
Now we can make the deleted constructor explicit, so that it will not
participate for implicit conversion resolution,
but then we loose the "use of deleted constructor" message when someone
attempts an ill-formed implicit conversion.

My question: Is someone aware of the issue? If so, is there a proposed
resolution (either a language fix or a user workaround)?

My suggestion would be to rank a conversion using a deleted constructor
worse than everything else to resolve ambiguities, but I'm not an expert
on the implication.

Thanks,
Jonathan

--
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/e46f369c-e50f-98d7-76b9-09248ef228a9%40gmail.com.

.

------=_Part_779_1008574698.1485008067186
Content-Type: text/plain; charset=UTF-8

You could could mark the constructor explicit and then no conversion attempt is made.

-Richard

--
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/4d806ac6-9857-43e6-961b-d755d47128e6%40isocpp.org.

------=_Part_779_1008574698.1485008067186--

.

------=_Part_765_1065967971.1485015762991
Content-Type: multipart/alternative;
 boundary="----=_Part_766_359933814.1485015762991"

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



On Saturday, January 21, 2017 at 5:23:46 AM UTC-5, Jonathan M=C3=BCller wro=
te:
>
> Consider the following code:=20
>
> struct foo=20
> {=20
>            foo() =3D default;=20
>         foo(int) {}=20
> };=20
>
> struct bar {};=20
>
>
> foo operator+(foo, foo);=20
> bar operator+(bar, int);=20
>
> When writing an expression such as `foo{} + 3`, the first overload is=20
> picked and `3` converted to `foo`.=20
>
> But when we add the following constructor to bar:=20
>
> bar(foo) =3D delete;=20
>
> The overloads are ambiguous, as it can also convert `foo` to `bar` and=20
> use the second overload, none is a better match.=20
> This happens even though the constructor is deleted, it still=20
> participates in overload resolution - by design.=20
>
> However, I often want to use a deleted constructor to improve the error=
=20
> message if bar has a lot of constructors with SFINAE. A "use of deleted=
=20
> constructor" message is often a lot clearer than "no matching=20
> constructor, this one doesn't work because ...., that one doesn't work=20
> because ...". This is especially true if a delete with message is=20
> supported one day.
>
=20
>
But because of situations like the one above, I can't really do that as=20
> it will provide a conversion considered by overload resolution.=20
> Now we can make the deleted constructor explicit, so that it will not=20
> participate for implicit conversion resolution,=20
> but then we loose the "use of deleted constructor" message when someone=
=20
> attempts an ill-formed implicit conversion.=20
>
> My question: Is someone aware of the issue? If so, is there a proposed=20
> resolution (either a language fix or a user workaround)?
>

We didn't add `=3D delete` syntax to make error messages more reasonable=20
(well OK, we did, but not in the way you mean). Part of the motivation of=
=20
the feature was for cases where you want to *prevent* implicit conversion=
=20
of some parameters from some values, so you delete the alternatives you=20
don't want the user to invoke:

void f(float f);
void f(int) =3D delete; //Cannot call `f` with integers.

f(10); //Compile error.
f(20.0f); //OK.

The feature is working as intended. If `=3D delete` changed how overload=20
resolution worked, then it wouldn't be doing its job. You are mis-applying=
=20
the tool to a use case for which it was not intended.

What you want would require a new feature.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/185a86ba-61f6-495f-9aa8-4ffad393721f%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Saturday, January 21, 2017 at 5:23:46 AM UTC-5,=
 Jonathan M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Co=
nsider the following code:
<br>
<br>struct foo
<br>{
<br>=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo() =3D =
default;
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0foo(int) {}
<br>};
<br>
<br>struct bar {};
<br>
<br>
<br>foo operator+(foo, foo);
<br>bar operator+(bar, int);
<br>
<br>When writing an expression such as `foo{} + 3`, the first overload is=
=20
<br>picked and `3` converted to `foo`.
<br>
<br>But when we add the following constructor to bar:
<br>
<br>bar(foo) =3D delete;
<br>
<br>The overloads are ambiguous, as it can also convert `foo` to `bar` and=
=20
<br>use the second overload, none is a better match.
<br>This happens even though the constructor is deleted, it still=20
<br>participates in overload resolution - by design.
<br>
<br>However, I often want to use a deleted constructor to improve the error=
=20
<br>message if bar has a lot of constructors with SFINAE. A &quot;use of de=
leted=20
<br>constructor&quot; message is often a lot clearer than &quot;no matching=
=20
<br>constructor, this one doesn&#39;t work because ...., that one doesn&#39=
;t work=20
<br>because ...&quot;. This is especially true if a delete with message is=
=20
<br>supported one day.<br></blockquote><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204)=
; padding-left: 1ex;"><div>=C2=A0</div></blockquote><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
But because of situations like the one above, I can&#39;t really do that as=
=20
<br>it will provide a conversion considered by overload resolution.
<br>Now we can make the deleted constructor explicit, so that it will not=
=20
<br>participate for implicit conversion resolution,
<br>but then we loose the &quot;use of deleted constructor&quot; message wh=
en someone=20
<br>attempts an ill-formed implicit conversion.
<br>
<br>My question: Is someone aware of the issue? If so, is there a proposed=
=20
<br>resolution (either a language fix or a user workaround)?<br></blockquot=
e><div><br>We didn&#39;t add `=3D delete` syntax to make error messages mor=
e reasonable=20
(well OK, we did, but not in the way you mean). Part of the motivation of t=
he feature was for cases where you want to <i>prevent</i> implicit conversi=
on of some parameters=20
from some values, so you delete the alternatives you don&#39;t want the use=
r
 to invoke:<br><br><div style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overf=
low-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">delete</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">//Cannot call `f` with integers.</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br>f</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">10</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">//Compile error.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>f</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">20.0f</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">//OK.</span>=
</div></code></div><br>The feature is working as intended. If `=3D delete` =
changed how overload resolution worked, then it wouldn&#39;t be doing its j=
ob. You are mis-applying the tool to a use case for which it was not intend=
ed.<br><br>What you want would require a new feature.</div><br></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/185a86ba-61f6-495f-9aa8-4ffad393721f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/185a86ba-61f6-495f-9aa8-4ffad393721f=
%40isocpp.org</a>.<br />

------=_Part_766_359933814.1485015762991--

------=_Part_765_1065967971.1485015762991--

.

On 21.01.2017 17:22, Nicol Bolas wrote:
>
> We didn't add `= delete` syntax to make error messages more reasonable
> (well OK, we did, but not in the way you mean). Part of the motivation
> of the feature was for cases where you want to /prevent/ implicit
> conversion of some parameters from some values, so you delete the
> alternatives you don't want the user to invoke:

I'm aware of that.

> The feature is working as intended. If `= delete` changed how overload
> resolution worked, then it wouldn't be doing its job. You are
> mis-applying the tool to a use case for which it was not intended.

Let me rephrase the original code:

struct foo
{
     foo() = default;
     foo(int) {}

     operator std::string(); // implicitly convertible to std::string,
because why not
};

struct bar
{
     bar(std::string) {}
     bar(foo) = delete; // I only want really strings, not foo's
     // delete's intended use case
};

foo operator+(foo, foo);
bar operator+(bar, int);

foo{} + 3; // error, ambiguous, thanks to delete

Yes, the example is silly, but you'll get the point.


> What you want would require a new feature.

I don't want a new feature. I don't event want to change how `= delete`
participates in overload resolution.
I just want to change how `deleted` constructor conversions are ranked
when doing overload resolution.

Because - as far as I can tell - deleted constructors are broken.

--
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/1587cf50-ac78-62ec-4eff-b0971aeffd05%40gmail.com.

.

------=_Part_794_353817217.1485022398990
Content-Type: multipart/alternative;
 boundary="----=_Part_795_1875516472.1485022398990"

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

On Saturday, January 21, 2017 at 12:42:46 PM UTC-5, Jonathan M=C3=BCller wr=
ote:
>
> On 21.01.2017 17:22, Nicol Bolas wrote:=20
> >=20
> > We didn't add `=3D delete` syntax to make error messages more reasonabl=
e=20
> > (well OK, we did, but not in the way you mean). Part of the motivation=
=20
> > of the feature was for cases where you want to /prevent/ implicit=20
> > conversion of some parameters from some values, so you delete the=20
> > alternatives you don't want the user to invoke:=20
>
> I'm aware of that.=20
>
> > The feature is working as intended. If `=3D delete` changed how overloa=
d=20
> > resolution worked, then it wouldn't be doing its job. You are=20
> > mis-applying the tool to a use case for which it was not intended.=20
>
> Let me rephrase the original code:=20
>
> struct foo=20
> {=20
>      foo() =3D default;=20
>      foo(int) {}=20
>
>      operator std::string(); // implicitly convertible to std::string,=20
> because why not=20
> };=20
>
> struct bar=20
> {=20
>      bar(std::string) {}=20
>      bar(foo) =3D delete; // I only want really strings, not foo's=20
>      // delete's intended use case=20
> };=20
>

What you have written is a type that will fail to compile if a user tries=
=20
to initialize it with a `foo`. What you *think* you have written is a type=
=20
that *avoids* being initialized with a `foo`. That's not the same thing.=20
The goal of `=3D delete` is to make your compilation fail, not to make it=
=20
succeed.

`=3D delete` is about forcing you to be unambiguous; it is not about=20
*resolving* ambiguity.

foo operator+(foo, foo);=20
> bar operator+(bar, int);=20
>
> foo{} + 3; // error, ambiguous, thanks to delete=20
>
> Yes, the example is silly, but you'll get the point.
>

> > What you want would require a new feature.=20
>
> I don't want a new feature. I don't event want to change how `=3D delete`=
=20
> participates in overload resolution.=20
> I just want to change how `deleted` constructor conversions are ranked=20
> when doing overload resolution.
>

Changing what happens "when doing overload resolution" is a part of=20
changing how something "participates in overload resolution". So yes, that=
=20
is very much what you're wanting, and it is very much a new feature.

And there's no reason why such a feature ought to be tied to `=3D delete`.=
=20
Consider the following:

struct bar
{
     bar(int);
     __low_ranked bar(foo);
};

This still permits `bar` to be implicitly converted from `foo`. But if=20
there would be an ambiguous conversion sequence, then take the one that=20
isn't marked "__low_ranked".

Because - as far as I can tell - deleted constructors are broken.=20
>

They aren't broken; they're just not doing what you want. And it is not=20
their purpose to be used for what you're trying to use them for.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/edd9bc75-0f3f-47bd-adaf-c8f86ec6ffb4%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, January 21, 2017 at 12:42:46 PM UTC-5, Jonath=
an M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 21.01.=
2017 17:22, Nicol Bolas wrote:
<br>&gt;
<br>&gt; We didn&#39;t add `=3D delete` syntax to make error messages more =
reasonable
<br>&gt; (well OK, we did, but not in the way you mean). Part of the motiva=
tion
<br>&gt; of the feature was for cases where you want to /prevent/ implicit
<br>&gt; conversion of some parameters from some values, so you delete the
<br>&gt; alternatives you don&#39;t want the user to invoke:
<br>
<br>I&#39;m aware of that.
<br>
<br>&gt; The feature is working as intended. If `=3D delete` changed how ov=
erload
<br>&gt; resolution worked, then it wouldn&#39;t be doing its job. You are
<br>&gt; mis-applying the tool to a use case for which it was not intended.
<br>
<br>Let me rephrase the original code:
<br>
<br>struct foo
<br>{
<br>=C2=A0 =C2=A0 =C2=A0foo() =3D default;
<br>=C2=A0 =C2=A0 =C2=A0foo(int) {}
<br>
<br>=C2=A0 =C2=A0 =C2=A0operator std::string(); // implicitly convertible t=
o std::string,=20
<br>because why not
<br>};
<br>
<br>struct bar
<br>{
<br>=C2=A0 =C2=A0 =C2=A0bar(std::string) {}
<br>=C2=A0 =C2=A0 =C2=A0bar(foo) =3D delete; // I only want really strings,=
 not foo&#39;s
<br>=C2=A0 =C2=A0 =C2=A0// delete&#39;s intended use case
<br>};
<br></blockquote><div><br>What you have written is a type that will fail to=
 compile if a user tries to initialize it with a `foo`. What you <i>think</=
i> you have written is a type that <i>avoids</i> being initialized with a `=
foo`. That&#39;s not the same thing. The goal of `=3D delete` is to make yo=
ur compilation fail, not to make it succeed.<br><br>`=3D delete` is about f=
orcing you to be unambiguous; it is not about <i>resolving</i> ambiguity.<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
foo operator+(foo, foo);
<br>bar operator+(bar, int);
<br>
<br>foo{} + 3; // error, ambiguous, thanks to delete
<br>
<br>Yes, the example is silly, but you&#39;ll get the point.<br></blockquot=
e><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bor=
der-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br></div>=
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; What you want would require a new feature.
<br>
<br>I don&#39;t want a new feature. I don&#39;t event want to change how `=
=3D delete`=20
<br>participates in overload resolution.
<br>I just want to change how `deleted` constructor conversions are ranked=
=20
<br>when doing overload resolution.<br></blockquote><div><br>Changing what =
happens &quot;when doing overload resolution&quot; is a part of changing ho=
w something &quot;participates in overload resolution&quot;. So yes, that i=
s very much what you&#39;re wanting, and it is very much a new feature.<br>=
<br>And there&#39;s no reason why such a feature ought to be tied to `=3D d=
elete`. Consider the following:<br><br><div style=3D"background-color: rgb(=
250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bord=
er-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> bar<br></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0bar</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 =C2=A0__low_ranked bar</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">foo</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">};</span></div></code></div><br>This still permits `bar` to be im=
plicitly converted from `foo`. But if there would be an ambiguous conversio=
n sequence, then take the one that isn&#39;t marked &quot;__low_ranked&quot=
;.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Because - as far as I can tell - deleted constructors are broken.
<br></blockquote><div><br>They aren&#39;t broken; they&#39;re just not doin=
g what you want. And it is not their purpose to be used for what you&#39;re=
 trying to use them for.<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/edd9bc75-0f3f-47bd-adaf-c8f86ec6ffb4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/edd9bc75-0f3f-47bd-adaf-c8f86ec6ffb4=
%40isocpp.org</a>.<br />

------=_Part_795_1875516472.1485022398990--

------=_Part_794_353817217.1485022398990--

.

On 21.01.2017 19:13, Nicol Bolas wrote:
>
> Changing what happens "when doing overload resolution" is a part of
> changing how something "participates in overload resolution". So yes,
> that is very much what you're wanting, and it is very much a new feature.
>
> And there's no reason why such a feature ought to be tied to `= delete`.
> Consider the following:
>
> |
> structbar
> {
>      bar(int);
>      __low_ranked bar(foo);
> };
> |
>
> This still permits `bar` to be implicitly converted from `foo`. But if
> there would be an ambiguous conversion sequence, then take the one that
> isn't marked "__low_ranked".

Alright, then I'm requesting a new feature.

>     Because - as far as I can tell - deleted constructors are broken.
>
>
> They aren't broken; they're just not doing what you want. And it is not
> their purpose to be used for what you're trying to use them for.

I'm trying to write a type that will fail to compile if a user
initializes it with `foo`. That's what delete is for, right?

However, when I do so, this breaks a completely legitimate use case of
`foo` itself because of an ambiguity thanks to the deleted constructor.
I'd call that broken.

--
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/4756be72-a3c7-3da1-b7ef-945dca4bb369%40gmail.com.

.

------=_Part_1851_2064768588.1485286020780
Content-Type: multipart/alternative;
 boundary="----=_Part_1852_823056825.1485286020780"

------=_Part_1852_823056825.1485286020780
Content-Type: text/plain; charset=UTF-8


>
> The overloads are ambiguous, as it can also convert `foo` to `bar` and
> use the second overload, none is a better match.
> This happens even though the constructor is deleted, it still
> participates in overload resolution - by design.
>

I had this problem by myself. It also occours with private base classes...

See here:
http://stackoverflow.com/questions/30004771/why-is-a-malformed-function-used-instead-of-an-implicit-conversion

Maybe that helps for the discussion...

Cheers,
Jakob

--
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/6dffe6fe-9077-4b0d-8835-b5258fff6911%40isocpp.org.

------=_Part_1852_823056825.1485286020780
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;">The overloads=
 are ambiguous, as it can also convert `foo` to `bar` and=20
<br>use the second overload, none is a better match.
<br>This happens even though the constructor is deleted, it still=20
<br>participates in overload resolution - by design.
<br></blockquote><div><br></div><div>I had this problem by myself. It also =
occours with private base classes...</div><div><br></div><div>See here:</di=
v><div><a href=3D"http://stackoverflow.com/questions/30004771/why-is-a-malf=
ormed-function-used-instead-of-an-implicit-conversion">http://stackoverflow=
..com/questions/30004771/why-is-a-malformed-function-used-instead-of-an-impl=
icit-conversion</a></div><div><br></div><div>Maybe that helps for the discu=
ssion...</div><div><br></div><div>Cheers,</div><div>Jakob</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/6dffe6fe-9077-4b0d-8835-b5258fff6911%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6dffe6fe-9077-4b0d-8835-b5258fff6911=
%40isocpp.org</a>.<br />

------=_Part_1852_823056825.1485286020780--

------=_Part_1851_2064768588.1485286020780--

.