Objective:
----------
Create a new keyword "implicit", having the meaning 'not "explicit"'.
That is, this keyword would annotate that a constructor or conversion
operator is allowed to be called in a manner that would be denied by
'explicit'.

Rationale:
----------
"explicit" is a great tool for avoiding mistakes in the use of a class.
Unfortunately, programmers must remember to use it, and there is not
presently a mechanism to diagnose failure to do so. Adding an "implicit"
keyword would permit compilers to diagnose constructors and/or
conversion operators which are in fact implicit according to the
standard, but are not marked as such. This would provide a mechanism to
warn programmers that a constructor or conversion operator is
potentially dangerous, while allowing them to clearly specify when this
is the intent.

Considerations:
---------------
Since keywords are scarce and the introduction of new keywords carries
the potential to break existing code, I suggest to make "implicit" a
context sensitive keyword in a similar manner as e.g. "override":

- If the compiler encounters the "implicit" token within a class
definition scope, it shall perform a forward scan of following tokens.
If the following token is the class name or equivalent (e.g. if we get
'auto' to declare constructors), or is followed by "operator" and then a
type name, "implicit" shall be treated as a keyword with the above meaning.

- For all other cases, "implicit" shall be treated as a potential type
name or identifier (i.e. historic behavior, not a keyword).

Alternatives:
-------------
Rather than a keyword, an attribute "[[implicit]]" could be used for
this purpose. Projects that prefer the appearance of a keyword can
define a macro "implicit" that expands to this attribute for supporting
compilers, or empty otherwise.

Addendum:
---------
The behavior of a constructor or conversion operator that is not
specified "explicit" remains "implicit" (i.e. this would not change the
meaning of existing code).

References:
-----------
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60135

-----------------------------------------------------------------------

What do folks think? Is this a reasonable wish? Is there a better way to
achieve this goal?

--
Matthew

--

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

.

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

On 10 February 2014 10:30, Matthew Woehlke
<mw_triad@users.sourceforge.net>wrote:

> Adding an "implicit" keyword would permit compilers to diagnose
> constructors and/or conversion operators which are in fact implicit
> according to the standard, but are not marked as such. This would provide a
> mechanism to warn programmers that a constructor or conversion operator is
> potentially dangerous, while allowing them to clearly specify when this is
> the intent.
>

But you still have to support not specifying "implicit" (or break huge
amounts of code), so I don't see what the keyword really buys you.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On 10 February 2014 10:30, Matthew Woehlke <span dir=3D"lt=
r">&lt;<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">=
mw_triad@users.sourceforge.net</a>&gt;</span> wrote:<br><div class=3D"gmail=
_extra">

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Adding an &quot;i=
mplicit&quot; keyword would permit compilers to diagnose constructors and/o=
r conversion operators which are in fact implicit according to the standard=
, but are not marked as such. This would provide a mechanism to warn progra=
mmers that a constructor or conversion operator is potentially dangerous, w=
hile allowing them to clearly specify when this is the intent.<br>

</blockquote><div><br></div><div>But you still have to support not specifyi=
ng &quot;implicit&quot; (or break huge amounts of code), so I don&#39;t see=
 what the keyword really buys you.</div></div>-- <br>=A0Nevin &quot;:-)&quo=
t; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"=
_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

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

--047d7bb04f687e226f04f20ffaf9--

.

On 2014-02-10 11:38, Nevin Liber wrote:
> On 10 February 2014 10:30, Matthew Woehlke wrote:
>> Adding an "implicit" keyword would permit compilers to diagnose
>> constructors and/or conversion operators which are in fact implicit
>> according to the standard, but are not marked as such. This would provide a
>> mechanism to warn programmers that a constructor or conversion operator is
>> potentially dangerous, while allowing them to clearly specify when this is
>> the intent.
>
> But you still have to support not specifying "implicit" (or break huge
> amounts of code), so I don't see what the keyword really buys you.

Yes, but that's the same problem as with e.g. implicit switch
fallthrough. Some things can only work for code bases that wish to 'opt
in' and thus "have" to change their existing code (and/or live with
warnings).

Currently there is no mechanism to do even that.

Also note that I explicitly specified that the meaning of existing code
is not changed. The point is to define a common mechanism to specify intent.

The alternative is to ignore the problem or only solve it using
compiler-specific markup.

--
Matthew

--

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

.

--Apple-Mail=_0F21165C-75C5-4D88-8F11-082EB40EA659
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On Feb 11, 2014, at 1:08 AM, Matthew Woehlke <mw_triad@users.sourceforge.ne=
t> wrote:

> Yes, but that's the same problem as with e.g. implicit switch fallthrough=
.. Some things can only work for code bases that wish to 'opt in' and thus "=
have" to change their existing code (and/or live with warnings).
>=20
> Currently there is no mechanism to do even that.
>=20
> Also note that I explicitly specified that the meaning of existing code i=
s not changed. The point is to define a common mechanism to specify intent.
>=20
> The alternative is to ignore the problem or only solve it using compiler-=
specific markup.

Since implicit is always implicit, it can always be specified by lack of sp=
ecification. Fortunately, the preprocessor provides the user with the tools=
 to expressively specify nothing:

#define implicit // Implicit is the default, i.e. opposite of explicit keyw=
ord.

struct wrap_int {
    implicit wrap_int( int );

    implicit operator int();

    int value;
};

This is stylistically fine, completely portable, and easy to understand (gi=
ven a comment). It doesn't break anything except use of implicit as an iden=
tifier, which the proposal does too. (Users would be well advised to do thi=
s only after all third-party library #includes.)

The only disadvantages are inability to diagnose improper usage, which isn'=
t particularly important, and inconsistent syntax highlighting in text edit=
ors, which savvy users can often fix for themselves.

--=20

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

--Apple-Mail=_0F21165C-75C5-4D88-8F11-082EB40EA659
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 11, 2=
014, at 1:08 AM, Matthew Woehlke &lt;<a href=3D"mailto:mw_triad@users.sourc=
eforge.net">mw_triad@users.sourceforge.net</a>&gt; wrote:</div><br class=3D=
"Apple-interchange-newline"><blockquote type=3D"cite">Yes, but that's the s=
ame problem as with e.g. implicit switch fallthrough. Some things can only =
work for code bases that wish to 'opt in' and thus "have" to change their e=
xisting code (and/or live with warnings).<br><br>Currently there is no mech=
anism to do even that.<br><br>Also note that I explicitly specified that th=
e meaning of existing code is not changed. The point is to define a common =
mechanism to specify intent.<br><br>The alternative is to ignore the proble=
m or only solve it using compiler-specific markup.<br></blockquote><div><br=
></div><div>Since <font face=3D"Courier">implicit</font> is always implicit=
, it can always be specified by lack of specification. Fortunately, the pre=
processor provides the user with the tools to expressively specify nothing:=
</div><div><br></div><div><font face=3D"Courier">#define implicit // Implic=
it is the default, i.e. opposite of explicit keyword.</font></div><div><fon=
t face=3D"Courier"><br></font></div><div><font face=3D"Courier">struct wrap=
_int {</font></div><div><font face=3D"Courier">&nbsp; &nbsp; implicit wrap_=
int( int );</font></div><div><font face=3D"Courier"><br></font></div><div><=
font face=3D"Courier">&nbsp; &nbsp; implicit operator int();</font></div><d=
iv><font face=3D"Courier"><br></font></div><div><font face=3D"Courier">&nbs=
p; &nbsp; int value;</font></div><div><font face=3D"Courier">};</font></div=
><div><br></div><div>This is stylistically fine, completely portable, and e=
asy to understand (given a comment). It doesn't break anything except use o=
f <font face=3D"Courier">implicit</font>&nbsp;as an identifier, which the p=
roposal does too. (Users would be well advised to do this only after all th=
ird-party library <font face=3D"Courier">#include</font>s.)</div><div><br><=
/div><div>The only disadvantages are inability to diagnose improper usage, =
which isn't particularly important, and inconsistent syntax highlighting in=
 text editors, which savvy users can often fix for themselves.</div><div><b=
r></div></div></body></html>

<p></p>

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

--Apple-Mail=_0F21165C-75C5-4D88-8F11-082EB40EA659--

.

On Mon, Feb 10, 2014 at 11:30:32AM -0500, Matthew Woehlke wrote:
> Objective:
> ----------
> Create a new keyword "implicit", having the meaning 'not
> "explicit"'. That is, this keyword would annotate that a constructor
> or conversion operator is allowed to be called in a manner that
> would be denied by 'explicit'.

I would expect a constructor marked as 'implicit' to be disallowed
in explicit situations, so

struct foo {
 implicit foo(int) { }
};

foo f = 1; // Valid
foo g(1); // Invalid

but I admit to not seeing much value in it.

As for the bikeshed, both 'not' and 'explicit' are already keywords, so why
not spell it 'not explicit'?

/MF

--

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

.

Em ter 11 fev 2014, =E0s 14:19:09, David Krauss escreveu:
> This is stylistically fine, completely portable, and easy to understand
> (given a comment). It doesn't break anything except use of implicit as an
> identifier, which the proposal does too. (Users would be well advised to =
do
> this only after all third-party library #includes.)

The proposal was for a context-dependent keyword. It would not break uses o=
f=20
"implicit" as an identifier elsewhere.

Question: if it's context-dependent, would it be allowed only to the right =
of=20
the parameter list?

struct X {
 X(int) implicit;
 explicit X(long);
};

If so, then the explicit keyword should be allowed to be there too.

It might not be, since only constructors and cast operators can be implicit=
=20
and those cannot have return types, so the presence of the keyword there wo=
uld=20
not be ambiguous. It might just be ugly:

struct implicit {
 implicit implicit(int);
 explicit implicit(long);
};
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

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

.

On 2014-02-11 01:19, David Krauss wrote:
> Since implicit is always implicit, it can always be specified by lack
> of specification.

How would this achieve the desired goal? I admit I am not a compiler
writer, but I expect most compilers have already run through
preprocessing before the stage where a diagnostic for unmarked implicit
methods could occur.

> Fortunately, the preprocessor provides the user with the tools to
> expressively specify nothing:
>
> #define implicit
>
> This is stylistically fine, completely portable, and easy to
> understand (given a comment). It doesn't break anything except use of
> implicit as an identifier, which the proposal does too.

No, (as Thiago also points out) this is *far* worse than my proposal,
which was to treat "implicit" as a keyword *only where it can be used as
such*. Which are also, I believe, locations where already a type or
identifier would be an error, which means that my proposal won't and
can't break existing code. (Even code that already does e.g. like you
propose, though of course the proposed diagnostic would not work in that
case.) Whereas yours breaks any code that uses 'implicit' as a type
and/or identifier.

--
Matthew

--

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

.

On 2014-02-11 02:34, Thiago Macieira wrote:
> Em ter 11 fev 2014, =C3=A0s 14:19:09, David Krauss escreveu:
>> This is stylistically fine, completely portable, and easy to understand
>> (given a comment). It doesn't break anything except use of implicit as a=
n
>> identifier, which the proposal does too. (Users would be well advised to=
 do
>> this only after all third-party library #includes.)
>
> The proposal was for a context-dependent keyword. It would not break uses=
 of
> "implicit" as an identifier elsewhere.
>
> Question: if it's context-dependent, would it be allowed only to the righ=
t of
> the parameter list?

No. In fact (like 'explicit') it would not be allowed to the right; see=20
original mail for the parse rules.

Examples:

class Foo
{
   implicit Foo(int); // okay
   explicit Foo(float); // okay
   Foo(short) implicit; // error, expected ';' after declaration
   Foo(double) explicit; // error, expected ';' after declaration
   implicit operator int(); // okay
   implicit operator+(int); // error, 'implicit' does not name a type
};
int implicit; // okay, declared an int variable named "implicit"

using implicit =3D int;
class Bar
{
   implicit operator+(int); // okay (but ugly), return type is int
   int operator-(implicit); // okay (but ugly), takes an int
};

> It might not be, since only constructors and cast operators can be implic=
it
> and those cannot have return types, so the presence of the keyword there =
would
> not be ambiguous. It might just be ugly:
>
> struct implicit {
>  implicit implicit(int);
>  explicit implicit(long);
> };

Eew. Yes, that's ugly :-). But would be allowed.

--=20
Matthew

--=20

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

.

On 2014-02-11 01:54, Magnus Fromreide wrote:
> On Mon, Feb 10, 2014 at 11:30:32AM -0500, Matthew Woehlke wrote:
>> Objective:
>> ----------
>> Create a new keyword "implicit", having the meaning 'not
>> "explicit"'. That is, this keyword would annotate that a constructor
>> or conversion operator is allowed to be called in a manner that
>> would be denied by 'explicit'.
>
> I would expect a constructor marked as 'implicit' to be disallowed
> in explicit situations, so
>
> struct foo {
>  implicit foo(int) { }
> };
>
> foo f = 1; // Valid
> foo g(1); // Invalid
>
> but I admit to not seeing much value in it.

Yes, that seems like it would be very confusing, besides that it is a
new behavior (which my proposal wouldn't be).

> As for the bikeshed, both 'not' and 'explicit' are already keywords, so why
> not spell it 'not explicit'?

I could (with a '#define implicit not explicit', probably :-) ) live
with that.

--
Matthew

--

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

.

Em seg 10 fev 2014, =E0s 11:30:32, Matthew Woehlke escreveu:
> Objective:
> ----------
> Create a new keyword "implicit", having the meaning 'not "explicit"'.=20
> That is, this keyword would annotate that a constructor or conversion=20
> operator is allowed to be called in a manner that would be denied by=20
> 'explicit'.
[snip]

I think it's a good idea and I support.

For example, in KDE we have a policy: every one-argument constructor must=
=20
either have the "explicit" keyword or must have "implicit" in a comment on =
the=20
same line[1]. Then we have an after-the-fact source code checker that verif=
ies=20
everything and produces warnings.

A keyword woud allow us to dump that part of the script and just enable a=
=20
compiler warning, or even a -Werror.

[1] the rule wasn't updated to deal with C++11 initialisation lists.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

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

.

--001a1139b03ef695ad04f236a7ef
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On a completely orthogonal direction, why not use attributes to do this,
and let compiler writers handle it. I imagine you could do:

struct X {
   [[implicit]] X(int);
};
struct Y {
   Y(int);
};

With a compiler flag to diagnose the lack of the attribute, so the above
would compile fine in one mode, or provide a diagnostic if
-Wdefault-implicit (error with -Edefault-implicit) in Y's constructor.

There is nothing that blocks a compiler from doing this already in C++11,
but I can see that the specific attribute to use could be standarized.

This has the advantage of not implying changes to the standard (other than
the possible standarization of the attribute spelling), it does not
introduce keywords or contextual keywords or anything that has to be
special cased in the compiler since attributes need to be supported already
and it is backwards compatible (C++11 compilers not supporting this feature
would just ignore the attribute).

    David


On Tue, Feb 11, 2014 at 1:11 PM, Thiago Macieira <thiago@macieira.org>wrote=
:

> Em seg 10 fev 2014, =E0s 11:30:32, Matthew Woehlke escreveu:
> > Objective:
> > ----------
> > Create a new keyword "implicit", having the meaning 'not "explicit"'.
> > That is, this keyword would annotate that a constructor or conversion
> > operator is allowed to be called in a manner that would be denied by
> > 'explicit'.
> [snip]
>
> I think it's a good idea and I support.
>
> For example, in KDE we have a policy: every one-argument constructor must
> either have the "explicit" keyword or must have "implicit" in a comment o=
n
> the
> same line[1]. Then we have an after-the-fact source code checker that
> verifies
> everything and produces warnings.
>
> A keyword woud allow us to dump that part of the script and just enable a
> compiler warning, or even a -Werror.
>
> [1] the rule wasn't updated to deal with C++11 initialisation lists.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">On a completely orthogonal direction, why not use attribut=
es to do this, and let compiler writers handle it. I imagine you could do:<=
br><br>struct X {<br>=A0 =A0[[implicit]] X(int);<div>};<br>struct Y {<br>=
=A0 =A0Y(int);<br>
};<br><br>With a compiler flag to diagnose the lack of the attribute, so th=
e above would compile fine in one mode, or provide a diagnostic if -Wdefaul=
t-implicit (error with -Edefault-implicit) in Y&#39;s constructor.<br><br>
There is nothing that blocks a compiler from doing this already in C++11, b=
ut I can see that the specific attribute to use could be standarized.<br><b=
r>This has the advantage of not implying changes to the standard (other tha=
n the possible standarization of the attribute spelling), it does not intro=
duce keywords or contextual keywords or anything that has to be special cas=
ed in the compiler since attributes need to be supported already and it is =
backwards compatible (C++11 compilers not supporting this feature would jus=
t ignore the attribute).=A0<br>
<br>=A0 =A0 David</div></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Tue, Feb 11, 2014 at 1:11 PM, Thiago Macieira <span dir=
=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiag=
o@macieira.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Em seg 10 fev 2014, =E0s 11:30:32, Matthew W=
oehlke escreveu:<br>
<div class=3D"">&gt; Objective:<br>
&gt; ----------<br>
&gt; Create a new keyword &quot;implicit&quot;, having the meaning &#39;not=
 &quot;explicit&quot;&#39;.<br>
&gt; That is, this keyword would annotate that a constructor or conversion<=
br>
&gt; operator is allowed to be called in a manner that would be denied by<b=
r>
&gt; &#39;explicit&#39;.<br>
</div>[snip]<br>
<br>
I think it&#39;s a good idea and I support.<br>
<br>
For example, in KDE we have a policy: every one-argument constructor must<b=
r>
either have the &quot;explicit&quot; keyword or must have &quot;implicit&qu=
ot; in a comment on the<br>
same line[1]. Then we have an after-the-fact source code checker that verif=
ies<br>
everything and produces warnings.<br>
<br>
A keyword woud allow us to dump that part of the script and just enable a<b=
r>
compiler warning, or even a -Werror.<br>
<br>
[1] the rule wasn&#39;t updated to deal with C++11 initialisation lists.<br=
>
<div class=3D"im HOEnZb">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a1139b03ef695ad04f236a7ef--

.