------=_Part_309_2711909.1353418602694
Content-Type: text/plain; charset=ISO-8859-1

C++ now supports explicit single-argument constructors and conversion
operators. As it's often better to be explicit than to be implcit, wouldn't
an implicit keyword be a good addition? The default can't be changed
without breaking code, but with an implicit keyword compilers could warn
for functions that may be implicit by accident.

--




------=_Part_309_2711909.1353418602694
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

C++ now supports explicit single-argument constructors and conversion opera=
tors. As it's often better to be explicit than to be implcit, wouldn't an i=
mplicit keyword be a good addition? The default can't be changed without br=
eaking code, but with an implicit keyword compilers could warn for function=
s that may be implicit by accident.<div><br></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_309_2711909.1353418602694--

.

On Tue, Nov 20, 2012 at 11:36 AM, Olaf van der Spek
<olafvdspek@gmail.com> wrote:
> C++ now supports explicit single-argument constructors and conversion
> operators. As it's often better to be explicit than to be implcit, wouldn't
> an implicit keyword be a good addition? The default can't be changed without
> breaking code, but with an implicit keyword compilers could warn for
> functions that may be implicit by accident.

I have found that I prefer implicit rather than explicit. Unless
somekind of side
effect would occur, such as transfer of ownership. Most of my classes are
actually value-based and use the constructor parameters to build this value,
so side effects are actually rarer. So I would find quite annoying
that a compiler
warns all the time just because I didn't write implicit in 99% of my classes.

> --

Regards,
--
Felipe Magno de Almeida

--




.

On 20 November 2012 15:50, Felipe Magno de Almeida
<felipe.m.almeida@gmail.com> wrote:
> On Tue, Nov 20, 2012 at 11:36 AM, Olaf van der Spek
> <olafvdspek@gmail.com> wrote:
>> C++ now supports explicit single-argument constructors and conversion
>> operators. As it's often better to be explicit than to be implcit, wouldn't
>> an implicit keyword be a good addition? The default can't be changed without
>> breaking code, but with an implicit keyword compilers could warn for
>> functions that may be implicit by accident.
> I have found that I prefer implicit rather than explicit. Unless
> somekind of side
> effect would occur, such as transfer of ownership. Most of my classes are
> actually value-based and use the constructor parameters to build this value,
> so side effects are actually rarer. So I would find quite annoying
> that a compiler
> warns all the time just because I didn't write implicit in 99% of my classes.

I would be more interested in this idea if there was field experience
with compiler switches
that warn about such cases. I'm not aware of such switches being
commonplace, but I
haven't looked much. If it's just going to quiesce a warning, "I
really mean this to be implicit",
why wouldn't it be an attribute? Do you really want to, after
deprecation, make undecorated
declarations of implicit conversions ill-formed?

--




.

On Tue, Nov 20, 2012 at 11:50 AM, Felipe Magno de Almeida
<felipe.m.almeida@gmail.com> wrote:
> On Tue, Nov 20, 2012 at 11:36 AM, Olaf van der Spek
> <olafvdspek@gmail.com> wrote:
>> C++ now supports explicit single-argument constructors and conversion
>> operators. As it's often better to be explicit than to be implcit, wouldn't
>> an implicit keyword be a good addition? The default can't be changed without
>> breaking code, but with an implicit keyword compilers could warn for
>> functions that may be implicit by accident.
>
> I have found that I prefer implicit rather than explicit. Unless
> somekind of side
> effect would occur, such as transfer of ownership. Most of my classes are
> actually value-based and use the constructor parameters to build this value,
> so side effects are actually rarer. So I would find quite annoying
> that a compiler
> warns all the time just because I didn't write implicit in 99% of my classes.

Besides, I'm not sure I agree with "it's often better to be explicit  than to be
implicit". This is usually an argument used against C++ by C programmers,
because of the intrinsic implicitness of working with abstractions.

Regards,
--
Felipe Magno de Almeida

--




.

------=_Part_307_19949873.1353420271730
Content-Type: text/plain; charset=ISO-8859-1

Op dinsdag 20 november 2012 14:52:56 UTC+1 schreef Ville Voutilainen het
volgende:

> On 20 November 2012 15:50, Felipe Magno de Almeida
> <felipe.m...@gmail.com <javascript:>> wrote:
> > On Tue, Nov 20, 2012 at 11:36 AM, Olaf van der Spek
> > <olafv...@gmail.com <javascript:>> wrote:
> >> C++ now supports explicit single-argument constructors and conversion
> >> operators. As it's often better to be explicit than to be implcit,
> wouldn't
> >> an implicit keyword be a good addition? The default can't be changed
> without
> >> breaking code, but with an implicit keyword compilers could warn for
> >> functions that may be implicit by accident.
> > I have found that I prefer implicit rather than explicit. Unless
> > somekind of side
> > effect would occur, such as transfer of ownership. Most of my classes
> are
> > actually value-based and use the constructor parameters to build this
> value,
>

Parameters? If a constructor has more (or less) than one (non-default)
parameter, it's always explicit isn't it?


> > so side effects are actually rarer. So I would find quite annoying
> > that a compiler
> > warns all the time just because I didn't write implicit in 99% of my
> classes.
>
> I would be more interested in this idea if there was field experience
> with compiler switches
> that warn about such cases. I'm not aware of such switches being
> commonplace, but I
> haven't looked much. If it's just going to quiesce a warning, "I
> really mean this to be implicit",
> why wouldn't it be an attribute? Do you really want to, after
>

An attribute makes more sense as a start.


> deprecation, make undecorated
> declarations of implicit conversions ill-formed?
>

Don't know, it depends. Certainly not any time soon.

--




------=_Part_307_19949873.1353420271730
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op dinsdag 20 november 2012 14:52:56 UTC+1 schreef Ville Voutilainen het vo=
lgende:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 20 November 2012=
 15:50, Felipe Magno de Almeida
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
tNONTNyIa2EJ">felipe.m...@gmail.com</a>&gt; wrote:
<br>&gt; On Tue, Nov 20, 2012 at 11:36 AM, Olaf van der Spek
<br>&gt; &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"tNONTNyIa2EJ">olafv...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; C++ now supports explicit single-argument constructors and con=
version
<br>&gt;&gt; operators. As it's often better to be explicit than to be impl=
cit, wouldn't
<br>&gt;&gt; an implicit keyword be a good addition? The default can't be c=
hanged without
<br>&gt;&gt; breaking code, but with an implicit keyword compilers could wa=
rn for
<br>&gt;&gt; functions that may be implicit by accident.
<br>&gt; I have found that I prefer implicit rather than explicit. Unless
<br>&gt; somekind of side
<br>&gt; effect would occur, such as transfer of ownership. Most of my clas=
ses are
<br>&gt; actually value-based and use the constructor parameters to build t=
his value,
<br></blockquote><div><br></div><div>Parameters? If a constructor has more =
(or less) than one (non-default) parameter, it's always explicit isn't it?<=
/div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; so =
side effects are actually rarer. So I would find quite annoying
<br>&gt; that a compiler
<br>&gt; warns all the time just because I didn't write implicit in 99% of =
my classes.
<br>
<br>I would be more interested in this idea if there was field experience
<br>with compiler switches
<br>that warn about such cases. I'm not aware of such switches being
<br>commonplace, but I
<br>haven't looked much. If it's just going to quiesce a warning, "I
<br>really mean this to be implicit",
<br>why wouldn't it be an attribute? Do you really want to, after
<br></blockquote><div><br></div><div>An attribute makes more sense as a sta=
rt.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">depr=
ecation, make undecorated
<br>declarations of implicit conversions ill-formed?
<br></blockquote><div><br></div><div>Don't know, it depends. Certainly not =
any time soon.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_307_19949873.1353420271730--

.

On Tue, Nov 20, 2012 at 3:04 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>
> Parameters? If a constructor has more (or less) than one (non-default)
> parameter, it's always explicit isn't it?

No. But before C++11 you were not able to test the "explicitness" of
such a constructor. In C++11 however, we can use the following
initialization of a pair<int,int> object:

    pait<int,int> x = {23,42}; // copy list initialization

Adding the "explicit" keyword to the corresponding constructor would
make this initialization illegal because all kinds of "copy something"
initializations (those initializations with an equal sign) can never
use explicit constructors. Explicit constructors can only be invoked
via a "direct initialization":

   pair<int,int> x {23,42}; // direct list initialization

Cheers!
SG

--




.

------=_Part_113_19065321.1353428184059
Content-Type: text/plain; charset=ISO-8859-1

Maybe auto could represent a more implicit kind of cast. For example, this
could be allowed:

class Foo {
    std::vector<int> m_vector;
    public:
    auto operator std::vector<int>&() {
        return m_vector;
    }
};

int main()
{
    Foo f;
    f.push_back(0);
    return f.back();
}

But it could be as dangerous as inheriting from a base class with a
non-virtual destructor.

--




------=_Part_113_19065321.1353428184059
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Maybe auto could represent a more implicit kind of cast. For example, this =
could be allowed:<br><br><span style=3D"font-family: courier new,monospace;=
">class Foo {<br>&nbsp;&nbsp;&nbsp; std::vector&lt;int&gt; m_vector;<br>&nb=
sp;&nbsp;&nbsp; public:<br>&nbsp;&nbsp;&nbsp; auto operator std::vector&lt;=
int&gt;&amp;() {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return m_vec=
tor;<br>&nbsp;&nbsp;&nbsp; }<br>};<br><br>int main()<br>{<br>&nbsp;&nbsp;&n=
bsp; Foo f;<br>&nbsp;&nbsp;&nbsp; f.push_back(0);<br>&nbsp;&nbsp;&nbsp; ret=
urn f.back();<br>}<br></span><br>But it could be as dangerous as inheriting=
 from a base class with a non-virtual destructor.<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_113_19065321.1353428184059--

.

--bcaec501634b06138604cef16893
Content-Type: text/plain; charset=ISO-8859-1

2012/11/20 Marc Thibault <marc.thibault1977@gmail.com>

> Maybe auto could represent a more implicit kind of cast. For example, this
> could be allowed:
>
> class Foo {
>     std::vector<int> m_vector;
>     public:
>     auto operator std::vector<int>&() {
>         return m_vector;
>     }
> };
>
> int main()
> {
>     Foo f;
>     f.push_back(0);
>     return f.back();
> }
>
> But it could be as dangerous as inheriting from a base class with a
> non-virtual destructor.
>

I don't think that "auto operator" is an appropriate syntactic
representation for what you
show here, because you are essentially overloading operator.(). I'm not
against that, but lets
be honest and lets give the children the right name:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1671.pdf

- Daniel

--




--bcaec501634b06138604cef16893
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2012/11/20 Marc Thibault <span dir=3D"ltr">&lt;<=
a href=3D"mailto:marc.thibault1977@gmail.com" target=3D"_blank">marc.thibau=
lt1977@gmail.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe auto could represent a more implicit kind of cast. For example, this =
could be allowed:<br><br><span style=3D"font-family:courier new,monospace">=
class Foo {<br>=A0=A0=A0 std::vector&lt;int&gt; m_vector;<br>=A0=A0=A0 publ=
ic:<br>=A0=A0=A0 auto operator std::vector&lt;int&gt;&amp;() {<br>
=A0=A0=A0=A0=A0=A0=A0 return m_vector;<br>=A0=A0=A0 }<br>};<br><br>int main=
()<br>{<br>=A0=A0=A0 Foo f;<br>=A0=A0=A0 f.push_back(0);<br>=A0=A0=A0 retur=
n f.back();<br>}<br></span><br>But it could be as dangerous as inheriting f=
rom a base class with a non-virtual destructor.<span class=3D"HOEnZb"><font=
 color=3D"#888888"><br>
</font></span></blockquote><div><br></div></div>I don&#39;t think that &quo=
t;auto operator&quot; is an appropriate syntactic representation for what y=
ou<br>show here, because you are essentially overloading operator.(). I&#39=
;m not against that, but lets<br>
be honest and lets give the children the right name:<br><br><a href=3D"http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1671.pdf">http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2004/n1671.pdf</a><br><br>- Daniel<b=
r>
<br><br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--bcaec501634b06138604cef16893--

.