------=_Part_5153_31609901.1378355795782
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Expression templates can be confused and corrupted if a value intended as a=
=20
temporary is persisted using auto.

As a safety net, I propose to overload destructors on the condition of the=
=20
object having a name or a bound reference at the time of destruction. This=
=20
is intended to be equivalent to destruction at the end of a full-expression=
..

The overloads would be identified by ref-qualifiers: lvalue for the named=
=20
case, and rvalue for the unnamed case.

Destructors are looked up at the point of declaration. The point of=20
declaration of a temporary is somewhat hazy, but in many cases a temporary=
=20
is created as if a named variable were declared. Some rules would have to=
=20
elaborate that the destructor lookup of a temporary occurs at the point of=
=20
declaration, but with the knowledge of whether it is bound to a name at the=
=20
time of destruction, not considering informative pseudo-names in as-if=20
declarations.

template( typename t >
void bar( t && );

template< typename t >
void foo( t x ) { // Error: lvalue destructor of t x is deleted while=20
instantiating foo( a + b)
    auto sum1 =3D a + b; // Error: lvalue destructor of sum1 is deleted.
    auto && sum2 =3D a + b; // Error: lvalue destructor of sum2 is deleted.
    foo( a + b ); // This line is OK, but error occurs upon instantiation=
=20
of declaration of foo.
    auto && sum3 =3D std::move( a + b ); // Error: such tomfoolery does not=
=20
affect destructor lookup.

    // There remains a problem not covered by this proposal. Neither would=
=20
it be covered by operator auto (I think).
    // This is hard to distinguish from typical, valid cases inside the=20
expression template library implementation.
    bar( a + b ); // OK: bound to named reference, but its lifetime ends=20
before full-expression.
}

Another application would be sentry types or ScopeGuards which must be=20
bound to a persistent reference to work properly.

sentry( []{ work_list.clear(); } ); // Error: rvalue destructor is deleted.
auto guard1 =3D sentry( []{ work_list.clear(); } ); // Destructor deleted, =
or=20
static_assert in instantiation of rvalue destructor: Please bind to=20
reference; do not copy.
auto && guard2 =3D sentry( []{ work_list.clear(); } ); // OK

This has advantages over the operator auto semantic for expression=20
templates:

1. Less core language impact.
2. Also allows forbidding temporaries of certain types, such as the sentry=
=20
example.
3. Does not get in the way of internal expression template implementation=
=20
which might want auto without operator auto.
4. Works with non-auto type deduction as in typename t above, or any=20
convoluted case where the unevaluated-expression type finally propagates to=
=20
a concrete declaration.
5. Library support only involves declaring the extra destructor and=20
ref-qualifying the existing one. Backward compatibility may thus easily be=
=20
provided by the preprocessor.

The disadvantage versus operator auto is that the user doesn't get=20
automatic evaluation along with automatic type deduction. But this is not a=
=20
limitation; the evaluation must merely be performed using the explicit=20
facility that every such library already provides. The destructor provides=
=20
a hook for a diagnostic message to provide helpful instructions that=20
explicit evaluation is necessary =97 libraries already give such messages i=
n=20
other contexts. Following the directions, the resulting source code is=20
explicit about when evaluations occur, a positive outcome.

--=20

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

------=_Part_5153_31609901.1378355795782
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Expression templates can be confused and corrupted if a va=
lue intended as a temporary is persisted using <span style=3D"font-family: =
courier new,monospace;">auto</span>.<br><br>As a safety net, I propose to o=
verload destructors on the condition of the object having a name or a bound=
 reference at the time of destruction. This is intended to be equivalent to=
 destruction at the end of a full-expression.<br><br>The overloads would be=
 identified by ref-qualifiers: lvalue for the named case, and rvalue for th=
e unnamed case.<br><br>Destructors are looked up at the point of declaratio=
n. The point of declaration of a temporary is somewhat hazy, but in many ca=
ses a temporary is created as if a named variable were declared. Some rules=
 would have to elaborate that the destructor lookup of a temporary occurs a=
t the point of declaration, but with the knowledge of whether it is bound t=
o a name at the time of destruction, not considering informative pseudo-nam=
es in as-if declarations.<br><br><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">template</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>typename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> t </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">template</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> t x </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">// Error: lvalu=
e destructor of t x is deleted while instantiating foo( a + b)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> sum1 </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> a </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> b</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// Error: lvalue destructor of sum1 is deleted.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> sum2 </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// Error: lvalue dest=
ructor of sum2 is deleted.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp; foo</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> b </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #800;" class=3D"styled-by-prettify">// This line is OK, bu=
t error occurs upon instantiation of declaration of foo.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp;&nbsp;&nbsp; auto =
&amp;&amp; sum3 =3D std::move( a + b ); // Error: such tomfoolery does not =
affect destructor lookup.<br></span><br><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #=
800;" class=3D"styled-by-prettify">&nbsp;&nbsp;&nbsp; // There remains a pr=
oblem not covered by this proposal. Neither would it be covered by operator=
 auto (I think).</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>&nbsp;&nbsp;&nbsp; // This is hard to distinguish from typical, v=
alid cases inside the expression template library implementation.<br></span=
></code>&nbsp; &nbsp; bar</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// OK: bound to named reference, b=
ut its lifetime ends before full-expression.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span></code>}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><=
br>Another application would be sentry types or ScopeGuards which must be b=
ound to a persistent reference to work properly.<br><br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">sentry</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[]{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> work_list</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">clear</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">// Error: rvalue destructor is deleted.</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> guard1 </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> sentry</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[]{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> work_list</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c=
lear</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">// Destructor deleted, or static_assert in instantiation =
of rvalue destructor: Please bind to reference; do not copy.</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> guard2 </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> sentry</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[=
]{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> work_li=
st</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">clear</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// OK</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span></div></code></div><br>This has advantages over the <span style=3D=
"font-family: courier new,monospace;">operator auto</span> semantic for exp=
ression templates:<br><br>1. Less core language impact.<br>2. Also allows f=
orbidding temporaries of certain types, such as the sentry example.<br>3. D=
oes not get in the way of internal expression template implementation which=
 might want <span style=3D"font-family: courier new,monospace;">auto</span>=
 without <span style=3D"font-family: courier new,monospace;">operator auto<=
/span>.<br>4. Works with non-<span style=3D"font-family: courier new,monosp=
ace;">auto</span> type deduction as in <span style=3D"font-family: courier =
new,monospace;">typename t</span> above, or any convoluted case where the u=
nevaluated-expression type finally propagates to a concrete declaration.<br=
>5. Library support only involves declaring the extra destructor and ref-qu=
alifying the existing one. Backward compatibility may thus easily be provid=
ed by the preprocessor.<br><br>The disadvantage versus <span style=3D"font-=
family: courier new,monospace;">operator auto</span> is that the user doesn=
't get automatic evaluation along with automatic type deduction. But this i=
s not a limitation; the evaluation must merely be performed using the expli=
cit facility that every such library already provides. The destructor provi=
des a hook for a diagnostic message to provide helpful instructions that ex=
plicit evaluation is necessary =97 libraries already give such messages in =
other contexts. Following the directions, the resulting source code is expl=
icit about when evaluations occur, a positive outcome.<br></div>

<p></p>

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

------=_Part_5153_31609901.1378355795782--

.

------=_Part_499_27280797.1380008071111
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, September 5, 2013 12:36:35 AM UTC-4, David Krauss wrote:
>
> Expression templates can be confused and corrupted if a value intended as
> a temporary is persisted using auto.
>
> As a safety net, I propose to overload destructors on the condition of the
> object having a name or a bound reference at the time of destruction. This
> is intended to be equivalent to destruction at the end of a full-expression.
>
> The overloads would be identified by ref-qualifiers: lvalue for the named
> case, and rvalue for the unnamed case.
>

Wow, very interesting.  What happens with classes that use virtual
destructors?  Each one gets marked "virtual"?  Would "virtual" be limited
to when a single non-qualified destructor is used?  Can one destructor call
the other for implementation purposes, or do we have to use a common
anti-init function?

Daryle W.



--

---
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_499_27280797.1380008071111
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, September 5, 2013 12:36:35 AM UTC-4, David Kr=
auss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr">Expression templat=
es can be confused and corrupted if a value intended as a temporary is pers=
isted using <span style=3D"font-family: courier new,monospace;">auto</span>=
..<br><br>As a safety net, I propose to overload destructors on the conditio=
n of the object having a name or a bound reference at the time of destructi=
on. This is intended to be equivalent to destruction at the end of a full-e=
xpression.<br><br>The overloads would be identified by ref-qualifiers: lval=
ue for the named case, and rvalue for the unnamed case.</div></blockquote><=
div>&nbsp;</div><div>Wow, very interesting.&nbsp; What happens with classes=
 that use virtual destructors?&nbsp;&nbsp;Each one gets marked "virtual"?&n=
bsp; Would&nbsp;"virtual" be limited to when a single non-qualified destruc=
tor is used?&nbsp; Can one destructor call the other for implementation pur=
poses, or do we have to use a common anti-init function?</div><div>&nbsp;</=
div><div>Daryle W.</div><div>&nbsp;</div><div>&nbsp;</div></div>

<p></p>

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

------=_Part_499_27280797.1380008071111--

.

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

Am 05.09.2013 06:36 schrieb "David Krauss" <potswa@gmail.com>:
>
> Expression templates can be confused and corrupted if a value intended as
a temporary is persisted using auto.
>
> As a safety net, I propose to overload destructors on the condition of
the object having a name or a bound reference at the time of destruction.
This is intended to be equivalent to destruction at the end of a
full-expression.

As a library workaround with the caveat that only a runtime exception
(instead of compile time error) is generated, I would like to point out the
code at
http://stackoverflow.com/questions/13159739/how-to-disallow-temporaries/13168668#13168668.

Hope this link proves useful to some.

--

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

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

<p dir=3D"ltr"><br>
Am 05.09.2013 06:36 schrieb &quot;David Krauss&quot; &lt;<a href=3D"mailto:=
potswa@gmail.com">potswa@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; Expression templates can be confused and corrupted if a value intended=
 as a temporary is persisted using auto.<br>
&gt;<br>
&gt; As a safety net, I propose to overload destructors on the condition of=
 the object having a name or a bound reference at the time of destruction. =
This is intended to be equivalent to destruction at the end of a full-expre=
ssion.</p>

<p dir=3D"ltr">As a library workaround with the caveat that only a runtime =
exception (instead of compile time error) is generated, I would like to poi=
nt out the code at <a href=3D"http://stackoverflow.com/questions/13159739/h=
ow-to-disallow-temporaries/13168668#13168668">http://stackoverflow.com/ques=
tions/13159739/how-to-disallow-temporaries/13168668#13168668</a> .</p>

<p dir=3D"ltr">Hope this link proves useful to some.<br>
</p>

<p></p>

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

--047d7bd6b2ae65863c04e71c5453--

.

------=_Part_596_21774185.1380038196852
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Il giorno marted=EC 24 settembre 2013 09:46:07 UTC+2, Johannes Schaub ha=20
scritto:
>
> As a library workaround with the caveat that only a runtime exception=20
> (instead of compile time error) is generated, I would like to point out t=
he=20
> code at=20
> http://stackoverflow.com/questions/13159739/how-to-disallow-temporaries/1=
3168668#13168668.=20


correct me if I'm missing something, but that code guards the destruction=
=20
of a temporary, not its creation. The difference being that any=20
precondition violation ( potentially invoking UB ) resulting from the=20
lifetime extension of a temporary may not result in the runtime error being=
=20
fired ( it's undefined behavior, after all ). For example, consider a=20
supposed-to-be-temporary constructor taking a const or r-value reference to=
=20
a supposed-to-be-temporary argument; the premature death of the latter may=
=20
induce the former to read/write to a dangling reference ...=20

--=20

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

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

<div dir=3D"ltr">Il giorno marted=EC 24 settembre 2013 09:46:07 UTC+2, Joha=
nnes Schaub ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">As a li=
brary workaround with the caveat that only a runtime exception (instead of =
compile time error) is generated, I would like to point out the code at <a =
href=3D"http://stackoverflow.com/questions/13159739/how-to-disallow-tempora=
ries/13168668#13168668" target=3D"_blank">http://stackoverflow.com/<wbr>que=
stions/13159739/how-to-<wbr>disallow-temporaries/13168668#<wbr>13168668</a>=
 .

</blockquote><div><br>correct me if I'm missing something, but that code gu=
ards the destruction of a temporary, not its creation. The difference being=
 that any precondition violation ( potentially invoking UB ) resulting from=
 the lifetime extension of a temporary may not result in the runtime error =
being fired ( it's undefined behavior, after all ). For example, consider a=
 supposed-to-be-temporary constructor taking a const or r-value reference t=
o a supposed-to-be-temporary argument; the premature death of the latter ma=
y induce the former to read/write to a dangling reference ... <br></div></d=
iv>

<p></p>

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

------=_Part_596_21774185.1380038196852--

.

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

On 5 September 2013 07:36, David Krauss <potswa@gmail.com> wrote:

> Expression templates can be confused and corrupted if a value intended as
> a temporary is persisted using auto.
>
> As a safety net, I propose to overload destructors on the condition of the
> object having a name or a bound reference at the time of destruction. This
> is intended to be equivalent to destruction at the end of a full-expression.
>
>
 I do not think expression template misuse with auto is a reason to add
multiple destructors. There's an existing
proposal proposing an alternative fix, see
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3748.pdf
(Implicit Evaluation of "auto" Variables and Arguments)

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 September 2013 07:36, David Krauss <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Expressi=
on templates can be confused and corrupted if a value intended as a tempora=
ry is persisted using <span style=3D"font-family:courier new,monospace">aut=
o</span>.<br>
<br>As a safety net, I propose to overload destructors on the condition of =
the object having a name or a bound reference at the time of destruction. T=
his is intended to be equivalent to destruction at the end of a full-expres=
sion.<br>
<br></div></blockquote><div><br></div><div>=A0I do not think expression tem=
plate misuse with auto is a reason to add multiple destructors. There&#39;s=
 an existing<br>proposal proposing an alternative fix, see<br><a href=3D"ht=
tp://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3748.pdf">http://open-st=
d.org/JTC1/SC22/WG21/docs/papers/2013/n3748.pdf</a><br>
(Implicit Evaluation of &quot;auto&quot; Variables and Arguments)</div></di=
v><br></div></div>

<p></p>

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

--047d7b5d4396e9180304e7234620--

.

------=_Part_39_22772041.1380070417614
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Wednesday, September 25, 2013 12:03:26 AM UTC+8, Ville Voutilainen wrote=
:
>
>
>  I do not think expression template misuse with auto is a reason to add=
=20
> multiple destructors. There's an existing
> proposal proposing an alternative fix, see
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3748.pdf
> (Implicit Evaluation of "auto" Variables and Arguments)
>

 This is explicitly intended as an alternative to that proposal. I really=
=20
don't like the idea of complicating auto deduction. That proposal is a=20
breaking change and this one is not.

And, the present proposal has greater scope =97 it does more. See the=20
scope-guard use case.

--=20

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

------=_Part_39_22772041.1380070417614
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, September 25, 2013 12:03:26 AM UTC+8=
, Ville Voutilainen 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"ltr"><br><div>&nbsp;I do not think expression template misuse with =
auto is a reason to add multiple destructors. There's an existing<br><div c=
lass=3D"gmail_quote"><div>proposal proposing an alternative fix, see<br><a =
href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3748.pdf" targ=
et=3D"_blank">http://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2013/n374=
8.<wbr>pdf</a><br>
(Implicit Evaluation of "auto" Variables and Arguments)</div></div></div></=
div></blockquote><div><br>&nbsp;This is explicitly intended as an alternati=
ve to that proposal. I really don't like the idea of complicating <span sty=
le=3D"font-family: courier new,monospace;">auto</span> deduction. That prop=
osal is a breaking change and this one is not.<br><br>And, the present prop=
osal has greater scope =97 it does more. See the scope-guard use case.<br><=
br></div></div>

<p></p>

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

------=_Part_39_22772041.1380070417614--

.

------=_Part_5055_13343393.1380070853912
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Tuesday, September 24, 2013 11:56:36 PM UTC+8, MJanes wrote:
>
> Il giorno marted=EC 24 settembre 2013 09:46:07 UTC+2, Johannes Schaub ha=
=20
> scritto:
>>
>> As a library workaround with the caveat that only a runtime exception=20
>> (instead of compile time error) is generated, I would like to point out =
the=20
>> code at=20
>> http://stackoverflow.com/questions/13159739/how-to-disallow-temporaries/=
13168668#13168668.=20
>
>
> correct me if I'm missing something, but that code guards the destruction=
=20
> of a temporary, not its creation. The difference being that any=20
> precondition violation ( potentially invoking UB ) resulting from the=20
> lifetime extension of a temporary may not result in the runtime error bei=
ng=20
> fired ( it's undefined behavior, after all ).
>

When an object of non-dynamic storage duration is created, its destructor=
=20
is looked up and used, because destruction is inevitable. Although guarding=
=20
construction and guarding destruction merely differ by which line the=20
compiler diagnostic is "supposed" to point at, it is the construction that=
=20
would be guarded if the standardese changes were minimized.

I'm discussing compile-time errors, not runtime errors.=20

For example, consider a supposed-to-be-temporary constructor taking a const=
=20
> or r-value reference to a supposed-to-be-temporary argument; the prematur=
e=20
> death of the latter may induce the former to read/write to a dangling=20
> reference ...=20
>

You would never get to runtime because the program wouldn't have compiled.

--=20

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

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

<div dir=3D"ltr"><br><br>On Tuesday, September 24, 2013 11:56:36 PM UTC+8, =
MJanes wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Il giorno marted=EC 24 settembre 2013 09:46:07 UTC+2, Johannes Schaub ha sc=
ritto:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">As a library workaround with =
the caveat that only a runtime exception (instead of compile time error) is=
 generated, I would like to point out the code at <a href=3D"http://stackov=
erflow.com/questions/13159739/how-to-disallow-temporaries/13168668#13168668=
" target=3D"_blank">http://stackoverflow.com/<wbr>questions/13159739/how-to=
-<wbr>disallow-temporaries/13168668#<wbr>13168668</a> .

</blockquote><div><br>correct me if I'm missing something, but that code gu=
ards the destruction of a temporary, not its creation. The difference being=
 that any precondition violation ( potentially invoking UB ) resulting from=
 the lifetime extension of a temporary may not result in the runtime error =
being fired ( it's undefined behavior, after all ).</div></div></blockquote=
><div><br>When an object of non-dynamic storage duration is created, its=20
destructor is looked up and used, because destruction is inevitable.=20
Although guarding construction and guarding destruction merely differ by
 which line the compiler diagnostic is "supposed" to point at, it is the
 construction that would be guarded if the standardese changes were=20
minimized.<br><br>I'm discussing compile-time errors, not runtime errors. <=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div> For example, consider a supposed-to-be-temporary constructor taking a=
 const or r-value reference to a supposed-to-be-temporary argument; the pre=
mature death of the latter may induce the former to read/write to a danglin=
g reference ... <br></div></div></blockquote><div><br>You would never get t=
o runtime because the program wouldn't have compiled.<br><br></div></div>

<p></p>

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

------=_Part_5055_13343393.1380070853912--

.

------=_Part_541_12487428.1380072165569
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, September 24, 2013 3:34:31 PM UTC+8, Daryle Walker wrote:
>
> On Thursday, September 5, 2013 12:36:35 AM UTC-4, David Krauss wrote:
>>
>> Expression templates can be confused and corrupted if a value intended as
>> a temporary is persisted using auto.
>>
>> As a safety net, I propose to overload destructors on the condition of
>> the object having a name or a bound reference at the time of destruction.
>> This is intended to be equivalent to destruction at the end of a
>> full-expression.
>>
>> The overloads would be identified by ref-qualifiers: lvalue for the named
>> case, and rvalue for the unnamed case.
>>
>
> Wow, very interesting.  What happens with classes that use virtual
> destructors?  Each one gets marked "virtual"?  Would "virtual" be limited
> to when a single non-qualified destructor is used?  Can one destructor call
> the other for implementation purposes, or do we have to use a common
> anti-init function?
>

Good point; hadn't considered that. The above are the only use cases of
which I'm aware, and they don't really suggest use of virtual. But it's
still relevant since guard classes and expression template classes are both
likely candidates as bases.

It's illegal to overload a ref-qualified signature with an otherwise
identical ref-unqualified signature. The same rule should apply to
qualified destructors.

A ref-qualified derived destructor should call the corresponding base
destructor, obviously. Qualified destructors need to be implicitly defined
to make that happen in general. I think the rule should be that presence of
a qualified destructor in the base triggers implicit declaration in the
derived class, and then declaring an unqualified destructor would be an
illegal overload.

I see no reason not to allow one destructor to be virtual and the other
non-virtual. You can ref-qualify overload any member function and make it
virtual for just one value category of this. Rather cruel to the user, but
not a special case of language semantics.

--

---
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_541_12487428.1380072165569
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, September 24, 2013 3:34:31 PM UTC+8, D=
aryle Walker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Thursday, September 5, 2013 12:36:35 AM UTC-4, David Krauss wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr">Expression templates can be confused and =
corrupted if a value intended as a temporary is persisted using <span style=
=3D"font-family:courier new,monospace">auto</span>.<br><br>As a safety net,=
 I propose to overload destructors on the condition of the object having a =
name or a bound reference at the time of destruction. This is intended to b=
e equivalent to destruction at the end of a full-expression.<br><br>The ove=
rloads would be identified by ref-qualifiers: lvalue for the named case, an=
d rvalue for the unnamed case.</div></blockquote><div>&nbsp;</div><div>Wow,=
 very interesting.&nbsp; What happens with classes that use virtual destruc=
tors?&nbsp;&nbsp;Each one gets marked "virtual"?&nbsp; Would&nbsp;"virtual"=
 be limited to when a single non-qualified destructor is used?&nbsp; Can on=
e destructor call the other for implementation purposes, or do we have to u=
se a common anti-init function?</div></div></blockquote><div dir=3D"ltr"><b=
r>Good point; hadn't considered that. The above are the only use cases of w=
hich I'm aware, and they don't really suggest use of <span style=3D"font-fa=
mily: courier new,monospace;">virtual</span>. But it's still relevant since=
 guard classes and expression template classes are both likely candidates a=
s bases. <br><br>It's illegal to overload a ref-qualified signature with an=
 otherwise identical ref-unqualified signature. The same rule should apply =
to qualified destructors.<br><br>A ref-qualified derived destructor should =
call the corresponding base destructor, obviously. Qualified destructors ne=
ed to be implicitly defined to make that happen in general. I think the rul=
e should be that presence of a qualified destructor in the base triggers im=
plicit declaration in the derived class, and then declaring an unqualified =
destructor would be an illegal overload.<br><br>I see no reason not to allo=
w one destructor to be virtual and the other non-virtual. You can ref-quali=
fy overload any member function and make it virtual for just one value cate=
gory of <span style=3D"font-family: courier new,monospace;">this</span>. Ra=
ther cruel to the user, but not a special case of language semantics.<br><b=
r></div></div>

<p></p>

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

------=_Part_541_12487428.1380072165569--

.

------=_Part_203_6421671.1380092577716
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Il giorno mercoled=EC 25 settembre 2013 03:00:53 UTC+2, David Krauss ha=20
scritto:
>
>
> I'm discussing compile-time errors, not runtime errors.=20
> You would never get to runtime because the program wouldn't have compiled=
..
>

I know. In fact, mine was an answer to johannes's library workaround that=
=20
relied on a runtime guard on the temporary destructor ( I hope quotes are=
=20
visible, aren't them ?  ). Indeed, FWIW I agree that a compile time=20
solution would be useful ...

--=20

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

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

<div dir=3D"ltr">Il giorno mercoled=EC 25 settembre 2013 03:00:53 UTC+2, Da=
vid Krauss ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div>I'm discussing compile-time errors, not runtime errors. <=
br>You would never get to runtime because the program wouldn't have compile=
d.<br></div></div></blockquote><div><br>I know. In fact, mine was an answer=
 to johannes's library workaround that relied on a runtime guard on the tem=
porary destructor ( I hope quotes are visible, aren't them ?&nbsp; ). Indee=
d, FWIW I agree that a compile time solution would be useful ...<br></div><=
/div>

<p></p>

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

------=_Part_203_6421671.1380092577716--

.

--001a11c227e8cd705804e73074ad
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 25 September 2013 03:53, David Krauss <potswa@gmail.com> wrote:

>
>
> On Wednesday, September 25, 2013 12:03:26 AM UTC+8, Ville Voutilainen
> wrote:
>>
>>
>>  I do not think expression template misuse with auto is a reason to add
>> multiple destructors. There's an existing
>> proposal proposing an alternative fix, see
>> http://open-std.org/JTC1/SC22/**WG21/docs/papers/2013/n3748.**pdf<http:/=
/open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3748.pdf>
>> (Implicit Evaluation of "auto" Variables and Arguments)
>>
>
>  This is explicitly intended as an alternative to that proposal. I really
> don't like the idea of complicating auto deduction. That proposal is a
> breaking change and this one is not.
>
> And, the present proposal has greater scope =97 it does more. See the
> scope-guard use case.
>
>
Regarding "this one is not" - introducing multiple overloads of destructors
is a breaking change
of a magnitude I have never seen before. So I disagree with that
assessment. To elaborate:
it fundamentally breaks the model we have had for decades about cleanup
having a very
simple and single exit in all cases. You can color me forever opposed to
any proposals
that even insinuate adding any kinds of destructor overloads.

The proposal about an alternative way to achieve the ability to control
type conversion
under deduction is not set in stone, and is not necessarily going to be a
breaking change.

--=20

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

--001a11c227e8cd705804e73074ad
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 September 2013 03:53, David Krauss <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br><br>O=
n Wednesday, September 25, 2013 12:03:26 AM UTC+8, Ville Voutilainen wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div>=A0I do not think expression template misuse with=
 auto is a reason to add multiple destructors. There&#39;s an existing<br><=
div class=3D"gmail_quote"><div>proposal proposing an alternative fix, see<b=
r>
<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3748.pdf" t=
arget=3D"_blank">http://open-std.org/JTC1/SC22/<u></u>WG21/docs/papers/2013=
/n3748.<u></u>pdf</a><br>
(Implicit Evaluation of &quot;auto&quot; Variables and Arguments)</div></di=
v></div></div></blockquote></div><div><br>=A0This is explicitly intended as=
 an alternative to that proposal. I really don&#39;t like the idea of compl=
icating <span style=3D"font-family:courier new,monospace">auto</span> deduc=
tion. That proposal is a breaking change and this one is not.<br>
<br>And, the present proposal has greater scope =97 it does more. See the s=
cope-guard use case.<br><br></div></div></blockquote><div><br></div><div>Re=
garding &quot;this one is not&quot; - introducing multiple overloads of des=
tructors is a breaking change<br>
of a magnitude I have never seen before. So I disagree with that assessment=
.. To elaborate:<br></div><div>it fundamentally breaks the model we have had=
 for decades about cleanup having a very<br>simple and single exit in all c=
ases. You can color me forever opposed to any proposals<br>
</div><div>that even insinuate adding any kinds of destructor overloads.<br=
><br></div><div>The proposal about an alternative way to achieve the abilit=
y to control type conversion<br></div><div>under deduction is not set in st=
one, and is not necessarily going to be a breaking change.<br>
</div></div><br></div></div>

<p></p>

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

--001a11c227e8cd705804e73074ad--

.

------=_Part_32_3057659.1380101413907
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, September 25, 2013 3:46:50 PM UTC+8, Ville Voutilainen wrote:
>
>
> Regarding "this one is not" - introducing multiple overloads of
> destructors is a breaking change
> of a magnitude I have never seen before.
>

Unless I'm mistaken, "breaking change" refers to breaking existing code. operator
auto() breaks generic code that assumes auto and function argument type
deduction are equivalent to template argument type deduction, and requires
it to change to explicit auto. My proposal could only break code that
expects to generically inherit from a user class and define a destructor.
This is way way way less common than generic use of auto or just plain
deduced types.

As for generic code that breaks because it calls a deleted destructor, that
would only happen as a purposeful diagnostic. That's surely a good thing.

Providing a recourse to generic code that is already broken against
expression templates is a noble intent, and I haven't addressed that. But
it seems to me that can be done without a core language change. A generic
evaluation facility can be provided through the library as std::evaluate(),
for example. (This would interface with the expression template library to
call the appropriate function, if necessary.)


> So I disagree with that assessment. To elaborate:
> it fundamentally breaks the model we have had for decades about cleanup
> having a very
> simple and single exit in all cases.
>

The destructor is chosen based on whether the given object is (for its
entire lifetime) bound to a name or not. There is a single exit for each
object. No runtime logic, and no context applies except for whether the
object is named or a lifetime-extended temporary.

And for all the use cases I see so far, in fact there is just one
destructor. The opposing one is deleted.


> You can color me forever opposed to any proposals
> that even insinuate adding any kinds of destructor overloads.
>

If this proposal fills the gap, with very narrow and strict semantics, then
you don't need to worry about any wackier proposals trying to fill the same
space. :v)


> The proposal about an alternative way to achieve the ability to control
> type conversion
> under deduction is not set in stone, and is not necessarily going to be a
> breaking change.
>

Introducing conversion into deduction and not breaking anything?

--

---
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_32_3057659.1380101413907
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, September 25, 2013 3:46:50 PM UTC+8,=
 Ville Voutilainen 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"ltr"><br><div>Regarding "this one is not" - introducing multiple ove=
rloads of destructors is a breaking change<br><div class=3D"gmail_quote"><d=
iv>
of a magnitude I have never seen before.</div></div></div></div></blockquot=
e><div><br>Unless I'm mistaken, "breaking change" refers to breaking existi=
ng code. <span style=3D"font-family: courier new,monospace;">operator auto(=
)</span> breaks generic code that assumes <span style=3D"font-family: couri=
er new,monospace;">auto</span> and function argument type deduction are equ=
ivalent to template argument type deduction, and requires it to change to <=
span style=3D"font-family: courier new,monospace;">explicit auto</span>. My=
 proposal could only break code that expects to generically inherit from a =
user class and define a destructor. This is way way way less common than ge=
neric use of auto or just plain deduced types.<br><br>As for generic code t=
hat breaks because it calls a deleted destructor, that would only happen as=
 a purposeful diagnostic. That's surely a good thing.<br><br>Providing a re=
course to generic code that is already broken against expression templates =
is a noble intent, and I haven't addressed that. But it seems to me that ca=
n be done without a core language change. A generic evaluation facility can=
 be provided through the library as <span style=3D"font-family: courier new=
,monospace;">std::evaluate()</span>, for example. (This would interface wit=
h the expression template library to call the appropriate function, if nece=
ssary.)<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote"><div> So I disagree with that ass=
essment. To elaborate:<br></div><div>it fundamentally breaks the model we h=
ave had for decades about cleanup having a very<br>simple and single exit i=
n all cases.</div></div></div></div></blockquote><div><br>The destructor is=
 chosen based on whether the given object is (for its entire lifetime) boun=
d to a name or not. There is a single exit for each object. No runtime logi=
c, and no context applies except for whether the object is named or a lifet=
ime-extended temporary.<br><br>And for all the use cases I see so far, in f=
act there is just one destructor. The opposing one is deleted.<br>&nbsp;</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div> You can color me forever opposed to any proposa=
ls<br>
</div><div>that even insinuate adding any kinds of destructor overloads.<br=
></div></div></div></div></blockquote><div><br>If this proposal fills the g=
ap, with very narrow and strict semantics, then you don't need to worry abo=
ut any wackier proposals trying to fill the same space. :v)<br>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><div>The proposal about an alternative way to achieve th=
e ability to control type conversion<br></div><div>under deduction is not s=
et in stone, and is not necessarily going to be a breaking change.<br>
</div></div></div></div></blockquote><div>&nbsp;<br>Introducing conversion =
into deduction and not breaking anything?<br></div></div>

<p></p>

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

------=_Part_32_3057659.1380101413907--

.