------=_Part_1306_135558851.1410996456851
Content-Type: text/plain; charset=UTF-8

Hi all,
This is my first-ever attempt at initiating a proposal; I look forward to
the process.

I think there's gaping hole in C++ that permits (or, more importantly,
prevents the class designer from prohibiting) the redefinition/hiding of a
non-virtual  function. As Scott Meyers says in items 35 and 36 of *Effective
C++ (3rd Ed.)*, non-virtual functions are supposed to represent *invariants
over specialization*. Yet, C++ currently offers no mechanism whereby a
function can be flagged explicitly as "not to be redefined."

Following some great conversations at CppCon (the most illuminating being
one I had with stl), I'd like to propose a new contextual keyword that
would be closely related to final/override (and written similarly.) The
best name I've been able to think of so far for this new keyword is
"invariant."

Since 'final' only applies to virtual functions, 'invariant' would only be
applicable to non-virtual functions, and make it an error to redefine the
function in a derived class.

Perhaps it would make sense to extend the prohibition to* all *forms of
hiding, so that no members of *any* kind can be declared with the same name
as any inherited invariant function.

And that's as far as I've gotten so far. Worth pursuing?

Thanks!





--

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

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

<div dir=3D"ltr">Hi all,<br>This is my first-ever attempt at initiating a p=
roposal; I look forward to the process.<br><br>I think there's gaping hole =
in C++ that permits (or, more importantly, prevents the class designer from=
 prohibiting) the redefinition/hiding of a non-virtual&nbsp; function. As S=
cott Meyers says in items 35 and 36 of <i>Effective C++ (3rd Ed.)</i>, non-=
virtual functions are supposed to represent <i>invariants over specializati=
on</i>. Yet, C++ currently offers no mechanism whereby a function can be fl=
agged explicitly as "not to be redefined." <br><br>Following some great con=
versations at CppCon (the most illuminating=20
being one I had with stl), I'd like to propose a new contextual keyword tha=
t=20
would be closely related to final/override (and written similarly.) The bes=
t name I've been able to think of so far for this new keyword is "invariant=
.."<br><br>Since 'final' only applies to virtual functions, 'invariant' woul=
d only be applicable to non-virtual functions, and make it an error to rede=
fine the function in a derived class. <br><br>Perhaps it would make sense t=
o extend the prohibition to<i> all </i>forms of hiding, so that no members =
of <i>any</i> kind can be declared with the same name as any inherited inva=
riant function.<br><br>And that's as far as I've gotten so far. Worth pursu=
ing?<br><br>Thanks!<br><br><br><br><br><br></div>

<p></p>

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

------=_Part_1306_135558851.1410996456851--

.

On 18 September 2014 02:27, Leor Zolman <leorzolman@gmail.com> wrote:
> Hi all,
> This is my first-ever attempt at initiating a proposal; I look forward to
> the process.
>
> I think there's gaping hole in C++ that permits (or, more importantly,
> prevents the class designer from prohibiting) the redefinition/hiding of a
> non-virtual  function. As Scott Meyers says in items 35 and 36 of Effective
> C++ (3rd Ed.), non-virtual functions are supposed to represent invariants
> over specialization. Yet, C++ currently offers no mechanism whereby a
> function can be flagged explicitly as "not to be redefined."

The question is whether it needs to. Implementations already do issue warnings
for designs that violate that particular way of designing programs. From a
practical point of view, such "viral" facilities need to be considered
with care.

> Following some great conversations at CppCon (the most illuminating being
> one I had with stl), I'd like to propose a new contextual keyword that would
> be closely related to final/override (and written similarly.) The best name
> I've been able to think of so far for this new keyword is "invariant."
>
> Since 'final' only applies to virtual functions, 'invariant' would only be
> applicable to non-virtual functions, and make it an error to redefine the
> function in a derived class.
>
> Perhaps it would make sense to extend the prohibition to all forms of
> hiding, so that no members of any kind can be declared with the same name as
> any inherited invariant function.

Perhaps it would, because I think the complete idea is to prevent changing
the meaning of a call expression that looks like a call expression applied to
the base type. Then again, that may be reaching too far, because the purpose
of the facility is to prevent accidents rather than abuse, right? I'm
fairly confident
that having such a contextual keyword apply to member function declarations and
checking derived class member declarations is pretty simple to specify
and implement,
whereas the full-hiding checking is at least more difficult to implement.

> And that's as far as I've gotten so far. Worth pursuing?

Potentially. What such a proposal certainly needs is a good explanation of
its motivation, preferably with examples of existing code where such a keyword
would help.

--

---
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/.

.

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

On Wed, Sep 17, 2014 at 7:27 PM, Leor Zolman <leorzolman@gmail.com> wrote:

> Hi all,
> This is my first-ever attempt at initiating a proposal; I look forward to
> the process.
>
> I think there's gaping hole in C++ that permits (or, more importantly,
> prevents the class designer from prohibiting) the redefinition/hiding of a
> non-virtual  function. As Scott Meyers says in items 35 and 36 of *Effective
> C++ (3rd Ed.)*, non-virtual functions are supposed to represent *invariants
> over specialization*. Yet, C++ currently offers no mechanism whereby a
> function can be flagged explicitly as "not to be redefined."
>
> Following some great conversations at CppCon (the most illuminating being
> one I had with stl), I'd like to propose a new contextual keyword that
> would be closely related to final/override (and written similarly.) The
> best name I've been able to think of so far for this new keyword is
> "invariant."
>
> Since 'final' only applies to virtual functions, 'invariant' would only be
> applicable to non-virtual functions, and make it an error to redefine the
> function in a derived class.
>


Why not just reuse 'final' then?

Tony

--

---
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/.

--089e0158ad547cc9aa0503586a7a
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 17, 2014 at 7:27 PM, Leor Zolman <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:leorzolman@gmail.com" target=3D"_blank">leorzolman@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 dir=3D"ltr">Hi=
 all,<br>This is my first-ever attempt at initiating a proposal; I look for=
ward to the process.<br><br>I think there&#39;s gaping hole in C++ that per=
mits (or, more importantly, prevents the class designer from prohibiting) t=
he redefinition/hiding of a non-virtual=C2=A0 function. As Scott Meyers say=
s in items 35 and 36 of <i>Effective C++ (3rd Ed.)</i>, non-virtual functio=
ns are supposed to represent <i>invariants over specialization</i>. Yet, C+=
+ currently offers no mechanism whereby a function can be flagged explicitl=
y as &quot;not to be redefined.&quot; <br><br>Following some great conversa=
tions at CppCon (the most illuminating=20
being one I had with stl), I&#39;d like to propose a new contextual keyword=
 that=20
would be closely related to final/override (and written similarly.) The bes=
t name I&#39;ve been able to think of so far for this new keyword is &quot;=
invariant.&quot;<br><br>Since &#39;final&#39; only applies to virtual funct=
ions, &#39;invariant&#39; would only be applicable to non-virtual functions=
, and make it an error to redefine the function in a derived class. <br></d=
iv></blockquote><div><br></div><div><br>Why not just reuse &#39;final&#39; =
then?<br><br></div><div>Tony<br><br></div><br></div><br></div></div>

<p></p>

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

--089e0158ad547cc9aa0503586a7a--

.

On 18 September 2014 18:12, Tony V E <tvaneerd@gmail.com> wrote:
>> Since 'final' only applies to virtual functions, 'invariant' would only be
>> applicable to non-virtual functions, and make it an error to redefine the
>> function in a derived class.
> Why not just reuse 'final' then?


That would confuse the meaning of 'final'. Clarifying question: is this facility
supposed to prevent a non-virtual function being hidden by an identical
signature, or any hiding signature? Consider

struct B
{
};

struct D : B
{
};

struct Base
{
    void f(const D&) nohide; // 'invariant'
};

struct Derived : Base
{
    void f(const B&); // ill-formed? well-formed?
};

If such hiding is meant to be ill-formed, and we would choose 'final'
for it, that
would be a breaking change.

--

---
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 18 September 2014 18:17, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> struct Base
> {
>     void f(const D&) nohide; // 'invariant'
> };
>
> struct Derived : Base
> {
>     void f(const B&); // ill-formed? well-formed?
> };
>
> If such hiding is meant to be ill-formed, and we would choose 'final'
> for it, that
> would be a breaking change.

Oh well, it wouldn't be a breaking change because decorating a non-virtual
function with 'final' is not currently valid. The question about which
signatures
are prevented still stands. And the follow-up question is whether this
hiding-prevention
would be allowed for both virtual and non-virtual functions, or just
the latter, and
whichever it is, why?

--

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

.

------=_Part_741_1019999169.1411080361976
Content-Type: text/plain; charset=UTF-8



On Thursday, September 18, 2014 11:12:45 AM UTC-4, Tony V E wrote:
>
>
> Why not just reuse 'final' then?
>
> Tony
>
>
That was my initial idea, to simply allow 'final' to apply to virtual
functions (as, for several years, I thought it actually did.)

stl opined that the final/override pair should be restricted to virtual
functions, and a new keyword would be needed. If it weren't for
"contextual" keywords, that would have been THAT, lol... but since we do
have cool contextual keywords, I now rather like the idea of coming up with
a new one that helps clarify intention.

In trying to play devil's advocate and argue for re-using 'final', I run
into some potential ambiguity. Consider:

struct B {
    virtual void f();
    virtual void g();
    void h();
};

struct D : B {
    void f() override final;  // Clearly virtual
    void g() final;              // Virtual?
    void h() final;              // Virtual?
};

A programmer reading D's definition would be thinking the following in
current C++:

f: Definitely virtual in B and D, invariant from here on down.
g: Definitely virtual in B and D, invariant from here on down (override is
not required, and wouldn't change anything)
h: This wouldn't compile, so even if they thought h was virtual in B,
they'd soon learn it isn't.

Now, if we extended 'final' to apply to non-virtual functions, then some
confusion ensues reading D's definition:

Is D::g() virtual? Answer: it depends on whether B::g() is or not. In this
case, yes, D::g() is virtual.

The case of h seems even more problematic. Reading both B and D's
definitions, it would be not at all clear what the intentions were/are:
a) Should B::h have been declared virtual (and therefore D::h's declaration
is missing an 'override')?
b)  Does it make any sense for B::h to even exist?

Most, but not all, of that ambiguity goes away if we use a different
keyword:

struct D : B {
    void f() override invariant;  // ERROR, can't be virtual and invariant
    void g() invariant;           // ERROR (same reason)
    void h() invariant;           // The only ambiguity remaining...
};

So in the case of h, now, we still don't know if B::h should even exist.
This would be a good place for the compiler to issue a warning in that
case. But I think the other issues all go away.

So I guess I've just convinced myself that a new keyword is better than
extending the meaning of 'final'. stl was right, IMO.





--

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

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

<div dir=3D"ltr"><br><br>On Thursday, September 18, 2014 11:12:45 AM UTC-4,=
 Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><br><div><div class=3D"gmail_quote"><div>Why not just reuse 'final' then=
?<br><br></div><div>Tony<br><br></div></div></div></div></blockquote><div><=
br>That was my initial idea, to simply allow 'final' to apply to virtual fu=
nctions (as, for several years, I thought it actually did.)<br><br>stl opin=
ed that the final/override pair should be restricted to virtual functions, =
and a new keyword would be needed. If it weren't for "contextual" keywords,=
 that would have been THAT, lol... but since we do have cool contextual key=
words, I now rather like the idea of coming up with a new one that helps cl=
arify intention. <br><br>In trying to play devil's advocate and argue for r=
e-using 'final', I run into some potential ambiguity. Consider:<br><br><spa=
n style=3D"font-family: courier new,monospace;">struct B {<br>&nbsp;&nbsp;&=
nbsp; virtual void f();<br>&nbsp;&nbsp;&nbsp; virtual void g();<br>&nbsp;&n=
bsp;&nbsp; void h();<br>};<br><br>struct D : B {<br>&nbsp;&nbsp;&nbsp; void=
 f() override final;&nbsp; // Clearly virtual<br>&nbsp;&nbsp;&nbsp; void g(=
) final;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; // =
Virtual?<br>&nbsp;&nbsp;&nbsp; void h() final;&nbsp;&nbsp;&nbsp; &nbsp;&nbs=
p;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp; // Virtual?<br>};</span><br><br>A progra=
mmer reading D's definition would be thinking the following in current C++:=
<br><br>f: Definitely virtual in B and D, invariant from here on down.<br>g=
: Definitely virtual in B and D, invariant from here on down (override is n=
ot required, and wouldn't change anything)<br>h: This wouldn't compile, so =
even if they thought h was virtual in B, they'd soon learn it isn't.<br><br=
>Now, if we extended 'final' to apply to non-virtual functions, then some c=
onfusion ensues reading D's definition:<br><br>Is D::g() virtual? Answer: i=
t depends on whether B::g() is or not. In this case, yes, D::g() is virtual=
..<br><br>The case of h seems even more problematic. Reading both B and D's =
definitions, it would be not at all clear what the intentions were/are:<br>=
a) Should B::h have been declared virtual (and therefore D::h's declaration=
 is missing an 'override')?<br>b)&nbsp; Does it make any sense for B::h to =
even exist?<br><br>Most, but not all, of that ambiguity goes away if we use=
 a different keyword:<br><br><span style=3D"font-family: courier new,monosp=
ace;">struct D : B {<br>&nbsp;&nbsp;&nbsp; void f() override invariant;&nbs=
p; // ERROR, can't be virtual and invariant<br>&nbsp;&nbsp;&nbsp; void g() =
invariant;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp; // ERROR (same=
 reason)<br>&nbsp;&nbsp;&nbsp; void h() invariant;&nbsp;&nbsp;&nbsp; &nbsp;=
&nbsp;&nbsp; &nbsp;&nbsp; // The only ambiguity remaining...<br>};</span><b=
r><br>So in the case of h, now, we still don't know if B::h should even exi=
st. This would be a good place for the compiler to issue a warning in that =
case. But I think the other issues all go away.<br><br>So I guess I've just=
 convinced myself that a new keyword is better than extending the meaning o=
f 'final'. stl was right, IMO.<br><br><br><br><br><br></div></div>

<p></p>

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

------=_Part_741_1019999169.1411080361976--

.

------=_Part_2231_2067702356.1411081032684
Content-Type: text/plain; charset=UTF-8



On Thursday, September 18, 2014 11:37:37 AM UTC-4, Ville Voutilainen wrote:
>
> The question about which signatures are prevented still stands. And the
> follow-up question is whether this
> hiding-prevention would be allowed for both virtual and non-virtual
> functions, or just the latter, and
> whichever it is, why?
>

One of the benefits of using a new contextual keyword is that the purpose
can be very targeted. Your example above is swaying me toward wanting
'invariant' to invalidate ALL signatures across the board.  If somebody
wants to mess with some sort of covariant scheme, power to them, they just
wouldn't use 'invariant' in he process ;-)

In my thinking, this decoration would only be used for non-virtual
functions...because that's the way to have invariants over specialization.

--

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

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

<div dir=3D"ltr"><br><br>On Thursday, September 18, 2014 11:37:37 AM UTC-4,=
 Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The q=
uestion about which
signatures
are prevented still stands. And the follow-up question is whether this
<br>hiding-prevention
would be allowed for both virtual and non-virtual functions, or just
the latter, and
<br>whichever it is, why?
<br></blockquote><div><br>One of the benefits of using a new contextual key=
word is that the purpose can be very targeted. Your example above is swayin=
g me toward wanting 'invariant' to invalidate ALL signatures across the boa=
rd.&nbsp; If somebody wants to mess with some sort of covariant scheme, pow=
er to them, they just wouldn't use 'invariant' in he process ;-)<br><br>In =
my thinking, this decoration would only be used for non-virtual functions..=
..because that's the way to have invariants over specialization. <br><br></d=
iv></div>

<p></p>

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

------=_Part_2231_2067702356.1411081032684--

.

On 19 September 2014 01:57, Leor Zolman <leorzolman@gmail.com> wrote:
> On Thursday, September 18, 2014 11:37:37 AM UTC-4, Ville Voutilainen wrote:
>> The question about which signatures are prevented still stands. And the
>> follow-up question is whether this
>> hiding-prevention would be allowed for both virtual and non-virtual
>> functions, or just the latter, and
>> whichever it is, why?
> One of the benefits of using a new contextual keyword is that the purpose
> can be very targeted. Your example above is swaying me toward wanting
> 'invariant' to invalidate ALL signatures across the board.  If somebody
> wants to mess with some sort of covariant scheme, power to them, they just
> wouldn't use 'invariant' in he process ;-)

Seems reasonable. Do remember, though, that whatever decision we make
for such a 'viral' facility, it's going to be hard to change that
decision afterwards
because such changes are always breaking. For example, if we decide that
ok, the keyword applies to functions only, and to non-virtual functions only,
it's bloody difficult to decide later that "oh, I guess it should
apply to virtual
functions as well".

> In my thinking, this decoration would only be used for non-virtual
> functions...because that's the way to have invariants over specialization.


Consider

struct B
{
    virtual void f(int);
};

struct D : B
{
    void f(double, double=0.0);
};


int main()
{
    D d;
    d.f(5);
}


D::f hides B::f. The call is not ambiguous. clang warns about the
hiding, gcc does not.
For such cases, it might be very beneficial to say "do not hide in
derived classes" for
virtual functions as well. You may end up in situations where
initially there is no
D::f, but such a function is added later, and then it changes the
meaning of code
silently. Being able to say that B::f can't be hidden would protect
from such mistakes.

As always, such a 'viral' facility needs to be used judiciously,
because sometimes
it's good that such injections of silent changes can be made, but that decision
is then made by the designer of B.

--

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

.

------=_Part_2353_1503115465.1411091326401
Content-Type: text/plain; charset=UTF-8

On Thursday, September 18, 2014 7:08:25 PM UTC-4, Ville Voutilainen wrote:

> Seems reasonable. Do remember, though, that whatever decision we make
> for such a 'viral' facility, it's going to be hard to change that
> decision afterwards
> because such changes are always breaking. For example, if we decide that
> ok, the keyword applies to functions only, and to non-virtual functions
> only,
> it's bloody difficult to decide later that "oh, I guess it should
> apply to virtual functions as well".
>
>
OK. Can I ask you, though, to please define the term "viral" as you're
using it here? I'm just not familiar with the word being used in the
context of a language feature. Thanks.


>
> Consider
>
> struct B
> {
>     virtual void f(int);
> };
>
> struct D : B
> {
>     void f(double, double=0.0);
> };
>
>
> int main()
> {
>     D d;
>     d.f(5);
> }
>
>
> D::f hides B::f. The call is not ambiguous. clang warns about the
> hiding, gcc does not.
> For such cases, it might be very beneficial to say "do not hide in
> derived classes" for
> virtual functions as well. You may end up in situations where
> initially there is no
> D::f, but such a function is added later, and then it changes the
> meaning of code
> silently. Being able to say that B::f can't be hidden would protect
> from such mistakes.
>

We may, then, actually have the need for two different keywords. My use of
'invariant' only makes sense for non-virtual functions. The other purpose
would be purely to disallow any form of hiding, hence perhaps 'nohide'.
This could apply to virtual functions (perhaps even non-virtual ones, to
offer a superset of 'invariant' functionality) plus many other types (data
members, enums, typedef/using, etc.)

At this point I'd need to know the use-cases for hiding. I've never seen
any (but that's more likely due to my need to get out of the house more
often, rather than my necessarily thinking it's a totally pointless
language capability.) If 'nohide' were to become part of the language, how
would its use in a base class potentially cause grief to a derived class
designer? I don't know. I'm less concerned about the  use of 'invariant' on
non-virtual functions... if a base class designer wants a non-virtual
function to be an invariant, the derived classes should be given no
opportunity to muck things up.



--

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

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

<div dir=3D"ltr">On Thursday, September 18, 2014 7:08:25 PM UTC-4, Ville Vo=
utilainen wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Seems reas=
onable. Do remember, though, that whatever decision we make
<br>for such a 'viral' facility, it's going to be hard to change that
<br>decision afterwards
<br>because such changes are always breaking. For example, if we decide tha=
t
<br>ok, the keyword applies to functions only, and to non-virtual functions=
 only,
<br>it's bloody difficult to decide later that "oh, I guess it should
<br>apply to virtual
functions as well".
<br>
<br></blockquote><div>&nbsp;</div><div>OK. Can I ask you, though, to please=
 define the term "viral" as you're using it here? I'm just not familiar wit=
h the word being used in the context of a language feature. Thanks. <br>&nb=
sp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Consider
<br>
<br>struct B
<br>{
<br>&nbsp; &nbsp; virtual void f(int);
<br>};
<br>
<br>struct D : B
<br>{
<br>&nbsp; &nbsp; void f(double, double=3D0.0);
<br>};
<br>
<br>
<br>int main()
<br>{
<br>&nbsp; &nbsp; D d;
<br>&nbsp; &nbsp; d.f(5);
<br>}
<br>
<br>
<br>D::f hides B::f. The call is not ambiguous. clang warns about the
<br>hiding, gcc does not.
<br>For such cases, it might be very beneficial to say "do not hide in
<br>derived classes" for
<br>virtual functions as well. You may end up in situations where
<br>initially there is no
<br>D::f, but such a function is added later, and then it changes the
<br>meaning of code
<br>silently. Being able to say that B::f can't be hidden would protect
<br>from such mistakes.
<br></blockquote><div><br>We may, then, actually have the need for two diff=
erent keywords. My use of 'invariant' only makes sense for non-virtual func=
tions. The other purpose would be purely to disallow any form of hiding, he=
nce perhaps 'nohide'. This could apply to virtual functions (perhaps even n=
on-virtual ones, to offer a superset of 'invariant' functionality) plus man=
y other types (data members, enums, typedef/using, etc.) <br><br>At this po=
int I'd need to know the use-cases for hiding. I've never seen any (but tha=
t's more likely due to my need to get out of the house more often, rather t=
han my necessarily thinking it's a totally pointless language capability.) =
If 'nohide' were to become part of the language, how would its use in a bas=
e class potentially cause grief to a derived class designer? I don't know. =
I'm less concerned about the&nbsp; use of 'invariant' on non-virtual functi=
ons... if a base class designer wants a non-virtual function to be an invar=
iant, the derived classes should be given no opportunity to muck things up.=
 <br><br><br><br></div></div>

<p></p>

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

------=_Part_2353_1503115465.1411091326401--

.

------=_Part_2418_1340099587.1411092180322
Content-Type: text/plain; charset=UTF-8

I meant to say this in my previous post above, but got distracted: I see a
potential issue with 'nohide' in that, generally speaking, MOST
declarations are meant "not to be hidden", so where exactly would a
programmer draw the line? Are some kinds of declarations "more likely" to
be hidden than others? Or, to the point, more likely to be hidden
inadvertently?

What would a style guide have to say, then, about what constitutes a
"stylish" use of 'nohide'? I don't have the answer. I'm thinking that there
may not BE an answer...


--

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

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

<div dir=3D"ltr">I meant to say this in my previous post above, but got dis=
tracted: I see a potential issue with 'nohide' in that, generally speaking,=
 MOST declarations are meant "not to be hidden", so where exactly would a p=
rogrammer draw the line? Are some kinds of declarations "more likely" to be=
 hidden than others? Or, to the point, more likely to be hidden inadvertent=
ly? <br><br>What would a style guide have to say, then, about what constitu=
tes a "stylish" use of 'nohide'? I don't have the answer. I'm thinking that=
 there may not BE an answer...<br><br><div dir=3D"ltr"><div><br></div></div=
></div>

<p></p>

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

------=_Part_2418_1340099587.1411092180322--

.

On 19 September 2014 04:48, Leor Zolman <leorzolman@gmail.com> wrote:
> OK. Can I ask you, though, to please define the term "viral" as you're using
> it here? I'm just not familiar with the word being used in the context of a
> language feature. Thanks.

It's referring to a language design facility where a design decision in a piece
of code restricts what design decisions other pieces of code can make,
especially
facilities where a design decision in a base class restricts the
design decisions
derived classes can make. Virtual functions are 'viral', especially destructors.
Final member functions are 'viral'. Virtual bases are 'viral'. This
'invariant' would
also be, in the same sense.

>> For such cases, it might be very beneficial to say "do not hide in
>> derived classes" for
>> virtual functions as well. You may end up in situations where
> We may, then, actually have the need for two different keywords. My use of
> 'invariant' only makes sense for non-virtual functions. The other purpose

Yes, in the sense that a virtual function would not establish a
similar invariant.
The question is, then, whether allowing the same keyword (whichever it may
be) on virtual functions as well is confusing and/or wrong, or whether it's
perhaps the right thing to do. :)

> At this point I'd need to know the use-cases for hiding. I've never seen any
> (but that's more likely due to my need to get out of the house more often,
> rather than my necessarily thinking it's a totally pointless language

This sort of hiding is an "escape hatch". Code like in my example is sometimes
(I bet not too often) used to change an interface of a function in a
class hierarchy.
Several design guideline authors like Meyers recommend against doing it,
but sometimes it may be necessary, especially in cases where the base classes
in the hierarchy are not easily modified (they may be part of a
library that can't
be modified for various reasons).

> capability.) If 'nohide' were to become part of the language, how would its
> use in a base class potentially cause grief to a derived class designer? I

Not necessarily in any way. While we were considering being able to mark
deliberate hiding functions, (see, for example,
http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3206.htm)
we thought it correct that a using-declaration would turn off facilities that
would diagnose the hiding cases. Perhaps we would want to do the
same here, for 'invariant' and/or 'nohide'. That way the decoration in the
becomes less 'viral' since its effects can be turned off.

> don't know. I'm less concerned about the  use of 'invariant' on non-virtual
> functions... if a base class designer wants a non-virtual function to be an
> invariant, the derived classes should be given no opportunity to muck things
> up.

That's a nice idea, but such designs where derived class authors have no
chance to state that they really really really _need_ to muck things up do not
always work well in practice. The whole facility becomes more palatable if
it's a "diagnose by default, people who know what they are doing can turn
off the diagnostic" rather than "establish a strict rule that cannot
be escaped".

See the paper linked above. The hiding control that was considered at that
time was not at all 'viral', it was pure opt-in for people who want
checks additional
to what the language traditionally provides. This proposal of yours is
fundamentally
less opt-in, although it can be made more so.

Also consider that there are existing ways to make sure the invariant
over class hierarchy
cannot be broken - you can detect it with tests, for example, or you
can static_assert
(in the base class) that the types of the addresses of B::f and D::f
are the same.

--

---
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 19 September 2014 05:03, Leor Zolman <leorzolman@gmail.com> wrote:
> I meant to say this in my previous post above, but got distracted: I see a
> potential issue with 'nohide' in that, generally speaking, MOST declarations
> are meant "not to be hidden", so where exactly would a programmer draw the
> line? Are some kinds of declarations "more likely" to be hidden than others?
> Or, to the point, more likely to be hidden inadvertently?

I'd say that things like assignment operators are more likely to be hidden
inadvertently than member functions that have actual names. I would also
expect that such operators are much more likely to be hidden deliberately.

> What would a style guide have to say, then, about what constitutes a
> "stylish" use of 'nohide'? I don't have the answer. I'm thinking that there
> may not BE an answer...

Well, I would realistically expect that a style guide would recommend it to be
used often. The cases where it shouldn't be used or where it should be allowed
to be bypassed are rare, I think. But they do exist.

--

---
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/.

.

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

On Fri, Sep 19, 2014 at 3:34 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 19 September 2014 05:03, Leor Zolman <leorzolman@gmail.com> wrote:
> > I meant to say this in my previous post above, but got distracted: I see
> a
> > potential issue with 'nohide' in that, generally speaking, MOST
> declarations
> > are meant "not to be hidden", so where exactly would a programmer draw
> the
> > line? Are some kinds of declarations "more likely" to be hidden than
> others?
> > Or, to the point, more likely to be hidden inadvertently?
>
> I'd say that things like assignment operators are more likely to be hidden
> inadvertently than member functions that have actual names. I would also
> expect that such operators are much more likely to be hidden deliberately.
>
> > What would a style guide have to say, then, about what constitutes a
> > "stylish" use of 'nohide'? I don't have the answer. I'm thinking that
> there
> > may not BE an answer...
>
> Well, I would realistically expect that a style guide would recommend it
> to be
> used often. The cases where it shouldn't be used or where it should be
> allowed
> to be bypassed are rare, I think. But they do exist.
>
>
If a style guide is likely to say "typically use keyword 'foo'" then can we
please always also have the opposite keyword 'xfoo' for the explicit
non-use cases?
ie
style guides often say:

- typically make constructors explicit
- typically make member functions const
- etc

So when I see a constructor that is NOT explicit, I can't tell whether that
was intentional or a mistake.
If we had an 'implicit' keyword, then the style guide could say

- typically mark constructors as 'explicit', otherwise mark them
'implicit'; never leave it unspecified.

That would make code reviews easier, and allow for automated checking.


If we have an 'invariant' keyword, and a common rule is "typically use
invariant", then we should also have a 'variant' keyword so coders can be
explicit about their intent when they go against the guidelines.

Tony



--
>
> ---
> 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/.
>

--

---
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/.

--089e0160b81e677fea05036badc3
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 Fri, Sep 19, 2014 at 3:34 AM, Ville Voutilainen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vo=
utilainen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><span class=3D"">On 19 September 2014 05:03, Leor Zolman &lt;<a href=3D"ma=
ilto:leorzolman@gmail.com">leorzolman@gmail.com</a>&gt; wrote:<br>
&gt; I meant to say this in my previous post above, but got distracted: I s=
ee a<br>
&gt; potential issue with &#39;nohide&#39; in that, generally speaking, MOS=
T declarations<br>
&gt; are meant &quot;not to be hidden&quot;, so where exactly would a progr=
ammer draw the<br>
&gt; line? Are some kinds of declarations &quot;more likely&quot; to be hid=
den than others?<br>
&gt; Or, to the point, more likely to be hidden inadvertently?<br>
<br>
</span>I&#39;d say that things like assignment operators are more likely to=
 be hidden<br>
inadvertently than member functions that have actual names. I would also<br=
>
expect that such operators are much more likely to be hidden deliberately.<=
br>
<span class=3D""><br>
&gt; What would a style guide have to say, then, about what constitutes a<b=
r>
&gt; &quot;stylish&quot; use of &#39;nohide&#39;? I don&#39;t have the answ=
er. I&#39;m thinking that there<br>
&gt; may not BE an answer...<br>
<br>
</span>Well, I would realistically expect that a style guide would recommen=
d it to be<br>
used often. The cases where it shouldn&#39;t be used or where it should be =
allowed<br>
to be bypassed are rare, I think. But they do exist.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>If a style guide is likely to say &quot;typically use keyword=
 &#39;foo&#39;&quot; then can we please always also have the opposite keywo=
rd &#39;xfoo&#39; for the explicit non-use cases?<br>ie<br></div><div>style=
 guides often say:<br><br></div><div>- typically make constructors explicit=
 <br></div><div>- typically make member functions const<br></div><div>- etc=
<br><br></div><div>So when I see a constructor that is NOT explicit, I can&=
#39;t tell whether that was intentional or a mistake.<br>If we had an &#39;=
implicit&#39; keyword, then the style guide could say<br></div><div><br>- t=
ypically mark constructors as &#39;explicit&#39;, otherwise mark them &#39;=
implicit&#39;; never leave it unspecified.<br><br></div><div>That would mak=
e code reviews easier, and allow for automated checking.<br><br><br></div><=
div>If we have an &#39;invariant&#39; keyword, and a common rule is &quot;t=
ypically use invariant&quot;, then we should also have a &#39;variant&#39; =
keyword so coders can be explicit about their intent when they go against t=
he guidelines.<br><br>Tony<br><br></div><div><br></div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><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></div>

<p></p>

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

--089e0160b81e677fea05036badc3--

.

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

On 19 September 2014 09:11, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> If a style guide is likely to say "typically use keyword 'foo'" then can
> we please always also have the opposite keyword 'xfoo' for the explicit
> non-use cases?
> ie
> style guides often say:
>
> - typically make constructors explicit
> - typically make member functions const
> - etc
>
> So when I see a constructor that is NOT explicit, I can't tell whether
> that was intentional or a mistake.
>

Why don't you just require comments in your style guide for those cases?
--
 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/.

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

<div dir=3D"ltr">On 19 September 2014 09:11, Tony V E <span dir=3D"ltr">&lt=
;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com=
</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote"><div>If a style guide is likely to =
say &quot;typically use keyword &#39;foo&#39;&quot; then can we please alwa=
ys also have the opposite keyword &#39;xfoo&#39; for the explicit non-use c=
ases?<br>ie<br></div><div>style guides often say:<br><br></div><div>- typic=
ally make constructors explicit <br></div><div>- typically make member func=
tions const<br></div><div>- etc<br><br></div><div>So when I see a construct=
or that is NOT explicit, I can&#39;t tell whether that was intentional or a=
 mistake.<br></div></div></div></div></blockquote><div><br></div><div>Why d=
on&#39;t you just require comments in your style guide for those cases?</di=
v></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

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

--f46d0421a9a56058f005036bd34d--

.

--14dae9cfc30a039cec05036beb46
Content-Type: text/plain; charset=UTF-8

On Fri, Sep 19, 2014 at 10:21 AM, Nevin Liber <nevin@eviloverlord.com>
wrote:

> On 19 September 2014 09:11, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>>
>> If a style guide is likely to say "typically use keyword 'foo'" then can
>> we please always also have the opposite keyword 'xfoo' for the explicit
>> non-use cases?
>> ie
>> style guides often say:
>>
>> - typically make constructors explicit
>> - typically make member functions const
>> - etc
>>
>> So when I see a constructor that is NOT explicit, I can't tell whether
>> that was intentional or a mistake.
>>
>
> Why don't you just require comments in your style guide for those cases?
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>

Explicit is almost always better. Why don't we go back to C style function
declarations without parameters?

Relying on comments makes it harder for me or the compiler to produce
warnings.  And you end up with a bunch of non-standard conventions.

If/When you have both 'implicit' and 'explicit' keywords, I expect my
compiler to offer a warning whenever neither is used.

Tony

--

---
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/.

--14dae9cfc30a039cec05036beb46
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 Fri, Sep 19, 2014 at 10:21 AM, Nevin Liber <span dir=3D"ltr">&lt;<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><span class=3D"">On 19 September 2014 09:11, Tony V E <span dir=3D"ltr">=
&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.=
com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=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"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div=
>If a style guide is likely to say &quot;typically use keyword &#39;foo&#39=
;&quot; then can we please always also have the opposite keyword &#39;xfoo&=
#39; for the explicit non-use cases?<br>ie<br></div><div>style guides often=
 say:<br><br></div><div>- typically make constructors explicit <br></div><d=
iv>- typically make member functions const<br></div><div>- etc<br><br></div=
><div>So when I see a constructor that is NOT explicit, I can&#39;t tell wh=
ether that was intentional or a mistake.<br></div></div></div></div></block=
quote><div><br></div></span><div>Why don&#39;t you just require comments in=
 your style guide for those cases?</div></div><span class=3D"HOEnZb"><font =
color=3D"#888888">-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt;=C2=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476=
911404" target=3D"_blank">(847) 691-1404</a>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br></div></div></blockquote></div><br></div><div class=3D"gmail_extra">=
Explicit is almost always better. Why don&#39;t we go back to C style funct=
ion declarations without parameters?<br><br></div><div class=3D"gmail_extra=
">Relying on comments makes it harder for me or the compiler to produce war=
nings.=C2=A0 And you end up with a bunch of non-standard conventions.<br><b=
r>If/When you have both &#39;implicit&#39; and &#39;explicit&#39; keywords,=
 I expect my compiler to offer a warning whenever neither is used.<br><br><=
/div><div class=3D"gmail_extra">Tony<br><br></div></div>

<p></p>

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

--14dae9cfc30a039cec05036beb46--

.

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

On 19 September 2014 09:28, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Fri, Sep 19, 2014 at 10:21 AM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>
>> On 19 September 2014 09:11, Tony V E <tvaneerd@gmail.com> wrote:
>>
>>>
>>>
>>> If a style guide is likely to say "typically use keyword 'foo'" then can
>>> we please always also have the opposite keyword 'xfoo' for the explicit
>>> non-use cases?
>>> ie
>>> style guides often say:
>>>
>>> - typically make constructors explicit
>>> - typically make member functions const
>>> - etc
>>>
>>> So when I see a constructor that is NOT explicit, I can't tell whether
>>> that was intentional or a mistake.
>>>
>>
>> Why don't you just require comments in your style guide for those cases?
>> --
>>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>>
>> --
>>
>
> Explicit is almost always better.
>

In your opinion.

I take it you don't believe in using mechanisms like overloaded functions?

Explicitness makes the code noisier.  Adding syntax has a high cost.
 Providing yet another way to spell a comment (we already have at least 4:
 /* */, //, [[ ]], #if 0) doesn't meet my burden of being worth the cost.


> Why don't we go back to C style function declarations without parameters?
>

C++ style function declarations are not comments; compilers must take
action if they don't match.

If you have any more straw man arguments to make, by all mean interject
them into this conversation.


> Relying on comments makes it harder for me or the compiler to produce
> warnings.
>

Why?  That's just a tooling issue, and not something covered by the
standard.

And you end up with a bunch of non-standard conventions.
>

Given that there is no universal C++ style guide endorsed by the C++
Committee, I don't see why that is a bad thing.

>
> If/When you have both 'implicit' and 'explicit' keywords, I expect my
> compiler to offer a warning whenever neither is used.
>

Again, why?  Not providing the implicit keyword is not incorrect.  What
precedence is there in the standard to require such behavior?  If it isn't
required, then it is just convention, and I don't see how adding it to the
standard helps anything, other than people who want to use the "appeal to
authority" argument by pointing to the standard as the blessed way of doing
things.

After all, if this is the behavior you want, one would expect the standard
itself to have every such function annotated.  We already have problems
with compilers warning about "struct" vs. "class" differences.  That seems
like a lot of work just for a comment.
--
 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/.

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

<div dir=3D"ltr">On 19 September 2014 09:28, Tony V E <span dir=3D"ltr">&lt=
;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com=
</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Fri, Sep =
19, 2014 at 10:21 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;</sp=
an> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D=
"h5"><div dir=3D"ltr"><span>On 19 September 2014 09:11, Tony V E <span dir=
=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvanee=
rd@gmail.com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div>If a =
style guide is likely to say &quot;typically use keyword &#39;foo&#39;&quot=
; then can we please always also have the opposite keyword &#39;xfoo&#39; f=
or the explicit non-use cases?<br>ie<br></div><div>style guides often say:<=
br><br></div><div>- typically make constructors explicit <br></div><div>- t=
ypically make member functions const<br></div><div>- etc<br><br></div><div>=
So when I see a constructor that is NOT explicit, I can&#39;t tell whether =
that was intentional or a mistake.<br></div></div></div></div></blockquote>=
<div><br></div></span><div>Why don&#39;t you just require comments in your =
style guide for those cases?</div></div><span><font color=3D"#888888">-- <b=
r>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevi=
n@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 =
<a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blan=
k">(847) 691-1404</a>
</font></span></div></div></div></div><div><div>

<p></p>

-- <br></div></div></blockquote></div><br></div><div class=3D"gmail_extra">=
Explicit is almost always better.</div></div></blockquote><div><br></div><d=
iv>In your opinion.=C2=A0</div><div><br></div><div>I take it you don&#39;t =
believe in using mechanisms like overloaded functions?</div><div><br></div>=
<div>Explicitness makes the code noisier. =C2=A0Adding syntax has a high co=
st. =C2=A0Providing yet another way to spell a comment (we already have at =
least 4: =C2=A0/* */, //, [[ ]], #if 0) doesn&#39;t meet my burden of being=
 worth the cost.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><div class=3D"gmail_extra">Why don&#39;t we go back to C style =
function declarations without parameters?<br></div></div></blockquote><div>=
<br></div><div>C++ style function declarations are not comments; compilers =
must take action if they don&#39;t match.</div><div><br></div><div>If you h=
ave any more straw man arguments to make, by all mean interject them into t=
his conversation.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_extra">Relying on comments makes it harder=
 for me or the compiler to produce warnings.=C2=A0 </div></div></blockquote=
><div><br></div><div>Why? =C2=A0That&#39;s just a tooling issue, and not so=
mething covered by the standard.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">And you end up with a =
bunch of non-standard conventions.<br></div></div></blockquote><div><br></d=
iv><div>Given that there is no universal C++ style guide endorsed by the C+=
+ Committee, I don&#39;t see why that is a bad thing.=C2=A0</div><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"></div><div=
 class=3D"gmail_extra"><br>If/When you have both &#39;implicit&#39; and &#3=
9;explicit&#39; keywords, I expect my compiler to offer a warning whenever =
neither is used.</div></div></blockquote><div><br></div><div>Again, why? =
=C2=A0Not providing the implicit keyword is not incorrect. =C2=A0What prece=
dence is there in the standard to require such behavior? =C2=A0If it isn&#3=
9;t required, then it is just convention, and I don&#39;t see how adding it=
 to the standard helps anything, other than people who want to use the &quo=
t;appeal to authority&quot; argument by pointing to the standard as the ble=
ssed way of doing things.</div><div><br></div><div>After all, if this is th=
e behavior you want, one would expect the standard itself to have every suc=
h function annotated. =C2=A0We already have problems with compilers warning=
 about &quot;struct&quot; vs. &quot;class&quot; differences. =C2=A0That see=
ms like a lot of work just for a comment.</div></div>-- <br>=C2=A0Nevin &qu=
ot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.co=
m" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

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

--047d7bae47b09b036605036e4d8a--

.

On 2014-09-19 10:28, Tony V E wrote:
> If/When you have both 'implicit' and 'explicit' keywords, I expect my
> compiler to offer a warning whenever neither is used.

OT, but I still very much want to see that happen :-). (I'm of the
opinion - as I think are many others - that explicit should have been
the default, with implicit requiring an annotation.)

That said, are there any feature requests to add this to any major
compiler via a private attribute? It seems it would be fairly easy to do
that and have folks writing preprocessor to define "implicit" as either
the appropriate attribute or nothing in order to give the feature some
exposure in the wild before canonization...

@Nevin, this relates to language issues where it's easy to forget an
annotation that was desired resulting in undesired behavior of the code.
Providing an annotation for "yes, I really meant to do that" and
deprecating (e.g. by having a compiler warning, at least to start) the
case of no annotation helps to avoid errors. This can apply to
initialization, non-const functions (I'm also in favor of allowing
'mutable' after a non-const member with a compiler diagnostic to
complain if it's missing), implicit ctors, shadowing, and possibly others.

Back on topic, an alternative could be that a member shadowing a member
from a base class would have an attribute that says "yes, I mean to do
this". This could possibly be instead an attribute (allowing it to apply
to any identifier) that would silence shadow warnings, which folks could
then promote to errors in their build environments.

--
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 24 September 2014 23:43, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> @Nevin, this relates to language issues where it's easy to forget an
> annotation that was desired resulting in undesired behavior of the code.
> Providing an annotation for "yes, I really meant to do that" and
> deprecating (e.g. by having a compiler warning, at least to start) the
> case of no annotation helps to avoid errors. This can apply to

I'm 100% sure that there will be heavy resistance to such deprecation.

> Back on topic, an alternative could be that a member shadowing a member
> from a base class would have an attribute that says "yes, I mean to do
> this". This could possibly be instead an attribute (allowing it to apply
> to any identifier) that would silence shadow warnings, which folks could
> then promote to errors in their build environments.


We had that in the override-controls papers. Previously with a
[[hiding]] attribute,
then in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
with an almost-contextual keyword (which happened to reuse an existing keyword,
aka 'new'). There's a fair amount of work to specify the various possibilities
of such hiding for member functions and data members and member types
and bitfields
and whatnot, and it gives us limited reward for such work. Due to the
various kinds
of hiding such a facility would provide, it's also a fair amount of
implementation
work to implement all the grammatical possibilities. ..unless, of
course, there will
be a new proposal that's more limited in scope. Personally I have no interest in
pushing one.

--

---
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/.

.

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

On 24 September 2014 15:43, Matthew Woehlke <mw_triad@users.sourceforge.net>
wrote:

> On 2014-09-19 10:28, Tony V E wrote:
> > If/When you have both 'implicit' and 'explicit' keywords, I expect my
> > compiler to offer a warning whenever neither is used.
>
> OT, but I still very much want to see that happen :-). (I'm of the
> opinion - as I think are many others - that explicit should have been
> the default, with implicit requiring an annotation.)
>

That ship sailed long, long ago...


> @Nevin, this relates to language issues where it's easy to forget an
> annotation that was desired resulting in undesired behavior of the code.
>

*shrug*  Unless you have a solution to the compatibility problem (has to
work with headers provided by vendors, has to work in environments where
every code change requires an expensive recertification of the software,
etc., etc.), it's a non-starter.


> Providing an annotation for "yes, I really meant to do that"


And when that becomes a pain point, tools will adjust so that people don't
have to think about it.

For instance, Java requires exception specifications for checked
exceptions, and instead of getting people to think about them, all that has
really changed is that editors like IntelliJ automatically write them into
the code so that developers don't have to.

Heck, I've even seen people alias "rm" to the more explicit "rm -i", and
all they do is blindly hit 'y <enter>' when removing files.


> and
> deprecating (e.g. by having a compiler warning, at least to start) the
> case of no annotation helps to avoid errors.


Do you sprinkle *every* function declaration in your code base with
noexcept specifications (true, false or conditional)?  Why not, if, y'know,
explicit is always better?

IMO, good defaults make things better; always being explicit just makes
things noisier.  For instance, I prefer that 90+% of my classes follow the
Rule of Zero instead of the always explicit Rule of Five.  That way, when
one is explicit it stands out.

And yes, I agree that C and C++ have some not-so-good defaults, but that
ship has sailed...
--
 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/.

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

<div dir=3D"ltr">On 24 September 2014 15:43, Matthew Woehlke <span dir=3D"l=
tr">&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"gmai=
l_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">On 20=
14-09-19 10:28, Tony V E wrote:<br>
&gt; If/When you have both &#39;implicit&#39; and &#39;explicit&#39; keywor=
ds, I expect my<br>
&gt; compiler to offer a warning whenever neither is used.<br>
<br>
</span>OT, but I still very much want to see that happen :-). (I&#39;m of t=
he<br>
opinion - as I think are many others - that explicit should have been<br>
the default, with implicit requiring an annotation.)<br></blockquote><div><=
br></div><div>That ship sailed long, long ago...</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
@Nevin, this relates to language issues where it&#39;s easy to forget an<br=
>
annotation that was desired resulting in undesired behavior of the code.<br=
></blockquote><div><br></div><div>*shrug* =C2=A0Unless you have a solution =
to the compatibility problem (has to work with headers provided by vendors,=
 has to work in environments where every code change requires an expensive =
recertification of the software, etc., etc.), it&#39;s a non-starter.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
Providing an annotation for &quot;yes, I really meant to do that&quot; </bl=
ockquote><div><br></div><div>And when that becomes a pain point, tools will=
 adjust so that people don&#39;t have to think about it.</div><div><br></di=
v><div>For instance, Java requires exception specifications for checked exc=
eptions, and instead of getting people to think about them, all that has re=
ally changed is that editors like IntelliJ automatically write them into th=
e code so that developers don&#39;t have to.</div><div><br></div><div>Heck,=
 I&#39;ve even seen people alias &quot;rm&quot; to the more explicit &quot;=
rm -i&quot;, and all they do is blindly hit &#39;y &lt;enter&gt;&#39; when =
removing files.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex">and<br>
deprecating (e.g. by having a compiler warning, at least to start) the<br>
case of no annotation helps to avoid errors.</blockquote><div><br></div><di=
v>Do you sprinkle <i>every</i> function declaration in your code base with =
noexcept specifications (true, false or conditional)?=C2=A0 Why not, if, y&=
#39;know, explicit is always better?</div><div><br></div><div>IMO, good def=
aults make things better; always being explicit just makes things noisier.=
=C2=A0 For instance, I prefer that 90+% of my classes follow the Rule of Ze=
ro instead of the always explicit Rule of Five.=C2=A0 That way, when one is=
 explicit it stands out.</div><div><br></div><div>And yes, I agree that C a=
nd C++ have some not-so-good defaults, but that ship has sailed...</div><di=
v>--=C2=A0<br></div></div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailt=
o:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

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

--f46d0438955586644c0503d6ef65--

.

On 2014-09-24 18:08, Nevin Liber wrote:
> On 24 September 2014 15:43, Matthew Woehlke wrote:
>> On 2014-09-19 10:28, Tony V E wrote:
>>> If/When you have both 'implicit' and 'explicit' keywords, I expect my
>>> compiler to offer a warning whenever neither is used.
>>
>> OT, but I still very much want to see that happen :-).
>>
>> @Nevin, this relates to language issues where it's easy to forget an
>> annotation that was desired resulting in undesired behavior of the code.
>
> *shrug*  Unless you have a solution to the compatibility problem (has to
> work with headers provided by vendors, has to work in environments where
> every code change requires an expensive recertification of the software,
> etc., etc.), it's a non-starter.

In the short term, I would expect this to be via a warning. This means
that the first problem is a non-issue (assuming you're using -isystem
appropriately), and for the second problem, just turn it off (or don't
use it; in the near term it would likely be opt-in rather than opt-out).

In the long run, I really think (in general) there needs to be a process
for phasing out (mis)features of the language. The usual way to do it is
gradually; to start with, continue to allow the old way but provide a
new alternative and encourage compiler authors to warn about the old
way. Most of the transition happens at the vendor level... start turning
the warning on by default, then make it an error by default. Eventually
the cost to remove the old way is sufficiently low that you can do so.

>> Providing an annotation for "yes, I really meant to do that"
>
> And when that becomes a pain point, tools will adjust so that people don't
> have to think about it.

Ideally by adding a -fexplicit-ctors option.

> Do you sprinkle *every* function declaration in your code base with
> noexcept specifications (true, false or conditional)?  Why not, if, y'know,
> explicit is always better?

That's a poor example. Implicit ctors should be the *exception*, not the
rule. An implicit ctor can be called when you don't expect, and as such,
is more deserving of annotation to make it stand out than an explicit ctor.

There is also a contradiction here; 'Foo(int)' is "magical" (implicit),
while 'Foo(int, int)' is not, despite that the former has no annotation
that tells the reader that it's special.

I also think you're missing the point. I want the compiler to help me
find bugs in my program. An implicit ctor that I didn't mean to be
implicit is a bug. I want the compiler to be able to tell me 'hey, did
you really mean this ctor to be implicit?' (which obviously implies
having a way to say 'yes, really I did'). This way, if I *didn't* mean
that, I am warned and have a chance to fix my code early, rather than it
being silently wrong and coming back to bite me later in a way that's
more difficult to track down.

(Naturally, all of the above applies to conversion operators also...)

--
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 25 September 2014 01:37, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> I also think you're missing the point. I want the compiler to help me
> find bugs in my program. An implicit ctor that I didn't mean to be
> implicit is a bug. I want the compiler to be able to tell me 'hey, did
> you really mean this ctor to be implicit?' (which obviously implies
> having a way to say 'yes, really I did'). This way, if I *didn't* mean
> that, I am warned and have a chance to fix my code early, rather than it
> being silently wrong and coming back to bite me later in a way that's
> more difficult to track down.
>
> (Naturally, all of the above applies to conversion operators also...)


There's no need to standardize anything for a compiler to be able to do that.
Mandating that a compiler has to do that is a completely different matter.
Changing the meaning of existing code just because we don't like the
style it was written or think that such style is error-prone
or dangerous (as correct as that may be) is difficult.

--

---
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-09-24 18:42, Ville Voutilainen wrote:
> On 25 September 2014 01:37, Matthew Woehlke wrote:
>> I also think you're missing the point. I want the compiler to help me
>> find bugs in my program. An implicit ctor that I didn't mean to be
>> implicit is a bug. I want the compiler to be able to tell me 'hey, did
>> you really mean this ctor to be implicit?' (which obviously implies
>> having a way to say 'yes, really I did'). This way, if I *didn't* mean
>> that, I am warned and have a chance to fix my code early, rather than it
>> being silently wrong and coming back to bite me later in a way that's
>> more difficult to track down.
>>
>> (Naturally, all of the above applies to conversion operators also...)
>
> There's no need to standardize anything for a compiler to be able to do that.

Sure. Hence my original question if anyone is implementing this, or has
asked to have this implemented, in some existing compiler. (I haven't,
yet, but it's on my mental to do list to file this as an RFE on GCC if
no one has done so already.)

Having a standardized mechanism for such annotation can *help*, as it
lessens the complexity of using the annotation and encourages compiler
vendors to provide the desired diagnostic, but as you correctly point
out, it's not strictly necessary.

--
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/.

.

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

On Fri, Sep 19, 2014 at 1:18 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 19 September 2014 09:28, Tony V E <tvaneerd@gmail.com> wrote:
>
>>
>>
>> On Fri, Sep 19, 2014 at 10:21 AM, Nevin Liber <nevin@eviloverlord.com>
>> wrote:
>>
>>> On 19 September 2014 09:11, Tony V E <tvaneerd@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> If a style guide is likely to say "typically use keyword 'foo'" then
>>>> can we please always also have the opposite keyword 'xfoo' for the explicit
>>>> non-use cases?
>>>> ie
>>>> style guides often say:
>>>>
>>>> - typically make constructors explicit
>>>> - typically make member functions const
>>>> - etc
>>>>
>>>> So when I see a constructor that is NOT explicit, I can't tell whether
>>>> that was intentional or a mistake.
>>>>
>>>
>>> Why don't you just require comments in your style guide for those cases?
>>> --
>>>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>>>
>>> --
>>>
>>
>> Explicit is almost always better.
>>
>
> In your opinion.
>
>
Very true.


> I take it you don't believe in using mechanisms like overloaded functions?
>
> Explicitness makes the code noisier.
>

Yes, explicitness is probably only needed in the cases where the existing
default is now seen as 'wrong', to most developers.


>  Adding syntax has a high cost.  Providing yet another way to spell a
> comment (we already have at least 4:  /* */, //, [[ ]], #if 0) doesn't meet
> my burden of being worth the cost.
>
>
>> Why don't we go back to C style function declarations without parameters?
>>
>
> C++ style function declarations are not comments; compilers must take
> action if they don't match.
>

Exactly.  Because we decided it should be that way.  But once upon a time
this was valid (at least in C):

    int f();

    int x = f(1, 2, 3);  // not an overload!

*Later* C decided that it would be better to be more explicit about params,
and make the compiler scream if it doesn't match up.



>
> If you have any more straw man arguments to make, by all mean interject
> them into this conversation
>

I'll try!


> .
>
>
>> Relying on comments makes it harder for me or the compiler to produce
>> warnings.
>>
>
> Why?  That's just a tooling issue, and not something covered by the
> standard.
>
> And you end up with a bunch of non-standard conventions.
>>
>
> Given that there is no universal C++ style guide endorsed by the C++
> Committee, I don't see why that is a bad thing.
>

The C++ language endorses a lot of style in many ways, some more subtle
than others.  Every language does.  Data-hiding is a 'style'.  C++ doesn't
_require_ you use it, but the language is written specifically to enable
it, and design decisions in the language and library promote it in various
ways.

So let's not say "explicit is almost always better", but just some of our
implicit defaults are seen as 'unfortunate' by today's modern 'style' - a
style we still don't enforce, but I suspect we'd like to promote, and do so
for new features.

The only question is whether "that ship has sailed" or are there ways of
slowing turning the ship.  Even if slowly takes another 20 years.


>
>> If/When you have both 'implicit' and 'explicit' keywords, I expect my
>> compiler to offer a warning whenever neither is used.
>>
>
> Again, why?  Not providing the implicit keyword is not incorrect.  What
> precedence is there in the standard to require such behavior?  If it isn't
> required, then it is just convention, and I don't see how adding it to the
> standard helps anything, other than people who want to use the "appeal to
> authority" argument by pointing to the standard as the blessed way of doing
> things.
>
> After all, if this is the behavior you want, one would expect the standard
> itself to have every such function annotated.  We already have problems
> with compilers warning about "struct" vs. "class" differences.  That seems
> like a lot of work just for a comment.
>

It is just a comment (at least to start) that could catch bugs at compile
time.  That is C++ 'style'.

If you were creating a new language, and had to decide whether constructors
should default to implicit or explicit, which would you choose?
What about uninitialized variables?

int x = uninitialized;  // explcitly uninitialized

If you could change C++ _very gradually_ why not?  Otherwise we will be
left with too much cruft and another language will pass us by.  Even with
all the new and exciting parts of C++, I worry about lack of adoption
because of the old stuff.  (Not so much explicit vs implicit, but
definitely uninitialized variables)


Tony

--

---
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/.

--047d7b3a82b02ee7270503e9baa0
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 Fri, Sep 19, 2014 at 1:18 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=
"><span class=3D"">On 19 September 2014 09:28, Tony V E <span dir=3D"ltr">&=
lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.c=
om</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=3D=
"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div=
>On Fri, Sep 19, 2014 at 10:21 AM, Nevin Liber <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.co=
m</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>=
<div><div dir=3D"ltr"><span>On 19 September 2014 09:11, Tony V E <span dir=
=3D"ltr">&lt;<a href=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvanee=
rd@gmail.com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div>If a =
style guide is likely to say &quot;typically use keyword &#39;foo&#39;&quot=
; then can we please always also have the opposite keyword &#39;xfoo&#39; f=
or the explicit non-use cases?<br>ie<br></div><div>style guides often say:<=
br><br></div><div>- typically make constructors explicit <br></div><div>- t=
ypically make member functions const<br></div><div>- etc<br><br></div><div>=
So when I see a constructor that is NOT explicit, I can&#39;t tell whether =
that was intentional or a mistake.<br></div></div></div></div></blockquote>=
<div><br></div></span><div>Why don&#39;t you just require comments in your =
style guide for those cases?</div></div><span><font color=3D"#888888">-- <b=
r>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevi=
n@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 =
<a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blan=
k">(847) 691-1404</a>
</font></span></div></div></div></div><div><div>

<p></p>

-- <br></div></div></blockquote></div><br></div><div class=3D"gmail_extra">=
Explicit is almost always better.</div></div></blockquote><div><br></div></=
span><div>In your opinion.=C2=A0</div><div><br></div></div></div></div></bl=
ockquote><div><br>Very true.<br>=C2=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<div></div><div>I take it you don&#39;t believe in using mechanisms like ov=
erloaded functions?</div><div><br></div><div>Explicitness makes the code no=
isier. </div></div></div></div></blockquote><div><br></div><div>Yes, explic=
itness is probably only needed in the cases where the existing default is n=
ow seen as &#39;wrong&#39;, to most developers.<br></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"><=
div class=3D"gmail_quote"><div>=C2=A0Adding syntax has a high cost.=C2=A0 P=
roviding yet another way to spell a comment (we already have at least 4: =
=C2=A0/* */, //, [[ ]], #if 0) doesn&#39;t meet my burden of being worth th=
e cost.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div class=3D"gmail_extra">Why don&#39;t we go back to =
C style function declarations without parameters?<br></div></div></blockquo=
te><div><br></div></span><div>C++ style function declarations are not comme=
nts; compilers must take action if they don&#39;t match.</div></div></div><=
/div></blockquote><div><br></div><div>Exactly.=C2=A0 Because we decided it =
should be that way.=C2=A0 But once upon a time this was valid (at least in =
C):<br><br></div><div>=C2=A0=C2=A0=C2=A0 int f();<br><br></div><div>=C2=A0=
=C2=A0=C2=A0 int x =3D f(1, 2, 3);=C2=A0 // not an overload!<br><br></div><=
div>*Later* C decided that it would be better to be more explicit about par=
ams, and make the compiler scream if it doesn&#39;t match up.<br><br></div>=
<div>=C2=A0<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 c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>If you =
have any more straw man arguments to make, by all mean interject them into =
this conversation</div></div></div></div></blockquote><div><br></div><div>I=
&#39;ll try!<br>=C2=A0<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>.</div><spa=
n class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra">Relying on comments makes it harder for me or=
 the compiler to produce warnings.=C2=A0 </div></div></blockquote><div><br>=
</div></span><div>Why?=C2=A0 That&#39;s just a tooling issue, and not somet=
hing covered by the standard.</div><span class=3D""><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">And you =
end up with a bunch of non-standard conventions.<br></div></div></blockquot=
e><div><br></div></span><div>Given that there is no universal C++ style gui=
de endorsed by the C++ Committee, I don&#39;t see why that is a bad thing.=
=C2=A0</div></div></div></div></blockquote><div><br></div><div>The C++ lang=
uage endorses a lot of style in many ways, some more subtle than others.=C2=
=A0 Every language does.=C2=A0 Data-hiding is a &#39;style&#39;.=C2=A0 C++ =
doesn&#39;t _require_ you use it, but the language is written specifically =
to enable it, and design decisions in the language and library promote it i=
n various ways.</div><br></div><div class=3D"gmail_quote">So let&#39;s not =
say &quot;explicit is almost always better&quot;, but just some of our impl=
icit defaults are seen as &#39;unfortunate&#39; by today&#39;s modern &#39;=
style&#39; - a style we still don&#39;t enforce, but I suspect we&#39;d lik=
e to promote, and do so for new features.<br><br>The only question is wheth=
er &quot;that ship has sailed&quot; or are there ways of slowing turning th=
e ship.=C2=A0 Even if slowly takes another 20 years.<br></div><div class=3D=
"gmail_quote"><div>=C2=A0<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"><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"></div><div class=3D"gmail_extra"><br>If/When you have both &#39;impli=
cit&#39; and &#39;explicit&#39; keywords, I expect my compiler to offer a w=
arning whenever neither is used.</div></div></blockquote><div><br></div></s=
pan><div>Again, why?=C2=A0 Not providing the implicit keyword is not incorr=
ect.=C2=A0 What precedence is there in the standard to require such behavio=
r?=C2=A0 If it isn&#39;t required, then it is just convention, and I don&#3=
9;t see how adding it to the standard helps anything, other than people who=
 want to use the &quot;appeal to authority&quot; argument by pointing to th=
e standard as the blessed way of doing things.</div><div><br></div><div>Aft=
er all, if this is the behavior you want, one would expect the standard its=
elf to have every such function annotated.=C2=A0 We already have problems w=
ith compilers warning about &quot;struct&quot; vs. &quot;class&quot; differ=
ences.=C2=A0 That seems like a lot of work just for a comment.</div></div><=
/div></div></blockquote><div><br></div><div>It is just a comment (at least =
to start) that could catch bugs at compile time.=C2=A0 That is C++ &#39;sty=
le&#39;.<br><br></div><div>If you were creating a new language, and had to =
decide whether constructors should default to implicit or explicit, which w=
ould you choose?<br></div><div>What about uninitialized variables?<br><br><=
/div><div>int x =3D uninitialized;=C2=A0 // explcitly uninitialized<br></di=
v><div><br>If you could change C++ _very gradually_ why not?=C2=A0 Otherwis=
e we will be left with too much cruft and another language will pass us by.=
=C2=A0 Even with all the new and exciting parts of C++, I worry about lack =
of adoption because of the old stuff.=C2=A0 (Not so much explicit vs implic=
it, but definitely uninitialized variables)<br></div><div>=C2=A0<br><br></d=
iv><div>Tony</div></div><br></div></div>

<p></p>

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

--047d7b3a82b02ee7270503e9baa0--

.