------=_Part_1509_1399561587.1474613046841
Content-Type: multipart/alternative;
 boundary="----=_Part_1510_136540261.1474613046841"

------=_Part_1510_136540261.1474613046841
Content-Type: text/plain; charset=UTF-8

The Facebook program
verifier flint (https://code.facebook.com/posts/729709347050548/under-the-hood-building-and-open-sourcing-flint/)
encourages that non-explicit single-argument constructors and conversion
operators should be marked with /* implicit */ comments (rules 14 and 22).

I wonder if there would be Committee support for a proposal for an
[[implicit]] attribute. Compilers could be encouraged to warn about missing
attribute on non-explicit single argument constructors and conversion
operators without such an attribute annotation. Neither gcc nor clang
appear to have warnings for this at the moment.


--
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/43a74c91-7ad1-408b-9ef0-e0f69e010092%40isocpp.org.

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

<div dir=3D"ltr">The Facebook program verifier=C2=A0flint=C2=A0(https://cod=
e.facebook.com/posts/729709347050548/under-the-hood-building-and-open-sourc=
ing-flint/) encourages that non-explicit single-argument constructors and c=
onversion operators should be marked with /* implicit */ comments (rules 14=
 and 22).=C2=A0<div><br></div><div>I wonder if there would be Committee sup=
port for a proposal for an [[implicit]] attribute. Compilers could be encou=
raged to warn about missing attribute on non-explicit single argument const=
ructors and conversion operators without such an attribute annotation. Neit=
her gcc nor clang appear to have warnings for this at the moment.<div><br><=
/div><div><br></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/43a74c91-7ad1-408b-9ef0-e0f69e010092%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/43a74c91-7ad1-408b-9ef0-e0f69e010092=
%40isocpp.org</a>.<br />

------=_Part_1510_136540261.1474613046841--

------=_Part_1509_1399561587.1474613046841--

.

rhalbersma@gmail.com writes:

> The Facebook program verifier flint
> (https://code.facebook.com/posts/729709347050548/under-the-hood-building-and-open-sourcing-flint/)
> encourages that non-explicit single-argument constructors and
> conversion operators should be marked with /* implicit */ comments
> (rules 14 and 22).
>
> I wonder if there would be Committee support for a proposal for an
> [[implicit]] attribute. Compilers could be encouraged to warn about
> missing attribute on non-explicit single argument constructors and
> conversion operators without such an attribute annotation. Neither gcc
> nor clang appear to have warnings for this at the moment.

I'm not the Committee but I like the idea a lot.  It seems very easy to
implement and doesn't hurt anybody who doesn't like it.

The only potential problem I can see is that enabling the warning would
trigger *a lot* of "false" positives for third-party headers that might
never get "fixed" because their authors don't adhere to the coding
standard.  Wrapping all third-party `#include`s into `#pragma`s to
temporairly silence the warning is not an option I'd choose eagerly.

--
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/87y42i4xsc.fsf%40gmail.com.

.

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

On Fri, Sep 23, 2016 at 2:15 PM, Moritz Klammler <moritz.klammler@gmail.com>
wrote:

> rhalbersma@gmail.com writes:
>
> > The Facebook program verifier flint
> > (https://code.facebook.com/posts/729709347050548/under-
> the-hood-building-and-open-sourcing-flint/)
> > encourages that non-explicit single-argument constructors and
> > conversion operators should be marked with /* implicit */ comments
> > (rules 14 and 22).
> >
> > I wonder if there would be Committee support for a proposal for an
> > [[implicit]] attribute. Compilers could be encouraged to warn about
> > missing attribute on non-explicit single argument constructors and
> > conversion operators without such an attribute annotation. Neither gcc
> > nor clang appear to have warnings for this at the moment.
>
> I'm not the Committee but I like the idea a lot.  It seems very easy to
> implement and doesn't hurt anybody who doesn't like it.
>
> The only potential problem I can see is that enabling the warning would
> trigger *a lot* of "false" positives for third-party headers that might
> never get "fixed" because their authors don't adhere to the coding
> standard.  Wrapping all third-party `#include`s into `#pragma`s to
> temporairly silence the warning is not an option I'd choose eagerly.
>

I guess the usual trick of marking such headers as system headers would
avoid the need for wrapping (-isystem on gcc/clang, there is also a CMake
flag IIRC)

--
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/CAGBGO5X%3DdhecUa6EPgdd4OWzpbxZE8DyDj-OvoWDxKHL7PTZiQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Sep 23, 2016 at 2:15 PM, Moritz Klammler <span dir=3D"ltr">&lt;<a href=
=3D"mailto:moritz.klammler@gmail.com" target=3D"_blank">moritz.klammler@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D""><a href=3D"mailto:rhalbersma@gmail.com">rhalbersma@gmail.com</a> writ=
es:<br>
<br>
&gt; The Facebook program verifier flint<br>
&gt; (<a href=3D"https://code.facebook.com/posts/729709347050548/under-the-=
hood-building-and-open-sourcing-flint/" rel=3D"noreferrer" target=3D"_blank=
">https://code.facebook.com/<wbr>posts/729709347050548/under-<wbr>the-hood-=
building-and-open-<wbr>sourcing-flint/</a>)<br>
&gt; encourages that non-explicit single-argument constructors and<br>
&gt; conversion operators should be marked with /* implicit */ comments<br>
&gt; (rules 14 and 22).<br>
&gt;<br>
&gt; I wonder if there would be Committee support for a proposal for an<br>
&gt; [[implicit]] attribute. Compilers could be encouraged to warn about<br=
>
&gt; missing attribute on non-explicit single argument constructors and<br>
&gt; conversion operators without such an attribute annotation. Neither gcc=
<br>
&gt; nor clang appear to have warnings for this at the moment.<br>
<br>
</span>I&#39;m not the Committee but I like the idea a lot.=C2=A0 It seems =
very easy to<br>
implement and doesn&#39;t hurt anybody who doesn&#39;t like it.<br>
<br>
The only potential problem I can see is that enabling the warning would<br>
trigger *a lot* of &quot;false&quot; positives for third-party headers that=
 might<br>
never get &quot;fixed&quot; because their authors don&#39;t adhere to the c=
oding<br>
standard.=C2=A0 Wrapping all third-party `#include`s into `#pragma`s to<br>
temporairly silence the warning is not an option I&#39;d choose eagerly.<br=
>
</blockquote></div><br></div><div class=3D"gmail_extra">I guess the usual t=
rick of marking such headers as system headers would avoid the need for wra=
pping (-isystem on gcc/clang, there is also a CMake flag IIRC)</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/CAGBGO5X%3DdhecUa6EPgdd4OWzpbxZE8DyDj=
-OvoWDxKHL7PTZiQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5X%3Ddhec=
Ua6EPgdd4OWzpbxZE8DyDj-OvoWDxKHL7PTZiQ%40mail.gmail.com</a>.<br />

--001a1147cd72bdbb29053d2c5a83--

.

> On 23 Sep 2016, at 14:15, Moritz Klammler <moritz.klammler@gmail.com> wro=
te:
>=20
> rhalbersma@gmail.com writes:
>=20
>> The Facebook program verifier flint
>> (https://code.facebook.com/posts/729709347050548/under-the-hood-building=
-and-open-sourcing-flint/)
>> encourages that non-explicit single-argument constructors and
>> conversion operators should be marked with /* implicit */ comments
>> (rules 14 and 22).
>>=20
>> I wonder if there would be Committee support for a proposal for an
>> [[implicit]] attribute. Compilers could be encouraged to warn about
>> missing attribute on non-explicit single argument constructors and
>> conversion operators without such an attribute annotation. Neither gcc
>> nor clang appear to have warnings for this at the moment.
>=20
> I'm not the Committee but I like the idea a lot.  It seems very easy to
> implement and doesn't hurt anybody who doesn't like it.

It does hurt. A lot. I try to write code that compiles with -Wall, -Wextra,=
 -Werror, but with each new compiler generation it becomes more difficult. =
Code that was clean and concise before is more and more cluttered with anno=
tations or work-arounds just to get rid of the warnings. In one case, this =
even forced me to pull in another header and therefore slows down compile t=
imes. Also: How would you tell the compiler that this is a system header? I=
n a portable, standardized way! Because I don't want to add another level o=
f complexity to support different compilers. Switching of the warning local=
ly is equally bad, each compiler has its own way and identification for a s=
pecific warning.

If you want to use lint-tools, fine, but encouraging compiler writers to ad=
d (or even mandate) warnings needs a really good justification. [[fallthoug=
h]] I can understand, it helps to catch real bugs and it is used only as an=
 exception. But a non-explicit single-argument ctor is quite common and oft=
en the right choice, so I would really like to use it without any further f=
uss.

--=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/8FA8B9B6-F25B-4393-947B-82C104B812DB%40gmx.de.

.

On 23 September 2016 at 16:57, Daniel Frey <d.frey@gmx.de> wrote:
>> I'm not the Committee but I like the idea a lot.  It seems very easy to
>> implement and doesn't hurt anybody who doesn't like it.
>
> It does hurt. A lot. I try to write code that compiles with -Wall, -Wextra, -Werror, but with each new compiler generation it becomes more difficult. Code that was

I don't believe it's feasible for a C++ implementation to enable the
warning we're talking about by default.

--
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/CAFk2RUYhNFO7i8ez1Ymn%3D8yugrQpYM7%3DbwH%3D8u11LZYH2Tnpbg%40mail.gmail.com.

.

------=_Part_1985_1768717127.1474639698352
Content-Type: multipart/alternative;
 boundary="----=_Part_1986_1271947198.1474639698352"

------=_Part_1986_1271947198.1474639698352
Content-Type: text/plain; charset=UTF-8



On Friday, September 23, 2016 at 3:57:05 PM UTC+2, Daniel Frey wrote:
>
> > On 23 Sep 2016, at 14:15, Moritz Klammler <moritz....@gmail.com
> <javascript:>> wrote:
> >
> > rhalb...@gmail.com <javascript:> writes:
> >
> >> The Facebook program verifier flint
> >> (
> https://code.facebook.com/posts/729709347050548/under-the-hood-building-and-open-sourcing-flint/)
>
> >> encourages that non-explicit single-argument constructors and
> >> conversion operators should be marked with /* implicit */ comments
> >> (rules 14 and 22).
> >>
> >> I wonder if there would be Committee support for a proposal for an
> >> [[implicit]] attribute. Compilers could be encouraged to warn about
> >> missing attribute on non-explicit single argument constructors and
> >> conversion operators without such an attribute annotation. Neither gcc
> >> nor clang appear to have warnings for this at the moment.
> >
> > I'm not the Committee but I like the idea a lot.  It seems very easy to
> > implement and doesn't hurt anybody who doesn't like it.
>
> It does hurt. A lot. I try to write code that compiles with -Wall,
> -Wextra, -Werror, but with each new compiler generation it becomes more
> difficult. Code that was clean and concise before is more and more
> cluttered with annotations or work-arounds just to get rid of the warnings.
> In one case, this even forced me to pull in another header and therefore
> slows down compile times. Also: How would you tell the compiler that this
> is a system header? In a portable, standardized way! Because I don't want
> to add another level of complexity to support different compilers.
> Switching of the warning locally is equally bad, each compiler has its own
> way and identification for a specific warning.
>
> If you want to use lint-tools, fine, but encouraging compiler writers to
> add (or even mandate) warnings needs a really good justification.
> [[fallthough]] I can understand, it helps to catch real bugs and it is used
> only as an exception. But a non-explicit single-argument ctor is quite
> common and often the right choice, so I would really like to use it without
> any further fuss.
>

The C++ Core guidelines also recommend warning against lack of explicit
keywords:

http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#a-namerc-explicitac46-by-default-declare-single-argument-constructors-explicit
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ro-conversion

You might be right that it can be an intended design choice to leave a
constructor implicit, but since it will silently generate conversions in
places where one might not expect it, shouldn't a warning be prudent? You
can silence this with [[implicit] in your own code (once) and for legacy
code treat them as system headers (if CMake has a SYSTEM flag for it, then
all major compilers can do this already).

--
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/d1e28b80-5c8b-49bf-9a49-859b19ffa1b8%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, September 23, 2016 at 3:57:05 PM UTC+2,=
 Daniel Frey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; On 23 =
Sep 2016, at 14:15, Moritz Klammler &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"eZdfDh1kAAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">moritz....@gmail.com</a>&gt; wrote:
<br>&gt;=20
<br>&gt; <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"eZdfDh1kAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">rhalb...@gmail.com</a> writes:
<br>&gt;=20
<br>&gt;&gt; The Facebook program verifier flint
<br>&gt;&gt; (<a href=3D"https://code.facebook.com/posts/729709347050548/un=
der-the-hood-building-and-open-sourcing-flint/" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhtt=
ps%3A%2F%2Fcode.facebook.com%2Fposts%2F729709347050548%2Funder-the-hood-bui=
lding-and-open-sourcing-flint%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH0=
dlQs1flKklDkqHd505Pj0knkEg&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttps://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.facebook.com%2Fposts%2F72=
9709347050548%2Funder-the-hood-building-and-open-sourcing-flint%2F\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNH0dlQs1flKklDkqHd505Pj0knkEg&#39;;return tr=
ue;">https://code.facebook.com/<wbr>posts/729709347050548/under-<wbr>the-ho=
od-building-and-open-<wbr>sourcing-flint/</a>)
<br>&gt;&gt; encourages that non-explicit single-argument constructors and
<br>&gt;&gt; conversion operators should be marked with /* implicit */ comm=
ents
<br>&gt;&gt; (rules 14 and 22).
<br>&gt;&gt;=20
<br>&gt;&gt; I wonder if there would be Committee support for a proposal fo=
r an
<br>&gt;&gt; [[implicit]] attribute. Compilers could be encouraged to warn =
about
<br>&gt;&gt; missing attribute on non-explicit single argument constructors=
 and
<br>&gt;&gt; conversion operators without such an attribute annotation. Nei=
ther gcc
<br>&gt;&gt; nor clang appear to have warnings for this at the moment.
<br>&gt;=20
<br>&gt; I&#39;m not the Committee but I like the idea a lot. =C2=A0It seem=
s very easy to
<br>&gt; implement and doesn&#39;t hurt anybody who doesn&#39;t like it.
<br>
<br>It does hurt. A lot. I try to write code that compiles with -Wall, -Wex=
tra, -Werror, but with each new compiler generation it becomes more difficu=
lt. Code that was clean and concise before is more and more cluttered with =
annotations or work-arounds just to get rid of the warnings. In one case, t=
his even forced me to pull in another header and therefore slows down compi=
le times. Also: How would you tell the compiler that this is a system heade=
r? In a portable, standardized way! Because I don&#39;t want to add another=
 level of complexity to support different compilers. Switching of the warni=
ng locally is equally bad, each compiler has its own way and identification=
 for a specific warning.
<br>
<br>If you want to use lint-tools, fine, but encouraging compiler writers t=
o add (or even mandate) warnings needs a really good justification. [[fallt=
hough]] I can understand, it helps to catch real bugs and it is used only a=
s an exception. But a non-explicit single-argument ctor is quite common and=
 often the right choice, so I would really like to use it without any furth=
er fuss.
<br></blockquote><div><br></div><div>The C++ Core guidelines also recommend=
 warning against lack of explicit keywords:</div><div><br></div><div>http:/=
/isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#a-namerc-explicitac46=
-by-default-declare-single-argument-constructors-explicit=C2=A0</div><div>h=
ttp://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ro-conversion=C2=
=A0</div><div><br></div><div>You might be right that it can be an intended =
design choice to leave a constructor implicit, but since it will silently g=
enerate conversions in places where one might not expect it, shouldn&#39;t =
a warning be prudent? You can silence this with [[implicit] in your own cod=
e (once) and for legacy code treat them as system headers (if CMake has a S=
YSTEM flag for it, then all major compilers can do this already). =C2=A0</d=
iv></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/d1e28b80-5c8b-49bf-9a49-859b19ffa1b8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d1e28b80-5c8b-49bf-9a49-859b19ffa1b8=
%40isocpp.org</a>.<br />

------=_Part_1986_1271947198.1474639698352--

------=_Part_1985_1768717127.1474639698352--

.

------=_Part_1771_914819294.1474639897296
Content-Type: multipart/alternative;
 boundary="----=_Part_1772_853952882.1474639897296"

------=_Part_1772_853952882.1474639897296
Content-Type: text/plain; charset=UTF-8



On Friday, September 23, 2016 at 4:05:40 PM UTC+2, Ville Voutilainen wrote:
>
> On 23 September 2016 at 16:57, Daniel Frey <d.f...@gmx.de <javascript:>>
> wrote:
> >> I'm not the Committee but I like the idea a lot.  It seems very easy to
> >> implement and doesn't hurt anybody who doesn't like it.
> >
> > It does hurt. A lot. I try to write code that compiles with -Wall,
> -Wextra, -Werror, but with each new compiler generation it becomes more
> difficult. Code that was
>
> I don't believe it's feasible for a C++ implementation to enable the
> warning we're talking about by default.
>

Could you explain? I'm not suggesting to warn for implicit conversion at
the point of call, but only inside the class definition.

--
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/576f2c8e-594d-429a-a993-8ae0a9ce3048%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, September 23, 2016 at 4:05:40 PM UTC+2,=
 Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 23=
 September 2016 at 16:57, Daniel Frey &lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"Uyw9BpVkAAAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">d.f...@gmx.de</a>&gt; wrote:
<br>&gt;&gt; I&#39;m not the Committee but I like the idea a lot. =C2=A0It =
seems very easy to
<br>&gt;&gt; implement and doesn&#39;t hurt anybody who doesn&#39;t like it=
..
<br>&gt;
<br>&gt; It does hurt. A lot. I try to write code that compiles with -Wall,=
 -Wextra, -Werror, but with each new compiler generation it becomes more di=
fficult. Code that was
<br>
<br>I don&#39;t believe it&#39;s feasible for a C++ implementation to enabl=
e the
<br>warning we&#39;re talking about by default.
<br></blockquote><div><br></div><div>Could you explain? I&#39;m not suggest=
ing to warn for implicit conversion at the point of call, but only inside t=
he class definition. =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/576f2c8e-594d-429a-a993-8ae0a9ce3048%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/576f2c8e-594d-429a-a993-8ae0a9ce3048=
%40isocpp.org</a>.<br />

------=_Part_1772_853952882.1474639897296--

------=_Part_1771_914819294.1474639897296--

.

On 23 September 2016 at 17:11,  <rhalbersma@gmail.com> wrote:
>
>
> On Friday, September 23, 2016 at 4:05:40 PM UTC+2, Ville Voutilainen wrote:
>>
>> On 23 September 2016 at 16:57, Daniel Frey <d.f...@gmx.de> wrote:
>> >> I'm not the Committee but I like the idea a lot.  It seems very easy to
>> >> implement and doesn't hurt anybody who doesn't like it.
>> >
>> > It does hurt. A lot. I try to write code that compiles with -Wall,
>> > -Wextra, -Werror, but with each new compiler generation it becomes more
>> > difficult. Code that was
>>
>> I don't believe it's feasible for a C++ implementation to enable the
>> warning we're talking about by default.
>
>
> Could you explain? I'm not suggesting to warn for implicit conversion at the
> point of call, but only inside the class definition.


I expect that there's a fair amount of non-annotated code that has
such implicit conversion
constructors in it, not to mention implicit conversion operators.

--
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/CAFk2RUamOhfbCV-v26giiM6Fn%2B5q_vAFqbiqo8Q9RTCiGfyUSQ%40mail.gmail.com.

.

Ville Voutilainen <ville.voutilainen@gmail.com> writes:

> On 23 September 2016 at 16:57, Daniel Frey <d.frey@gmx.de> wrote:
>>> I'm not the Committee but I like the idea a lot.  It seems very easy
>>> to implement and doesn't hurt anybody who doesn't like it.
>>
>> It does hurt. A lot. I try to write code that compiles with -Wall,
>> -Wextra, -Werror, but with each new compiler generation it becomes
>> more difficult. Code that was
>
> I don't believe it's feasible for a C++ implementation to enable the
> warning we're talking about by default.

Yes, it definitely shouldn't be enabled by default.  At most, `-Wextra`
could enable it.

But I believe that the code cluttering argument is somewhat reverse.  We
shouldn't write code we dislike just to silence warnings but enable
those warnings that flag deviations from the coding standards we
consider good.  Naturally, people have different ideas about good coding
standards and thus compilers offer different warnings we can select or
not select.  If compilers can only warn about things everybody hates,
that would be sad.

The one exception to this is if your code triggers warnings in other
people's code.  But several people have already commented how this point
from my previous message is kinda moot.

--
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/87wpi28zei.fsf%40gmail.com.

.

--94eb2c12fa5c85772f053d2d9946
Content-Type: text/plain; charset=UTF-8

On Fri, Sep 23, 2016 at 4:24 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 23 September 2016 at 17:11,  <rhalbersma@gmail.com> wrote:
>
> >>
> >> I don't believe it's feasible for a C++ implementation to enable the
> >> warning we're talking about by default.
> >
> >
> > Could you explain? I'm not suggesting to warn for implicit conversion at
> the
> > point of call, but only inside the class definition.
>
> I expect that there's a fair amount of non-annotated code that has
> such implicit conversion
> constructors in it, not to mention implicit conversion operators.
>

OK, so it might be too much work to fix, not too hard to warn. Yet it is
what the Core Guidelines recommend. It seems to me a small fix that
clang-tidy or similar tools could easily automate.

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Sep 23, 2016 at 4:24 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>O=
n 23 September 2016 at 17:11,=C2=A0 &lt;<a href=3D"mailto:rhalbersma@gmail.=
com" target=3D"_blank">rhalbersma@gmail.com</a>&gt; wrote:<br><br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t believe it&#39;s feasible for a C++ implementation to =
enable the<br>
&gt;&gt; warning we&#39;re talking about by default.<br>
&gt;<br>
&gt;<br>
&gt; Could you explain? I&#39;m not suggesting to warn for implicit convers=
ion at the<br>
&gt; point of call, but only inside the class definition.<br><br>
</span>I expect that there&#39;s a fair amount of non-annotated code that h=
as<br>
such implicit conversion<br>
constructors in it, not to mention implicit conversion operators.<br></bloc=
kquote><div><br></div><div>OK, so it might be too much work to fix, not too=
 hard to warn. Yet it is what the Core Guidelines recommend. It seems to me=
 a small fix that clang-tidy or similar tools could easily automate.</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/CAGBGO5Xmp9Hb0hVMUdSUkuHWqyegJxuOhO6P=
fdg0MJjaVQ0%2BEg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5Xmp9Hb0h=
VMUdSUkuHWqyegJxuOhO6Pfdg0MJjaVQ0%2BEg%40mail.gmail.com</a>.<br />

--94eb2c12fa5c85772f053d2d9946--

.

On 23 September 2016 at 17:29, Rein Halbersma <rhalbersma@gmail.com> wrote:
>> I expect that there's a fair amount of non-annotated code that has
>> such implicit conversion
>> constructors in it, not to mention implicit conversion operators.
>
>
> OK, so it might be too much work to fix, not too hard to warn. Yet it is
> what the Core Guidelines recommend. It seems to me a small fix that
> clang-tidy or similar tools could easily automate.


Warning about valid code isn't particularly hard. Avoiding false
positives is some magnitudes
harder.

--
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/CAFk2RUbmUw6zM7nF7UWufq1auYaoYDs0tBpy9orfksdtAd7XnA%40mail.gmail.com.

.

------=_Part_60_1029005773.1474977800123
Content-Type: multipart/alternative;
 boundary="----=_Part_61_1861294640.1474977800123"

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



W dniu pi=C4=85tek, 23 wrze=C5=9Bnia 2016 15:57:05 UTC+2 u=C5=BCytkownik Da=
niel Frey=20
napisa=C5=82:
>
> > On 23 Sep 2016, at 14:15, Moritz Klammler <moritz....@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> > rhalb...@gmail.com <javascript:> writes:=20
> >=20
> >> The Facebook program verifier flint=20
> >> (
> https://code.facebook.com/posts/729709347050548/under-the-hood-building-a=
nd-open-sourcing-flint/)=20
>
> >> encourages that non-explicit single-argument constructors and=20
> >> conversion operators should be marked with /* implicit */ comments=20
> >> (rules 14 and 22).=20
> >>=20
> >> I wonder if there would be Committee support for a proposal for an=20
> >> [[implicit]] attribute. Compilers could be encouraged to warn about=20
> >> missing attribute on non-explicit single argument constructors and=20
> >> conversion operators without such an attribute annotation. Neither gcc=
=20
> >> nor clang appear to have warnings for this at the moment.=20
> >=20
> > I'm not the Committee but I like the idea a lot.  It seems very easy to=
=20
> > implement and doesn't hurt anybody who doesn't like it.=20
>
> It does hurt. A lot. I try to write code that compiles with -Wall,=20
> -Wextra, -Werror, but with each new compiler generation it becomes more=
=20
> difficult. Code that was clean and concise before is more and more=20
> cluttered with annotations or work-arounds just to get rid of the warning=
s.=20
> In one case, this even forced me to pull in another header and therefore=
=20
> slows down compile times. Also: How would you tell the compiler that this=
=20
> is a system header? In a portable, standardized way! Because I don't want=
=20
> to add another level of complexity to support different compilers.=20
> Switching of the warning locally is equally bad, each compiler has its ow=
n=20
> way and identification for a specific warning.=20
>
> If you want to use lint-tools, fine, but encouraging compiler writers to=
=20
> add (or even mandate) warnings needs a really good justification.=20
> [[fallthough]] I can understand, it helps to catch real bugs and it is us=
ed=20
> only as an exception. But a non-explicit single-argument ctor is quite=20
> common and often the right choice, so I would really like to use it witho=
ut=20
> any further fuss.=20
>

Apart from -Wall and -Wextra compilers like GCC offer other opt-in=20
warnings, that you would not use upon every compilation due to too many=20
false positives, but you could use them from time to time, or as=20
non-errors, to successively refactor or annotate the warned about code.

--=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/a5395bfd-ac53-420b-a138-3353624ee1aa%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 23 wrze=C5=9Bnia 2016 15:57:05=
 UTC+2 u=C5=BCytkownik Daniel Frey napisa=C5=82:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">&gt; On 23 Sep 2016, at 14:15, Moritz Klammler &lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"eZdfDh1kAAAJ" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">moritz....@=
gmail.com</a>&gt; wrote:
<br>&gt;=20
<br>&gt; <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"eZdfDh1kAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">rhalb...@gmail.com</a> writes:
<br>&gt;=20
<br>&gt;&gt; The Facebook program verifier flint
<br>&gt;&gt; (<a href=3D"https://code.facebook.com/posts/729709347050548/un=
der-the-hood-building-and-open-sourcing-flint/" target=3D"_blank" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhtt=
ps%3A%2F%2Fcode.facebook.com%2Fposts%2F729709347050548%2Funder-the-hood-bui=
lding-and-open-sourcing-flint%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH0=
dlQs1flKklDkqHd505Pj0knkEg&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttps://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.facebook.com%2Fposts%2F72=
9709347050548%2Funder-the-hood-building-and-open-sourcing-flint%2F\x26sa\x3=
dD\x26sntz\x3d1\x26usg\x3dAFQjCNH0dlQs1flKklDkqHd505Pj0knkEg&#39;;return tr=
ue;">https://code.facebook.com/<wbr>posts/729709347050548/under-<wbr>the-ho=
od-building-and-open-<wbr>sourcing-flint/</a>)
<br>&gt;&gt; encourages that non-explicit single-argument constructors and
<br>&gt;&gt; conversion operators should be marked with /* implicit */ comm=
ents
<br>&gt;&gt; (rules 14 and 22).
<br>&gt;&gt;=20
<br>&gt;&gt; I wonder if there would be Committee support for a proposal fo=
r an
<br>&gt;&gt; [[implicit]] attribute. Compilers could be encouraged to warn =
about
<br>&gt;&gt; missing attribute on non-explicit single argument constructors=
 and
<br>&gt;&gt; conversion operators without such an attribute annotation. Nei=
ther gcc
<br>&gt;&gt; nor clang appear to have warnings for this at the moment.
<br>&gt;=20
<br>&gt; I&#39;m not the Committee but I like the idea a lot. =C2=A0It seem=
s very easy to
<br>&gt; implement and doesn&#39;t hurt anybody who doesn&#39;t like it.
<br>
<br>It does hurt. A lot. I try to write code that compiles with -Wall, -Wex=
tra, -Werror, but with each new compiler generation it becomes more difficu=
lt. Code that was clean and concise before is more and more cluttered with =
annotations or work-arounds just to get rid of the warnings. In one case, t=
his even forced me to pull in another header and therefore slows down compi=
le times. Also: How would you tell the compiler that this is a system heade=
r? In a portable, standardized way! Because I don&#39;t want to add another=
 level of complexity to support different compilers. Switching of the warni=
ng locally is equally bad, each compiler has its own way and identification=
 for a specific warning.
<br>
<br>If you want to use lint-tools, fine, but encouraging compiler writers t=
o add (or even mandate) warnings needs a really good justification. [[fallt=
hough]] I can understand, it helps to catch real bugs and it is used only a=
s an exception. But a non-explicit single-argument ctor is quite common and=
 often the right choice, so I would really like to use it without any furth=
er fuss.
<br></blockquote><div><br>Apart from -Wall and -Wextra compilers like GCC o=
ffer other opt-in warnings, that you would not use upon every compilation d=
ue to too many false positives, but you could use them from time to time, o=
r as non-errors, to successively refactor or annotate the warned about code=
..<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/a5395bfd-ac53-420b-a138-3353624ee1aa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a5395bfd-ac53-420b-a138-3353624ee1aa=
%40isocpp.org</a>.<br />

------=_Part_61_1861294640.1474977800123--

------=_Part_60_1029005773.1474977800123--

.

------=_Part_385_1951981113.1474977939637
Content-Type: multipart/alternative;
 boundary="----=_Part_386_1608723751.1474977939637"

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



W dniu pi=C4=85tek, 23 wrze=C5=9Bnia 2016 08:44:07 UTC+2 u=C5=BCytkownik=20
rhalb...@gmail.com napisa=C5=82:
>
> The Facebook program verifier flint (
> https://code.facebook.com/posts/729709347050548/under-the-hood-building-a=
nd-open-sourcing-flint/)=20
> encourages that non-explicit single-argument constructors and conversion=
=20
> operators should be marked with /* implicit */ comments (rules 14 and 22)=
..=20
>
> I wonder if there would be Committee support for a proposal for an=20
> [[implicit]] attribute. Compilers could be encouraged to warn about missi=
ng=20
> attribute on non-explicit single argument constructors and conversion=20
> operators without such an attribute annotation. Neither gcc nor clang=20
> appear to have warnings for this at the moment.
>

See this GCC feature request:=20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D77741=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3baee5cf-6aec-4cd8-bd48-7e2861795192%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu pi=C4=85tek, 23 wrze=C5=9Bnia 2016 08:44:07=
 UTC+2 u=C5=BCytkownik rhalb...@gmail.com napisa=C5=82:<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">The Facebook program verifier=C2=
=A0flint=C2=A0(<a href=3D"https://code.facebook.com/posts/729709347050548/u=
nder-the-hood-building-and-open-sourcing-flint/" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dht=
tps%3A%2F%2Fcode.facebook.com%2Fposts%2F729709347050548%2Funder-the-hood-bu=
ilding-and-open-sourcing-flint%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
0dlQs1flKklDkqHd505Pj0knkEg&#39;;return true;" onclick=3D"this.href=3D&#39;=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.facebook.com%2Fposts%2F7=
29709347050548%2Funder-the-hood-building-and-open-sourcing-flint%2F\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH0dlQs1flKklDkqHd505Pj0knkEg&#39;;return t=
rue;">https://code.<wbr>facebook.com/posts/<wbr>729709347050548/under-the-<=
wbr>hood-building-and-open-<wbr>sourcing-flint/</a>) encourages that non-ex=
plicit single-argument constructors and conversion operators should be mark=
ed with /* implicit */ comments (rules 14 and 22).=C2=A0<div><br></div><div=
>I wonder if there would be Committee support for a proposal for an [[impli=
cit]] attribute. Compilers could be encouraged to warn about missing attrib=
ute on non-explicit single argument constructors and conversion operators w=
ithout such an attribute annotation. Neither gcc nor clang appear to have w=
arnings for this at the moment.</div></div></blockquote><div><br>See this G=
CC feature request: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D77741 <b=
r></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/3baee5cf-6aec-4cd8-bd48-7e2861795192%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3baee5cf-6aec-4cd8-bd48-7e2861795192=
%40isocpp.org</a>.<br />

------=_Part_386_1608723751.1474977939637--

------=_Part_385_1951981113.1474977939637--

.

------=_Part_4257_477160942.1475038587961
Content-Type: text/plain; charset=UTF-8

Wouldn't it be better to depricate the explicit keyword in favor of having it by default? That is, replace "explicit" with "implicit".

--
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/5cd862e0-d9a8-42bb-96d7-3cf99656f424%40isocpp.org.

------=_Part_4257_477160942.1475038587961--

.

------=_Part_1129_1467865774.1475038586955
Content-Type: text/plain; charset=UTF-8

Wouldn't it be better to depricate the explicit keyword in favor of having it by default? That is, replace "explicit" with "implicit".

--
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/9be295ef-a62f-457e-a00b-2736cbac27a3%40isocpp.org.

------=_Part_1129_1467865774.1475038586955--

.

------=_Part_199_60463884.1475071212955
Content-Type: multipart/alternative;
 boundary="----=_Part_200_1027033988.1475071212955"

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

On Wednesday, September 28, 2016 at 12:56:27 AM UTC-4, Jens =C3=85kerblom w=
rote:
>
> Wouldn't it be better to depricate the explicit keyword in favor of havin=
g=20
> it by default? That is, replace "explicit" with "implicit".


That would require an additional keyword as well as break lots and lots of=
=20
code.

--=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/769bf2c6-276a-4657-9c30-fdf8b41c98eb%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, September 28, 2016 at 12:56:27 AM UTC-4, Jen=
s =C3=85kerblom wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Wouldn&#=
39;t it be better to depricate the explicit keyword in favor of having it b=
y default? That is, replace &quot;explicit&quot; with &quot;implicit&quot;.=
</blockquote><div><br>That would require an additional keyword as well as b=
reak lots and lots of code.<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/769bf2c6-276a-4657-9c30-fdf8b41c98eb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/769bf2c6-276a-4657-9c30-fdf8b41c98eb=
%40isocpp.org</a>.<br />

------=_Part_200_1027033988.1475071212955--

------=_Part_199_60463884.1475071212955--

.

That is a 20+ year process:

1. Introduce implicit. Compilers can have optional warning on naked constru=
ctors=C2=A0
2. After N =C2=A0years, compilers warn by default=C2=A0
3. Deprecate naked constructors
4. Error on naked constructors=C2=A0
5. Make explicit the default
6. Deprecate explicit
7. Remove explicit

You could add
0. [[implicit]]

Which is a sensible place to start, since it is just for compiler warnings,=
 and doesn't change valid code.=C2=A0


Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi=
ce
=C2=A0 Original Message =C2=A0
From: Jens =C3=85kerblom
Sent: Wednesday, September 28, 2016 12:56 AM
To: ISO C++ Standard - Future Proposals
Reply To: std-proposals@isocpp.org
Subject: [std-proposals] [[implicit]] attribute

Wouldn't it be better to depricate the explicit keyword in favor of having =
it by default? That is, replace "explicit" with "implicit".

--=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/5cd862e0-d9a8-42bb-96d7-3cf99656f424%40isocpp.or=
g.

--=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/20160928140550.4919374.10911.17563%40gmail.com.

.

I have no interest in 0), unless we plan for the 20+ year process.

Adding an attribute to raise warnings essentially forces a keyword on
all constructors, whether implicit or explicit, adding burden on all users
of the language.

However, I am the mad man who might be interested in 20 year
projects, so you may persuade me yet ;)

AlisdairM

> On Sep 28, 2016, at 10:05 AM, Tony V E <tvaneerd@gmail.com> wrote:
>=20
> That is a 20+ year process:
>=20
> 1. Introduce implicit. Compilers can have optional warning on naked const=
ructors=20
> 2. After N  years, compilers warn by default=20
> 3. Deprecate naked constructors
> 4. Error on naked constructors=20
> 5. Make explicit the default
> 6. Deprecate explicit
> 7. Remove explicit
>=20
> You could add
> 0. [[implicit]]
>=20
> Which is a sensible place to start, since it is just for compiler warning=
s, and doesn't change valid code.=20
>=20
>=20
> Sent from my BlackBerry portable Babbage Device
>   Original Message =20
> From: Jens =C3=85kerblom
> Sent: Wednesday, September 28, 2016 12:56 AM
> To: ISO C++ Standard - Future Proposals
> Reply To: std-proposals@isocpp.org
> Subject: [std-proposals] [[implicit]] attribute
>=20
> Wouldn't it be better to depricate the explicit keyword in favor of havin=
g it by default? That is, replace "explicit" with "implicit".
>=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=
 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/isoc=
pp.org/d/msgid/std-proposals/5cd862e0-d9a8-42bb-96d7-3cf99656f424%40isocpp.=
org.
>=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=
 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/isoc=
pp.org/d/msgid/std-proposals/20160928140550.4919374.10911.17563%40gmail.com=
..

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

.

------=_Part_329_230887516.1475073958384
Content-Type: multipart/alternative;
 boundary="----=_Part_330_355265157.1475073958384"

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



W dniu =C5=9Broda, 28 wrze=C5=9Bnia 2016 16:09:38 UTC+2 u=C5=BCytkownik Ali=
sdair Meredith=20
napisa=C5=82:
>
> I have no interest in 0), unless we plan for the 20+ year process.=20
>
> Adding an attribute to raise warnings essentially forces a keyword on=20
> all constructors, whether implicit or explicit, adding burden on all user=
s=20
> of the language.


Not that much burden: if you are now forced to mark your constructor as=20
explicit: it is a bug fix: it was supposed to be explicit long ago.
If you are forced to mark the constructor [[implicit]]: this does not=20
happen very often: how often do you consciously implement an intended=20
conversion?
 =20

>
>
> However, I am the mad man who might be interested in 20 year=20
> projects, so you may persuade me yet ;)=20
>
> AlisdairM=20
>
> > On Sep 28, 2016, at 10:05 AM, Tony V E <tvan...@gmail.com <javascript:>=
>=20
> wrote:=20
> >=20
> > That is a 20+ year process:=20
> >=20
> > 1. Introduce implicit. Compilers can have optional warning on naked=20
> constructors=20
> > 2. After N  years, compilers warn by default=20
> > 3. Deprecate naked constructors=20
> > 4. Error on naked constructors=20
> > 5. Make explicit the default=20
> > 6. Deprecate explicit=20
> > 7. Remove explicit=20
> >=20
> > You could add=20
> > 0. [[implicit]]=20
> >=20
> > Which is a sensible place to start, since it is just for compiler=20
> warnings, and doesn't change valid code.=20
> >=20
> >=20
> > Sent from my BlackBerry portable Babbage Device=20
> >   Original Message  =20
> > From: Jens =C3=85kerblom=20
> > Sent: Wednesday, September 28, 2016 12:56 AM=20
> > To: ISO C++ Standard - Future Proposals=20
> > Reply To: std-pr...@isocpp.org <javascript:>=20
> > Subject: [std-proposals] [[implicit]] attribute=20
> >=20
> > Wouldn't it be better to depricate the explicit keyword in favor of=20
> having it by default? That is, replace "explicit" with "implicit".=20
> >=20
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5cd862e0-d9a=
8-42bb-96d7-3cf99656f424%40isocpp.org.=20
>
> >=20
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/201609281405=
50.4919374.10911.17563%40gmail.com.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/58c1012c-696c-4fed-840e-324e38b1de82%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 28 wrze=C5=9Bnia 2016 16:09:38 =
UTC+2 u=C5=BCytkownik Alisdair Meredith napisa=C5=82:<blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">I have no interest in 0), unless we plan for the 20+=
 year process.
<br>
<br>Adding an attribute to raise warnings essentially forces a keyword on
<br>all constructors, whether implicit or explicit, adding burden on all us=
ers
<br>of the language.</blockquote><div><br>Not that much burden: if you are =
now forced to mark your constructor as explicit: it is a bug fix: it was su=
pposed to be explicit long ago.<br>If you are forced to mark the constructo=
r [[implicit]]: this does not happen very often: how often do you conscious=
ly implement an intended conversion?<br>=C2=A0 <br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>
<br>However, I am the mad man who might be interested in 20 year
<br>projects, so you may persuade me yet ;)
<br>
<br>AlisdairM
<br>
<br>&gt; On Sep 28, 2016, at 10:05 AM, Tony V E &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"GDSx5oNSBQAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">tvan...@gmail.com</a>&gt; wr=
ote:
<br>&gt;=20
<br>&gt; That is a 20+ year process:
<br>&gt;=20
<br>&gt; 1. Introduce implicit. Compilers can have optional warning on nake=
d constructors=20
<br>&gt; 2. After N =C2=A0years, compilers warn by default=20
<br>&gt; 3. Deprecate naked constructors
<br>&gt; 4. Error on naked constructors=20
<br>&gt; 5. Make explicit the default
<br>&gt; 6. Deprecate explicit
<br>&gt; 7. Remove explicit
<br>&gt;=20
<br>&gt; You could add
<br>&gt; 0. [[implicit]]
<br>&gt;=20
<br>&gt; Which is a sensible place to start, since it is just for compiler =
warnings, and doesn&#39;t change valid code.=20
<br>&gt;=20
<br>&gt;=20
<br>&gt; Sent from my BlackBerry portable Babbage Device
<br>&gt; =C2=A0 Original Message =C2=A0
<br>&gt; From: Jens =C3=85kerblom
<br>&gt; Sent: Wednesday, September 28, 2016 12:56 AM
<br>&gt; To: ISO C++ Standard - Future Proposals
<br>&gt; Reply To: <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"GDSx5oNSBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">std-pr...@isocpp.org</a>
<br>&gt; Subject: [std-proposals] [[implicit]] attribute
<br>&gt;=20
<br>&gt; Wouldn&#39;t it be better to depricate the explicit keyword in fav=
or of having it by default? That is, replace &quot;explicit&quot; with &quo=
t;implicit&quot;.
<br>&gt;=20
<br>&gt; --=20
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"GDSx5oNSBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"GDSx5oNSBQAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt; To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/5cd862e0-d9a8-42bb-96d7-3cf9=
9656f424%40isocpp.org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/5cd862e0-d9a8-42bb-96d7-3cf99656f424%40isocpp.org&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/5cd862e0-d9a8-42bb-96d7-3cf99656f424%40isocpp.org&#39;;return true=
;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5=
cd862e0-d9a8-42bb-<wbr>96d7-3cf99656f424%40isocpp.org</a><wbr>.
<br>&gt;=20
<br>&gt; --=20
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"GDSx5oNSBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"GDSx5oNSBQAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt; To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/20160928140550.4919374.10911=
..17563%40gmail.com" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20=
160928140550.4919374.10911.17563%40gmail.com&#39;;return true;" onclick=3D"=
this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/20160928140550.4919374.10911.17563%40gmail.com&#39;;return true;">https:=
//groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/2016092814=
0550.<wbr>4919374.10911.17563%40gmail.<wbr>com</a>.
<br>
<br></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/58c1012c-696c-4fed-840e-324e38b1de82%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58c1012c-696c-4fed-840e-324e38b1de82=
%40isocpp.org</a>.<br />

------=_Part_330_355265157.1475073958384--

------=_Part_329_230887516.1475073958384--

.

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

On Wed, Sep 28, 2016 at 9:09 AM, Alisdair Meredith <alisdairm@me.com> wrote:

> I have no interest in 0), unless we plan for the 20+ year process.
>
> Adding an attribute to raise warnings essentially forces a keyword on
> all constructors, whether implicit or explicit, adding burden on all users
> of the language.
>

+1 to both of these.

And personally, I've found making copy constructors explicit to just be
troublesome (and I've never experimented with making move constructors
explicit because of that), but I assume the people wanting this feature
have the opposite experience, or they would have mentioned this, given that
copy constructors are the most popular non-explicit single argument
constructors.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BOq%2BKT6%2BL5ROXNz-cLbBfHMDMwgwwL2wQSf39U8XQ0Zgg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On Wed, Sep 28, 2016 at 9:09 AM=
, Alisdair Meredith <span dir=3D"ltr">&lt;<a href=3D"mailto:alisdairm@me.co=
m" target=3D"_blank">alisdairm@me.com</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div id=3D":2ks" class=3D"a=
3s aXjCH m1577121242e2d774">I have no interest in 0), unless we plan for th=
e 20+ year process.<br>
<br>
Adding an attribute to raise warnings essentially forces a keyword on<br>
all constructors, whether implicit or explicit, adding burden on all users<=
br>
of the language.<br></div></blockquote></div><br>+1 to both of these.</div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">And persona=
lly, I&#39;ve found making copy constructors explicit to just be troublesom=
e (and I&#39;ve never experimented with making move constructors explicit b=
ecause of that), but I assume the people wanting this feature have the oppo=
site experience, or they would have mentioned this, given that copy constru=
ctors are the most popular non-explicit single argument constructors.<br>--=
 <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div=
 dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=
=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div></=
div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOq%2BKT6%2BL5ROXNz-cLbBfHMDM=
wgwwL2wQSf39U8XQ0Zgg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BOq=
%2BKT6%2BL5ROXNz-cLbBfHMDMwgwwL2wQSf39U8XQ0Zgg%40mail.gmail.com</a>.<br />

--001a11371fbcefe5ba053d94f499--

.

--047d7b66f34327419b053d95222d
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 28, 2016 at 7:46 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On Wed, Sep 28, 2016 at 9:09 AM, Alisdair Meredith <alisdairm@me.com>
> wrote:
>
>> I have no interest in 0), unless we plan for the 20+ year process.
>>
>> Adding an attribute to raise warnings essentially forces a keyword on
>> all constructors, whether implicit or explicit, adding burden on all users
>> of the language.
>>
>
> +1 to both of these.
>
> And personally, I've found making copy constructors explicit to just be
> troublesome (and I've never experimented with making move constructors
> explicit because of that), but I assume the people wanting this feature
> have the opposite experience, or they would have mentioned this, given that
> copy constructors are the most popular non-explicit single argument
> constructors.
>

I didn't mean to propose [[implicit]] to suppress warnings for copy/move
constructors, inherited constructors or even conversion to base classes.
Only for single argument constructors from / conversions to unrelated
types.

So. e.g. std::bitset has implicit constructors from unsigned long and
unsigned long long, they can be surprising (especially since the overloaded
bit-operators for std::bitset do not have such conversions on their
arguments).

--
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/CAGBGO5XA6CUihmCYvtcQ3M%3DG60mEWhbtQkyOiHr09WBVaXZ2Jw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Sep 28, 2016 at 7:46 PM, Nevin Liber <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><span class=3D"">On Wed, Sep 28, 2016 at 9:09 =
AM, Alisdair Meredith <span dir=3D"ltr">&lt;<a href=3D"mailto:alisdairm@me.=
com" target=3D"_blank">alisdairm@me.com</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div>I have no interest in =
0), unless we plan for the 20+ year process.<br>
<br>
Adding an attribute to raise warnings essentially forces a keyword on<br>
all constructors, whether implicit or explicit, adding burden on all users<=
br>
of the language.<br></div></blockquote></div><br></span>+1 to both of these=
..</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">And =
personally, I&#39;ve found making copy constructors explicit to just be tro=
ublesome (and I&#39;ve never experimented with making move constructors exp=
licit because of that), but I assume the people wanting this feature have t=
he opposite experience, or they would have mentioned this, given that copy =
constructors are the most popular non-explicit single argument constructors=
..<br></div></div></blockquote><div><br></div><div>I didn&#39;t mean to prop=
ose [[implicit]] to suppress warnings for copy/move constructors, inherited=
 constructors or even conversion to base classes. Only for single argument =
constructors from / conversions to unrelated types.=C2=A0</div><div><br></d=
iv><div>So. e.g. std::bitset has implicit constructors from unsigned long a=
nd unsigned long long, they can be surprising (especially since the overloa=
ded bit-operators for std::bitset do not have such conversions on their arg=
uments).</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/CAGBGO5XA6CUihmCYvtcQ3M%3DG60mEWhbtQk=
yOiHr09WBVaXZ2Jw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5XA6CUihm=
CYvtcQ3M%3DG60mEWhbtQkyOiHr09WBVaXZ2Jw%40mail.gmail.com</a>.<br />

--047d7b66f34327419b053d95222d--

.

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

On Wed, Sep 28, 2016 at 1:00 PM, Rein Halbersma <rhalbersma@gmail.com>
wrote:

>
> I didn't mean to propose [[implicit]] to suppress warnings for copy/move
> constructors, inherited constructors or even conversion to base classes.
>

Oh, you want a complicated rule.


> Only for single argument constructors from / conversions to unrelated
> types.
>

And what do you do about things like:

struct Foo {
    Foo(std::string s, int i = 0);

    template<typename... Ts>
    Foo(Ts&&...) { /* ... */ }
};

Do we get warnings for either of those?  Both of those?  Neither of those?

So. e.g. std::bitset has implicit constructors from unsigned long and
> unsigned long long, they can be surprising (especially since the overloaded
> bit-operators for std::bitset do not have such conversions on their
> arguments).
>

That may be (I don't know the original motivation and I'm not motivated
enough to do the archeology), but changing that has a non-zero chance of
breaking user code.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BNdkHcPaRm4nK13qJw8TMdmNuV_oHeoyid%3DGdR5Rawz9A%40mail.gmail.com.

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

<div dir=3D"ltr">On Wed, Sep 28, 2016 at 1:00 PM, Rein Halbersma <span dir=
=3D"ltr">&lt;<a href=3D"mailto:rhalbersma@gmail.com" target=3D"_blank">rhal=
bersma@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><d=
iv class=3D"gmail_extra">I didn&#39;t mean to propose [[implicit]] to suppr=
ess warnings for copy/move constructors, inherited constructors or even con=
version to base classes.</div></div></blockquote><div><br></div><div>Oh, yo=
u want a complicated rule.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"> Only for single argument =
constructors from / conversions to unrelated types.=C2=A0<br></div></div></=
blockquote><div><br></div><div>And what do you do about things like:</div><=
div><br></div><div>struct Foo {</div><div>=C2=A0 =C2=A0 Foo(std::string s, =
int i =3D 0);</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;typename..=
.. Ts&gt;</div><div>=C2=A0 =C2=A0 Foo(Ts&amp;&amp;...) { /* ... */ }</div><d=
iv>};</div><div><br></div><div>Do we get warnings for either of those?=C2=
=A0 Both of those?=C2=A0 Neither of those?</div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div>So. e.g. std::bitset has implicit constructors from u=
nsigned long and unsigned long long, they can be surprising (especially sin=
ce the overloaded bit-operators for std::bitset do not have such conversion=
s on their arguments).<br></div></div></div></div></blockquote><div><br></d=
iv><div>That may be (I don&#39;t know the original motivation and I&#39;m n=
ot motivated enough to do the archeology), but changing that has a non-zero=
 chance of breaking user code.</div></div>-- <br><div class=3D"gmail_signat=
ure" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"l=
tr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mail=
to:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
 =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNdkHcPaRm4nK13qJw8TMdmNuV_oH=
eoyid%3DGdR5Rawz9A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNdkH=
cPaRm4nK13qJw8TMdmNuV_oHeoyid%3DGdR5Rawz9A%40mail.gmail.com</a>.<br />

--001a113cf0a4872e8d053d95a0f6--

.

--089e010d86264361d0053d95da2b
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 28, 2016 at 8:34 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> Only for single argument constructors from / conversions to unrelated
>> types.
>>
>
> And what do you do about things like:
>
> struct Foo {
>     Foo(std::string s, int i = 0);
>
>     template<typename... Ts>
>     Foo(Ts&&...) { /* ... */ }
> };
>
> Do we get warnings for either of those?  Both of those?  Neither of those?
>

OK, fair enough, this is getting complicated.


> So. e.g. std::bitset has implicit constructors from unsigned long and
>> unsigned long long, they can be surprising (especially since the overloaded
>> bit-operators for std::bitset do not have such conversions on their
>> arguments).
>>
>
> That may be (I don't know the original motivation and I'm not motivated
> enough to do the archeology),
>

the proposals for std::bitset predate the introduction of the explicit
keyword...

--
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/CAGBGO5Xn3j93d-FA9uK4cGK1ahzCnuavUkh5SZ1S%2BOQMD-u8YA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Sep 28, 2016 at 8:34 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">Only for s=
ingle argument constructors from / conversions to unrelated types.=C2=A0<br=
></div></div></blockquote><div><br></div></span><div>And what do you do abo=
ut things like:</div><div><br></div><div>struct Foo {</div><div>=C2=A0 =C2=
=A0 Foo(std::string s, int i =3D 0);</div><div><br></div><div>=C2=A0 =C2=A0=
 template&lt;typename... Ts&gt;</div><div>=C2=A0 =C2=A0 Foo(Ts&amp;&amp;...=
) { /* ... */ }</div><div>};</div><div><br></div><div>Do we get warnings fo=
r either of those?=C2=A0 Both of those?=C2=A0 Neither of those?</div></div>=
</div></div></blockquote><div><br></div><div>OK, fair enough, this is getti=
ng complicated.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span clas=
s=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><div>So. e.g. std::bitset has implicit co=
nstructors from unsigned long and unsigned long long, they can be surprisin=
g (especially since the overloaded bit-operators for std::bitset do not hav=
e such conversions on their arguments).<br></div></div></div></div></blockq=
uote><div><br></div></span><div>That may be (I don&#39;t know the original =
motivation and I&#39;m not motivated enough to do the archeology),=C2=A0</d=
iv></div></div></div></blockquote><div><br></div><div>the proposals for std=
::bitset predate the introduction of the explicit keyword...</div></div></d=
iv></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/CAGBGO5Xn3j93d-FA9uK4cGK1ahzCnuavUkh5=
SZ1S%2BOQMD-u8YA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGBGO5Xn3j93d-=
FA9uK4cGK1ahzCnuavUkh5SZ1S%2BOQMD-u8YA%40mail.gmail.com</a>.<br />

--089e010d86264361d0053d95da2b--

.

------=_Part_1639_1431627968.1475089009146
Content-Type: multipart/alternative;
 boundary="----=_Part_1640_521403818.1475089009147"

------=_Part_1640_521403818.1475089009147
Content-Type: text/plain; charset=UTF-8

On Wednesday, September 28, 2016 at 2:35:37 PM UTC-4, Nevin ":-)" Liber
wrote:
>
> On Wed, Sep 28, 2016 at 1:00 PM, Rein Halbersma <rhalb...@gmail.com
> <javascript:>> wrote:
>
>>
>> I didn't mean to propose [[implicit]] to suppress warnings for copy/move
>> constructors, inherited constructors or even conversion to base classes.
>>
>
> Oh, you want a complicated rule.
>

No, it would be a simple rule. It's any constructor which would be used for
implicit conversion operations, in accord with [over.best.ics]. Well, minus
[over.match.list] (list initialization), of course.

Copy/move constructors don't apply, since they are only invoked on the
actual type T. And I don't believe that inherited constructors apply either.


>
>> Only for single argument constructors from / conversions to unrelated
>> types.
>>
>
> And what do you do about things like:
>
> struct Foo {
>     Foo(std::string s, int i = 0);
>
>     template<typename... Ts>
>     Foo(Ts&&...) { /* ... */ }
> };
>
> Do we get warnings for either of those?  Both of those?  Neither of those?
>

The point of the warning is to that, if a constructor can be used by an
implicit conversion sequence, then you must explicitly mark it as such.
Since both of those constructors can be used for implicit conversion
sequences under [over.best.ics], then yes, they both get warnings.

That being said, perhaps the warning could be issued due to the *use* of
such a conversion sequence, rather than the mere existence of a constructor
that could be used with it.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c10bb766-1f02-4b27-a619-d5c1aab032d1%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, September 28, 2016 at 2:35:37 PM UTC-4, Nevi=
n &quot;:-)&quot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">On Wed, Sep 28, 2016 at 1:00 PM, Rein Halbersma <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"ZI9dmQdhBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">rhalb...@gmail.com</a>&gt;</span> wrote:<br><div><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>I didn&#3=
9;t mean to propose [[implicit]] to suppress warnings for copy/move constru=
ctors, inherited constructors or even conversion to base classes.</div></di=
v></blockquote><div><br></div><div>Oh, you want a complicated rule.</div></=
div></div></div></blockquote><div><br>No, it would be a simple rule. It&#39=
;s any constructor which would be used for implicit conversion operations, =
in accord with [over.best.ics]. Well, minus [over.match.list] (list initial=
ization), of course.<br><br>Copy/move constructors don&#39;t apply, since t=
hey are only invoked on the actual type T. And I don&#39;t believe that inh=
erited constructors apply either.<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div> Only for sin=
gle argument constructors from / conversions to unrelated types.=C2=A0<br><=
/div></div></blockquote><div><br></div><div>And what do you do about things=
 like:</div><div><br></div><div>struct Foo {</div><div>=C2=A0 =C2=A0 Foo(st=
d::string s, int i =3D 0);</div><div><br></div><div>=C2=A0 =C2=A0 template&=
lt;typename... Ts&gt;</div><div>=C2=A0 =C2=A0 Foo(Ts&amp;&amp;...) { /* ...=
 */ }</div><div>};</div><div><br></div><div>Do we get warnings for either o=
f those?=C2=A0 Both of those?=C2=A0 Neither of those?</div></div></div></di=
v></blockquote><div><br>The point of the warning is to that, if a construct=
or can be used by an implicit conversion sequence, then you must explicitly=
 mark it as such. Since both of those constructors can be used for implicit=
 conversion sequences under [over.best.ics], then yes, they both get warnin=
gs.<br><br>That being said, perhaps the warning could be issued due to the =
<i>use</i> of such a conversion sequence, rather than the mere existence of=
 a constructor that could be used with it.<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/c10bb766-1f02-4b27-a619-d5c1aab032d1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c10bb766-1f02-4b27-a619-d5c1aab032d1=
%40isocpp.org</a>.<br />

------=_Part_1640_521403818.1475089009147--

------=_Part_1639_1431627968.1475089009146--

.

On Wed, Sep 28, 2016 at 11:56 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, September 28, 2016 at 2:35:37 PM UTC-4, Nevin ":-)" Liber
> wrote:
>>
>> On Wed, Sep 28, 2016 at 1:00 PM, Rein Halbersma <rhalb...@gmail.com>
>> wrote:
>>>
>>>
>>> I didn't mean to propose [[implicit]] to suppress warnings for copy/move
>>> constructors, inherited constructors or even conversion to base classes.
>>
>>
>> Oh, you want a complicated rule.
>
>
> No, it would be a simple rule. It's any constructor which would be used for
> implicit conversion operations, in accord with [over.best.ics]. Well, minus
> [over.match.list] (list initialization), of course.
>
> Copy/move constructors don't apply, since they are only invoked on the
> actual type T. And I don't believe that inherited constructors apply either.

+1, with the caveat that I haven't checked the actual section references.

>>> Only for single argument constructors from / conversions to unrelated
>>> types.
>>
>>
>> And what do you do about things like:
>>
>> struct Foo {
>>     Foo(std::string s, int i = 0);
>>
>>     template<typename... Ts>
>>     Foo(Ts&&...) { /* ... */ }
>> };
>>
>> Do we get warnings for either of those?  Both of those?  Neither of those?
>
>
> The point of the warning is to that, if a constructor can be used by an
> implicit conversion sequence, then you must explicitly mark it as such.
> Since both of those constructors can be used for implicit conversion
> sequences under [over.best.ics], then yes, they both get warnings.
>
> That being said, perhaps the warning could be issued due to the use of such
> a conversion sequence, rather than the mere existence of a constructor that
> could be used with it.

FWIW, I'd rather warn about a class definition based on rules that can
be applied to the definition itself. Warning about a missing
`implicit` marker based on uses is likely to produce a bunch of
warnings that the warn-ee can't fix in their own code.

Jeffrey

--
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/CANh-dXkAuzxYqxOS3wDdmh-jizpnskCvXP%2Byer%3D2kVVEyAUfrw%40mail.gmail.com.

.

------=_Part_151_555223993.1475128485384
Content-Type: multipart/alternative;
 boundary="----=_Part_152_1815436103.1475128485384"

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



W dniu =C5=9Broda, 28 wrze=C5=9Bnia 2016 19:47:38 UTC+2 u=C5=BCytkownik Nev=
in ":-)" Liber=20
napisa=C5=82:
>
> On Wed, Sep 28, 2016 at 9:09 AM, Alisdair Meredith <alis...@me.com=20
> <javascript:>> wrote:
>
>> I have no interest in 0), unless we plan for the 20+ year process.
>>
>> Adding an attribute to raise warnings essentially forces a keyword on
>> all constructors, whether implicit or explicit, adding burden on all use=
rs
>> of the language.
>>
>
We are not comparing "mark only converting" to "mark every one", but "mark=
=20
only explicit" to "mark every one". The current one, "mark only explicit"=
=20
is bug-prone. So, we are really comparing "bug-prone" to "bug-safe", even=
=20
though at the expense of certain burden.


> +1 to both of these.
>
> And personally, I've found making copy constructors explicit to just be=
=20
> troublesome (and I've never experimented with making move constructors=20
> explicit because of that), but I assume the people wanting this feature=
=20
> have the opposite experience, or they would have mentioned this, given th=
at=20
> copy constructors are the most popular non-explicit single argument=20
> constructors.
>

The rule for warning generation would probably be: Warn when:


   1. A constructor that could in C++ be used in conversions=20
   (single-argument or one where a second argument has a default value) tha=
t=20
   is not a copy or move constructor declared without attribute [[implicit]=
].
   2. An explicit constructor declared with attribute [[implicit]].
  =20
Given your example:

Foo::Foo(std::string s, int i =3D 0);

It is potentially converting -- will trigger a warning

 template<typename... Ts>
 Foo::Foo(Ts&&...) { /* ... */ }

Is potentially buggy. Do you really want to construct from about=20
*everything*? Such constructors are known to have caused bugs:=20
http://ericniebler.com/2013/08/07/universal-references-and-the-copy-constru=
cto/
They "compete" with copy/move constructors, if not anything else.=20
Nonetheless, it is potentially converting -- will trigger a warning

We are talking about warnings: programmers will surely be allowed to turn=
=20
them off, when they feel uncomfortable.

 Regards,
&rzej
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4fa60d1d-389a-462f-a79f-43e58aec016d%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 28 wrze=C5=9Bnia 2016 19:47:38 =
UTC+2 u=C5=BCytkownik Nevin &quot;:-)&quot; Liber napisa=C5=82:<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>On Wed, Sep 28, 2016=
 at 9:09 AM, Alisdair Meredith <span dir=3D"ltr">&lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"OKNYXmleBQAJ" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">alis...@me.com</a>&gt;</spa=
n> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
>I have no interest in 0), unless we plan for the 20+ year process.<br>
<br>
Adding an attribute to raise warnings essentially forces a keyword on<br>
all constructors, whether implicit or explicit, adding burden on all users<=
br>
of the language.<br></div></blockquote></div></div></div></blockquote><div>=
<br>We are not comparing &quot;mark only converting&quot; to &quot;mark eve=
ry one&quot;, but &quot;mark only explicit&quot; to &quot;mark every one&qu=
ot;. The current one, &quot;mark only explicit&quot; is bug-prone. So, we a=
re really comparing &quot;bug-prone&quot; to &quot;bug-safe&quot;, even tho=
ugh at the expense of certain burden.<br><br></div><blockquote class=3D"gma=
il_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"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div></div></blockquote></div><br>+1 to both of t=
hese.</div><div><br></div><div>And personally, I&#39;ve found making copy c=
onstructors explicit to just be troublesome (and I&#39;ve never experimente=
d with making move constructors explicit because of that), but I assume the=
 people wanting this feature have the opposite experience, or they would ha=
ve mentioned this, given that copy constructors are the most popular non-ex=
plicit single argument constructors.<br></div></div></blockquote><div><br>T=
he rule for warning generation would probably be: Warn when:<br><br><ol><li=
>A constructor that could in C++ be used in conversions (single-argument or=
 one where a second argument has a default value) that is not a copy or mov=
e constructor declared without attribute [[implicit]].</li><li>An explicit =
constructor declared with attribute [[implicit]].<br></li></ol>Given your e=
xample:<br><br><div><div style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; over=
flow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Foo</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">string</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> s</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: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></div>=
<br>It is potentially converting -- will trigger a warning<br></div><div><b=
r></div><div style=3D"background-color: rgb(250, 250, 250); border-color: r=
gb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: b=
reak-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
=C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettify">temp=
late</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Ts</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Foo</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Ts</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&=
amp;...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">/* ... */</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span></div></code></div><div><br></div>I=
s potentially buggy. Do you really want to construct from about *everything=
*? Such constructors are known to have caused bugs: http://ericniebler.com/=
2013/08/07/universal-references-and-the-copy-constructo/<br>They &quot;comp=
ete&quot; with copy/move constructors, if not anything else. Nonetheless, i=
t is potentially converting -- will trigger a warning<br><br>We are talking=
 about warnings: programmers will surely be allowed to turn them off, when =
they feel uncomfortable.<br><br>=C2=A0Regards,<br>&amp;rzej<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/4fa60d1d-389a-462f-a79f-43e58aec016d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4fa60d1d-389a-462f-a79f-43e58aec016d=
%40isocpp.org</a>.<br />

------=_Part_152_1815436103.1475128485384--

------=_Part_151_555223993.1475128485384--

.

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

On Thu, Sep 29, 2016 at 12:54 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.=
com>
wrote:

> Is potentially buggy. Do you really want to construct from about
> *everything*? Such constructors are known to have caused bugs:
> http://ericniebler.com/2013/08/07/universal-references-and-
> the-copy-constructo/
> They "compete" with copy/move constructors, if not anything else.
> Nonetheless, it is potentially converting -- will trigger a warning
>

I'm confused.  Given that forwarding references are always an exact match
without any conversion, how does this proposal address either "construct
from about *everything*" or the problem of competing with copy/move
constructors?  Please elaborate, because I just don't see it.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--=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/CAGg_6%2BNmtxu%3D%3Djvd_vJmG10aZmn3cgZGVQ9kCZ8ED=
7x4Pq4%3DZw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Sep 29, 2016 at 12:54 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr=
">&lt;<a href=3D"mailto:akrzemi1@gmail.com" target=3D"_blank">akrzemi1@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Is poten=
tially buggy. Do you really want to construct from about *everything*? Such=
 constructors are known to have caused bugs: <a href=3D"http://ericniebler.=
com/2013/08/07/universal-references-and-the-copy-constructo/" target=3D"_bl=
ank">http://ericniebler.com/2013/08<wbr>/07/universal-references-and-<wbr>t=
he-copy-constructo/</a><br>They &quot;compete&quot; with copy/move construc=
tors, if not anything else. Nonetheless, it is potentially converting -- wi=
ll trigger a warning<br></div></blockquote></div><br>I&#39;m confused.=C2=
=A0 Given that forwarding references are always an exact match without any =
conversion, how does this proposal address either &quot;construct from abou=
t *everything*&quot; or the problem of competing with copy/move constructor=
s?=C2=A0 Please elaborate, because I just don&#39;t see it.<br>-- <br><div =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><=
div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:ne=
vin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a><wbr>&gt;=
 =C2=A0<a href=3D"tel:%2B1-847-691-1404" value=3D"+18476911404" target=3D"_=
blank">+1-847-691-1404</a></div></div></div></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNmtxu%3D%3Djvd_vJmG10aZmn3cg=
ZGVQ9kCZ8ED7x4Pq4%3DZw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
Nmtxu%3D%3Djvd_vJmG10aZmn3cgZGVQ9kCZ8ED7x4Pq4%3DZw%40mail.gmail.com</a>.<br=
 />

--001a11408da0853ad6053d9f62d3--

.

------=_Part_209_710863841.1475131243395
Content-Type: multipart/alternative;
 boundary="----=_Part_210_129671860.1475131243395"

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



W dniu czwartek, 29 wrze=C5=9Bnia 2016 08:14:06 UTC+2 u=C5=BCytkownik Nevin=
 ":-)"=20
Liber napisa=C5=82:
>
>
> On Thu, Sep 29, 2016 at 12:54 AM, Andrzej Krzemie=C5=84ski <akrz...@gmail=
..com=20
> <javascript:>> wrote:
>
>> Is potentially buggy. Do you really want to construct from about=20
>> *everything*? Such constructors are known to have caused bugs:=20
>> http://ericniebler.com/2013/08/07/universal-references-and-the-copy-cons=
tructo/
>> They "compete" with copy/move constructors, if not anything else.=20
>> Nonetheless, it is potentially converting -- will trigger a warning
>>
>
> I'm confused.  Given that forwarding references are always an exact match=
=20
> without any conversion, how does this proposal address either "construct=
=20
> from about *everything*" or the problem of competing with copy/move=20
> constructors?  Please elaborate, because I just don't see it.
>
=20
Sorry, It looks I unnecessarily spawned a child thread. It was meant to be=
=20
a side note on forwarding constructors, not in the context of [[implicit]]:=
=20
"Unconstrained forwarding constructors forward too much -- consider not=20
using them (rather than adding attributes)"=20

The only connection between forwarding constructors and [[implicit]] is the=
=20
answer to your challenge:

 template<typename... Ts>
 Foo::Foo(Ts&&...) { /* ... */ }

It is potentially converting: mark it as either 'explicit' or=20
'[[implicit]]'.

Regards,
&rzej;

--=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/920acbbd-1d5c-46c5-a03f-e4fa80fdacb4%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>W dniu czwartek, 29 wrze=C5=9Bnia 2016 08:14:06 UT=
C+2 u=C5=BCytkownik Nevin &quot;:-)&quot; Liber napisa=C5=82:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><div class=3D"gmai=
l_quote">On Thu, Sep 29, 2016 at 12:54 AM, Andrzej Krzemie=C5=84ski <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"hmGmXSWHBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;">akrz...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div>Is potentially buggy. Do you really want to construct from ab=
out *everything*? Such constructors are known to have caused bugs: <a href=
=3D"http://ericniebler.com/2013/08/07/universal-references-and-the-copy-con=
structo/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fericniebler.com%2F2013%2F08%2=
F07%2Funiversal-references-and-the-copy-constructo%2F\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNG5furBo4l7ExsbGLd3urhJh3sccg&#39;;return true;" onclick=
=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fericnieble=
r.com%2F2013%2F08%2F07%2Funiversal-references-and-the-copy-constructo%2F\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG5furBo4l7ExsbGLd3urhJh3sccg&#39;;ret=
urn true;">http://ericniebler.com/2013/<wbr>08/07/universal-references-<wbr=
>and-the-copy-constructo/</a><br>They &quot;compete&quot; with copy/move co=
nstructors, if not anything else. Nonetheless, it is potentially converting=
 -- will trigger a warning<br></div></blockquote></div><br>I&#39;m confused=
..=C2=A0 Given that forwarding references are always an exact match without =
any conversion, how does this proposal address either &quot;construct from =
about *everything*&quot; or the problem of competing with copy/move constru=
ctors?=C2=A0 Please elaborate, because I just don&#39;t see it.<br></div></=
div></blockquote><div>=C2=A0<br>Sorry, It looks I unnecessarily spawned a c=
hild thread. It was meant to be a side note on forwarding constructors, not=
 in the context of [[implicit]]: &quot;Unconstrained forwarding constructor=
s forward too much -- consider not using them (rather than adding attribute=
s)&quot; <br><br>The only connection between forwarding constructors and [[=
implicit]] is the answer to your challenge:<br><br><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px"><code><div><span style=3D"color:#000">=C2=A0</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:#660">...</span=
><span style=3D"color:#000"> </span><span style=3D"color:#606">Ts</span><sp=
an style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br>=C2=A0</s=
pan><span style=3D"color:#606">Foo</span><span style=3D"color:#660">::</spa=
n><span style=3D"color:#606">Foo</span><span style=3D"color:#660">(</span><=
span style=3D"color:#606">Ts</span><span style=3D"color:#660">&amp;&amp;...=
)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#800">/* ... */<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">}</span=
><span style=3D"color:#000"><br></span></div></code></div><br>It is potenti=
ally converting: mark it as either &#39;explicit&#39; or &#39;[[implicit]]&=
#39;.<br><br>Regards,<br>&amp;rzej;<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/920acbbd-1d5c-46c5-a03f-e4fa80fdacb4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/920acbbd-1d5c-46c5-a03f-e4fa80fdacb4=
%40isocpp.org</a>.<br />

------=_Part_210_129671860.1475131243395--

------=_Part_209_710863841.1475131243395--

.

------=_Part_217_2092269832.1475133400133
Content-Type: multipart/alternative;
 boundary="----=_Part_218_103666891.1475133400133"

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

On Thursday, September 29, 2016 at 2:14:06 AM UTC-4, Nevin ":-)" Liber=20
wrote:
>
>
> On Thu, Sep 29, 2016 at 12:54 AM, Andrzej Krzemie=C5=84ski <akrz...@gmail=
..com=20
> <javascript:>> wrote:
>
>> Is potentially buggy. Do you really want to construct from about=20
>> *everything*? Such constructors are known to have caused bugs:=20
>> http://ericniebler.com/2013/08/07/universal-references-and-the-copy-cons=
tructo/
>> They "compete" with copy/move constructors, if not anything else.=20
>> Nonetheless, it is potentially converting -- will trigger a warning
>>
>
> I'm confused.  Given that forwarding references are always an exact match=
=20
> without any conversion, how does this proposal address either "construct=
=20
> from about *everything*" or the problem of competing with copy/move=20
> constructors?  Please elaborate, because I just don't see it.
>

In your example, `Foo` can be *implicitly* converted from any type.=20
Therefore, it is legal to do `Foo f =3D 1`. It is also legal to call=20
`func(1)`, where `func` takes a `Foo`. All of those provoke implicit=20
conversions through your take-anything-constructor.

These are almost *never* what the idea behind that constructor is for. The=
=20
point of such a constructor is not to provoke a bunch of implicit=20
conversions. The writer of `Foo` *should have* marked that constructor=20
`explicit`.

The warning is there to let the user know that they did not. [[implicit]]=
=20
is there for the occasion when they didn't forget `explicit`; they truly=20
intended for it to be a converting constructor.

--=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/2095bcf1-21e5-4e8b-9812-4bd652593b1e%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, September 29, 2016 at 2:14:06 AM UTC-4, Nevin=
 &quot;:-)&quot; Liber wrote:<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><br><div class=3D"gmail_quote">On Thu, Sep 29, 2016 at=
 12:54 AM, Andrzej Krzemie=C5=84ski <span dir=3D"ltr">&lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"hmGmXSWHBQAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">akrz...@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Is potentially bug=
gy. Do you really want to construct from about *everything*? Such construct=
ors are known to have caused bugs: <a href=3D"http://ericniebler.com/2013/0=
8/07/universal-references-and-the-copy-constructo/" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fericniebler.com%2F2013%2F08%2F07%2Funiversal-references-and-=
the-copy-constructo%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG5furBo4l7Ex=
sbGLd3urhJh3sccg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fericniebler.com%2F2013%2F08%2F07%2Funivers=
al-references-and-the-copy-constructo%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNG5furBo4l7ExsbGLd3urhJh3sccg&#39;;return true;">http://ericniebler.co=
m/2013/<wbr>08/07/universal-references-<wbr>and-the-copy-constructo/</a><br=
>They &quot;compete&quot; with copy/move constructors, if not anything else=
.. Nonetheless, it is potentially converting -- will trigger a warning<br></=
div></blockquote></div><br>I&#39;m confused.=C2=A0 Given that forwarding re=
ferences are always an exact match without any conversion, how does this pr=
oposal address either &quot;construct from about *everything*&quot; or the =
problem of competing with copy/move constructors?=C2=A0 Please elaborate, b=
ecause I just don&#39;t see it.</div></div></blockquote><div><br>In your ex=
ample, `Foo` can be <i>implicitly</i> converted from any type. Therefore, i=
t is legal to do `Foo f =3D 1`. It is also legal to call `func(1)`, where `=
func` takes a `Foo`. All of those provoke implicit conversions through your=
 take-anything-constructor.<br><br>These are almost <i>never</i> what the i=
dea behind that constructor is for. The point of such a constructor is not =
to provoke a bunch of implicit conversions. The writer of `Foo` <i>should h=
ave</i> marked that constructor `explicit`.<br><br>The warning is there to =
let the user know that they did not. [[implicit]] is there for the occasion=
 when they didn&#39;t forget `explicit`; they truly intended for it to be a=
 converting constructor.<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/2095bcf1-21e5-4e8b-9812-4bd652593b1e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2095bcf1-21e5-4e8b-9812-4bd652593b1e=
%40isocpp.org</a>.<br />

------=_Part_218_103666891.1475133400133--

------=_Part_217_2092269832.1475133400133--

.

On 2016-09-28 00:56, Jens =C3=85kerblom wrote:
> Wouldn't it be better to depricate the explicit keyword in favor of havin=
g it by default? That is, replace "explicit" with "implicit".

Not really; this would break 95%=C2=B9 of existing C++ code. At best, you
could add `implicit` and have a transition period where not specifying
either is deprecated. Said period would have to be very long, possibly
even indefinite.

(=C2=B9 I'll grant the existence of a very small body of C++ code that does
not have classes with user defined constructors.)

--=20
Matthew

--=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/nsgip9%2467h%241%40blaine.gmane.org.

.