What if discarded-value expressions of class type invoked an optional opera=
tor void() conversion function?

Useful:

Definition as =3D delete would forbid the discard.

A function could return a status value and throw an exception if it is unus=
ed, without overhead. (The inspiration was the allocator resize proposal, w=
hich throws for any failed resize, which seems quite excessive.)

Definition as =3D default could suppress the warning in extremely strict st=
yles that forbid implicit discarding.

Expression templates could use such a hook to invoke evaluation.

Seemingly less useful:

If non-const only, then const objects could not be discarded.

Definition as volatile =3D default could, with a volatile copy constructor,=
 copy the object to a temporary, which would perhaps be discarded, creating=
 an endless loop. A corner case to be sure, but maybe a sign that this is a=
ll harebrained.

It could be abused to make an ugly kind of functor which executes when mere=
ly named as a complete expression-statement, particularly with lvalue refer=
ence qualification.

=97=97=97

On a related note, what do folks think about declaring a destructor explici=
t to suppress the unused variable warning? There needn't be any semantic me=
aning. This would remove an unnecessary wart from my scope guard class, and=
 would do likewise for the one under official proposal.

I'm a bit woozy with flu so forgive if this is really insane.

--=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_1654_1170382.1378101637041
Content-Type: text/plain; charset=ISO-8859-1

David,

What if discarded-value expressions of class type invoked an optional
> operator void() conversion function?
>

Why not? Indeed, void can't be used in an expression, and can't be used as
a parameter. Type void can be used as a template argument, though. Would
that break templates using conversion to T?

A function could return a status value and throw an exception if it is
> unused, without overhead. (The inspiration was the allocator resize
> proposal, which throws for any failed resize, which seems quite excessive.)
>

You mean, the class implementing the status would throw an exception on
conversion to void?

Definition as = delete would forbid the discard.
>
> Definition as = default could suppress the warning in extremely strict
> styles that forbid implicit discarding.
>

OK about = delete, unsure about = default. Indeed, I think the default
should not change existing code, so the semantics would have operator
void() = default as the implicit meaning. I would not forbid it, though.
But I propose explicit operator void() to force the programmer to
explicitly ignore a returned value :)

Expression templates could use such a hook to invoke evaluation.
>

 Could you come up with a little example?

Seemingly less useful:
>
> If non-const only, then const objects could not be discarded.

Definition as volatile = default could, with a volatile copy constructor,
> copy the object to a temporary, which would perhaps be discarded, creating
> an endless loop. A corner case to be sure, but maybe a sign that this is
> all harebrained.
>
It could be abused to make an ugly kind of functor which executes when
> merely named as a complete expression-statement, particularly with lvalue
> reference qualification.
>

Examples ? :)

I think it's an idea worth digging.

Laurent

--

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

<div dir=3D"ltr">David,<br><br><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>What if discarded-value expressions of class type invoked an optional oper=
ator void() conversion function?
<br></blockquote><div>&nbsp;<br>Why not? Indeed, void can't be used in an e=
xpression, and can't be used as a parameter. Type void can be used as a tem=
plate argument, though. Would that break templates using conversion to T?<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">A function could r=
eturn a status value and throw an exception if it is unused, without overhe=
ad. (The inspiration was the allocator resize proposal, which throws for an=
y failed resize, which seems quite excessive.)
<br></blockquote><div>&nbsp;<br>You mean, the class implementing the status=
 would throw an exception on conversion to void?<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">Definition as =3D delete would forbid the d=
iscard.
<br>
<br>Definition as =3D default could suppress the warning in extremely stric=
t styles that forbid implicit discarding.
<br></blockquote><div>&nbsp;<br>OK about <span style=3D"font-family: courie=
r new,monospace;">=3D delete</span>, unsure about <span style=3D"font-famil=
y: courier new,monospace;">=3D default</span>. Indeed, I think the default =
should not change existing code, so the semantics would have <span style=3D=
"font-family: courier new,monospace;">operator void() =3D default</span> as=
 the implicit meaning. I would not forbid it, though. But I propose <span s=
tyle=3D"font-family: courier new,monospace;">explicit operator void()</span=
> to force the programmer to explicitly ignore a returned value :)<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Expression templates coul=
d use such a hook to invoke evaluation.
<br></blockquote><div><br>&nbsp;Could you come up with a little example?<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Seemingly less usef=
ul:
<br>
<br>If non-const only, then const objects could not be discarded.
&nbsp;</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Definition =
as volatile =3D default could, with a volatile copy constructor, copy the o=
bject to a temporary, which would perhaps be discarded, creating an endless=
 loop. A corner case to be sure, but maybe a sign that this is all harebrai=
ned.
<br></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">It=
 could be abused to make an ugly kind of functor which executes when merely=
 named as a complete expression-statement, particularly with lvalue referen=
ce qualification.<br></blockquote><div><br>Examples ? :)<br><br>I think it'=
s an idea worth digging.<br><br>Laurent<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_1654_1170382.1378101637041--

.

------=_Part_106_14826830.1378106439301
Content-Type: text/plain; charset=ISO-8859-1



On Monday, September 2, 2013 2:00:36 PM UTC+8, the.ultim...@gmail.com wrote:
>
> David,
>
> What if discarded-value expressions of class type invoked an optional
>> operator void() conversion function?
>>
>
> Why not? Indeed, void can't be used in an expression, and can't be used as
> a parameter. Type void can be used as a template argument, though. Would
> that break templates using conversion to T?
>

If you mean the is_convertible trait, then I think it's OK but it could be
controversial. IIRC is_convertible checks for convertibility in the context
of a return value expression. This disqualifies convertibility to void ever
being true, and supplying an operator void couldn't change that.


> A function could return a status value and throw an exception if it is
>> unused, without overhead. (The inspiration was the allocator resize
>> proposal, which throws for any failed resize, which seems quite excessive.)
>>
>
> You mean, the class implementing the status would throw an exception on
> conversion to void?
>

Yes, the return value would have to be a proxy object.


> Definition as = delete would forbid the discard.
>>
>> Definition as = default could suppress the warning in extremely strict
>> styles that forbid implicit discarding.
>>
>
> OK about = delete, unsure about = default. Indeed, I think the default
> should not change existing code, so the semantics would have operator
> void() = default as the implicit meaning. I would not forbid it, though.
> But I propose explicit operator void() to force the programmer to
> explicitly ignore a returned value :)
>

Yes, by "suppress the warning" I mean exactly and only that. There are
compilers that will emit a diagnostic if you write foo() as opposed to (void)
foo(), requiring an explicit cast to compile quietly.

The idea of a warning isn't standardized, and I don't think this is a good
place to start, which is why I didn't mention explicit.


> Expression templates could use such a hook to invoke evaluation.
>>
>
>  Could you come up with a little example?
>

Not off the top of my head. It would give a library a hook indicating a
full-expression as opposed to a subexpression. Most expression templates
work their magic upon conversion to a concrete type. But expression
template applications are mostly mathematical in nature, with functional as
opposed to imperative semantics. So most results are converted to
something. Although I can't think of any template expression would also be
a useful full-expression, I'd bet that a use case exists.


> Seemingly less useful:
>>
>> If non-const only, then const objects could not be discarded.
>
> Definition as volatile = default could, with a volatile copy constructor,
>> copy the object to a temporary, which would perhaps be discarded, creating
>> an endless loop. A corner case to be sure, but maybe a sign that this is
>> all harebrained.
>>
> It could be abused to make an ugly kind of functor which executes when
>> merely named as a complete expression-statement, particularly with lvalue
>> reference qualification.
>>
>
> Examples ? :)
>

I'd rather not :) . Throwing volatile around is just asking for trouble.
Returning to the idea now, void can be cv-qualified, so allowing operator
void() would perhaps require disallowing operator void volatile().

The last instance might bear mentioning. For example with the above
throwing status proxy type, if you have an object obj of such type, the
expression statement obj; would throw the exception. Such statements
usually flag "unused value" warnings, but with this language feature, the
compiler would have a tough choice because the value *is* getting used. I
don't think many people could write that just by accident, but maybe I
overestimate people.

--

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

<div dir=3D"ltr"><br><br>On Monday, September 2, 2013 2:00:36 PM UTC+8, the=
..ultim...@gmail.com 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">David,<br><br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">What if =
discarded-value expressions of class type invoked an optional operator void=
() conversion function?
<br></blockquote><div>&nbsp;<br>Why not? Indeed, void can't be used in an e=
xpression, and can't be used as a parameter. Type void can be used as a tem=
plate argument, though. Would that break templates using conversion to T?<b=
r></div></div></blockquote><div><br>If you mean the <span style=3D"font-fam=
ily: courier new,monospace;">is_convertible</span> trait, then I think it's=
 OK but it could be controversial. IIRC <span style=3D"font-family: courier=
 new,monospace;">is_convertible</span> checks for convertibility in the con=
text of a return value expression. This disqualifies <span style=3D"font-fa=
mily: arial,sans-serif;">convertibility</span> to void ever being true, and=
 supplying an <span style=3D"font-family: courier new,monospace;">operator =
void</span> couldn't change that.<br>&nbsp;</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>A function could return a status value and throw an exception if it is unu=
sed, without overhead. (The inspiration was the allocator resize proposal, =
which throws for any failed resize, which seems quite excessive.)
<br></blockquote><div>&nbsp;<br>You mean, the class implementing the status=
 would throw an exception on conversion to void?<br></div></div></blockquot=
e><div><br>Yes, the return value would have to be a proxy object.<br>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">Definition as =3D delete would forbid the =
discard.
<br>
<br>Definition as =3D default could suppress the warning in extremely stric=
t styles that forbid implicit discarding.
<br></blockquote><div>&nbsp;<br>OK about <span style=3D"font-family:courier=
 new,monospace">=3D delete</span>, unsure about <span style=3D"font-family:=
courier new,monospace">=3D default</span>. Indeed, I think the default shou=
ld not change existing code, so the semantics would have <span style=3D"fon=
t-family:courier new,monospace">operator void() =3D default</span> as the i=
mplicit meaning. I would not forbid it, though. But I propose <span style=
=3D"font-family:courier new,monospace">explicit operator void()</span> to f=
orce the programmer to explicitly ignore a returned value :)<br></div></div=
></blockquote><div><br>Yes, by "suppress the warning" I mean exactly and on=
ly that. There are compilers that will emit a diagnostic if you write <span=
 style=3D"font-family: courier new,monospace;">foo()</span> as opposed to <=
span style=3D"font-family: courier new,monospace;">(void) foo()</span>, req=
uiring an explicit cast to compile quietly.<br><br>The idea of a warning is=
n't standardized, and I don't think this is a good place to start, which is=
 why I didn't mention <span style=3D"font-family: courier new,monospace;">e=
xplicit</span>.<br>&nbsp;<br></div><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"><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Expression t=
emplates could use such a hook to invoke evaluation.
<br></blockquote><div><br>&nbsp;Could you come up with a little example?<br=
></div></div></blockquote><div><br>Not off the top of my head. It would giv=
e a library a hook indicating a full-expression as opposed to a subexpressi=
on. Most expression templates work their magic upon conversion to a concret=
e type. But expression template applications are mostly mathematical in nat=
ure, with functional as opposed to imperative semantics. So most results ar=
e converted to something. Although I can't think of any template expression=
 would also be a useful full-expression, I'd bet that a use case exists.<br=
>&nbsp;</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">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">Seemingly less useful:
<br>
<br>If non-const only, then const objects could not be discarded.
&nbsp;</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Definition as vo=
latile =3D default could, with a volatile copy constructor, copy the object=
 to a temporary, which would perhaps be discarded, creating an endless loop=
.. A corner case to be sure, but maybe a sign that this is all harebrained.
<br></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">It coul=
d be abused to make an ugly kind of functor which executes when merely name=
d as a complete expression-statement, particularly with lvalue reference qu=
alification.<br></blockquote><div><br>Examples ? :)<br></div></div></blockq=
uote><div><br>I'd rather not :) . Throwing volatile around is just asking f=
or trouble. Returning to the idea now, void can be cv-qualified, so allowin=
g <span style=3D"font-family: courier new,monospace;">operator void()</span=
> would perhaps require disallowing <span style=3D"font-family: courier new=
,monospace;">operator void volatile()</span>.<br><br>The last instance migh=
t bear mentioning. For example with the above throwing status proxy type, i=
f you have an object <span style=3D"font-family: courier new,monospace;">ob=
j</span> of such type, the expression statement <span style=3D"font-family:=
 courier new,monospace;">obj;</span> would throw the exception. Such statem=
ents usually flag "unused value" warnings, but with this language feature, =
the compiler would have a tough choice because the value <i>is</i> getting =
used. I don't think many people could write that just by accident, but mayb=
e I overestimate people.</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_106_14826830.1378106439301--

.

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

Am 02.09.2013 08:00 schrieb <the.ultimate.koala@gmail.com>:
>
> David,
>
>
>> What if discarded-value expressions of class type invoked an optional
operator void() conversion function?
>
>
> Why not? Indeed, void can't be used in an expression, and can't be used
as a parameter. Type void can be used as a template argument, though. Would
that break templates using conversion to T?

Such a breakage is only possibe
Le if code explicitly called "operator void".

An implicit call of that conversion function never happens, even if you say
"(void) x".

--

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

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

<p dir=3D"ltr"><br>
Am 02.09.2013 08:00 schrieb &lt;<a href=3D"mailto:the.ultimate.koala@gmail.=
com">the.ultimate.koala@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; David,<br>
&gt;<br>
&gt;<br>
&gt;&gt; What if discarded-value expressions of class type invoked an optio=
nal operator void() conversion function? <br>
&gt;<br>
&gt; =A0<br>
&gt; Why not? Indeed, void can&#39;t be used in an expression, and can&#39;=
t be used as a parameter. Type void can be used as a template argument, tho=
ugh. Would that break templates using conversion to T?</p>
<p dir=3D"ltr">Such a breakage is only possibe<br>
Le if code explicitly called &quot;operator void&quot;. </p>
<p dir=3D"ltr">An implicit call of that conversion function never happens, =
even if you say &quot;(void) x&quot;.</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 />

--047d7bd6b2ae4a971b04e561c463--

.

------=_Part_2437_2361069.1378109841876
Content-Type: text/plain; charset=ISO-8859-1



On Monday, September 2, 2013 3:46:14 PM UTC+8, Johannes Schaub wrote:
>
>
> Am 02.09.2013 08:00 schrieb <the.ultim...@gmail.com <javascript:>>:
> > Why not? Indeed, void can't be used in an expression, and can't be used
> as a parameter. Type void can be used as a template argument, though. Would
> that break templates using conversion to T?
>
> Such a breakage is only possibe
> Le if code explicitly called "operator void".
>
> An implicit call of that conversion function never happens, even if you
> say "(void) x".
>
Of course. The proposal is for a core language feature to make the implicit
call. Technically the breaking change would be to templates relying on the
call *not* happening in the void case.

It hadn't even occurred to me, but such a function and an explicit call to
it is already well-formed, and supported GCC and Clang. (Clang gives a
warning that the function will not be used, even if it is.) So that means
it would be a bad idea for the proposed feature to mention conversion
functions to cv-qualified void.

--

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

<div dir=3D"ltr"><br><br>On Monday, September 2, 2013 3:46:14 PM UTC+8, Joh=
annes Schaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"l=
tr"><br>
Am 02.09.2013 08:00 schrieb &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"2kzuhpiwqNoJ">the.ultim...@gmail.com</a>&gt;<wbr>:<=
br>
&gt; Why not? Indeed, void can't be used in an expression, and can't be use=
d as a parameter. Type void can be used as a template argument, though. Wou=
ld that break templates using conversion to T?</p>
<p dir=3D"ltr">Such a breakage is only possibe<br>
Le if code explicitly called "operator void". </p>
<p dir=3D"ltr">An implicit call of that conversion function never happens, =
even if you say "(void) x".</p></blockquote><div>Of course. The proposal is=
 for a core language feature to make the implicit call. Technically the bre=
aking change would be to templates relying on the call <i>not</i> happening=
 in the <span style=3D"font-family: courier new,monospace;">void</span> cas=
e.<br><br>It hadn't even occurred to me, but such a function and an explici=
t call to it is already well-formed, and supported GCC and Clang. (Clang gi=
ves a warning that the function will not be used, even if it is.) So that m=
eans it would be a bad idea for the proposed feature to mention conversion =
functions to cv-qualified void.<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_2437_2361069.1378109841876--

.

------=_Part_453_11224109.1378111534498
Content-Type: text/plain; charset=ISO-8859-1

Another corner case: An lvalue of incomplete type may be formed and
discarded with no effect. But the same syntax could result in an operator
void() call for the same type once complete. This is analogous to unary operator
& overloading, so the effect should likewise be UB. Fortunately,
discarding, taking the address, and binding a reference are the only things
you can do with such an lvalue, right?

--

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

<div dir=3D"ltr">Another corner case: An lvalue of incomplete type may be f=
ormed and=20
discarded with no effect. But the same syntax could result in an <span styl=
e=3D"font-family: courier new,monospace;">operator void()</span> call for t=
he same type once complete. This is analogous to unary <span style=3D"font-=
family: courier new,monospace;">operator &amp;</span>
 overloading, so the effect should likewise be UB. Fortunately,=20
discarding, taking the address, and binding a reference are the only things=
 you can do with=20
such an lvalue, right?<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_453_11224109.1378111534498--

.

On 2013-09-02 03:20, David Krauss wrote:
> On Monday, September 2, 2013 2:00:36 PM UTC+8, the.ultim...@gmail.com wrote:
<snip>

>         Expression templates could use such a hook to invoke evaluation.
>
>      Could you come up with a little example?
>
> Not off the top of my head. It would give a library a hook indicating a
> full-expression as opposed to a subexpression. Most expression templates
> work their magic upon conversion to a concrete type. But expression
> template applications are mostly mathematical in nature, with functional
> as opposed to imperative semantics. So most results are converted to
> something. Although I can't think of any template expression would also
> be a useful full-expression, I'd bet that a use case exists.

There are such cases.  Consider an expression template for vector
operations (similar to std::valarray).

We can have

a = b + c;

where b + c yields an expression template, and the assignment operator
evaluates it.

However, what if the user writes

a = b = c + d;

Now the assignment to b will trigger evaluation, and the assignment to a
will again.  So the elements of b will be iterated over twice (once for
writing, once for reading).

With the ability to detect discarded values, the library could delay
evaluation past the assignment to a, and write to both a and b in
parallel (with the advantage that b is read into cache only once).

Similar comments apply to things like

a += b += c;

I don't really feel comfortable with this feature, though.  It sounds
dangerous to have the semantics of an expression depend on its context
in this way; C++ has mostly avoided that so far.

John Bytheway

--

---
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_2993_12575919.1378170049061
Content-Type: text/plain; charset=ISO-8859-1



On Monday, September 2, 2013 11:30:41 PM UTC+8, John Bytheway wrote:
>
> I don't really feel comfortable with this feature, though.  It sounds
> dangerous to have the semantics of an expression depend on its context
> in this way; C++ has mostly avoided that so far.
>

It's potentially dangerous, but all the downsides I listed seem to result
from some kind of abuse. Expression semantics *do* already depend on
context according to all kinds of conversion rules; I'm merely suggesting a
runtime hook into one existing rule.

On the other hand, the throw-on-discard use case (the present motivation)
addresses situations where discarding a result is so dangerous that a
library designer would otherwise opt to provide only an exception, not a
return value.

I really don't want the performance consequences of resize() throwing in
the routine case that memory must be reallocated, e.g. every time a stringor
vector outgrows its capacity on a fragmented heap. Although in this case
it's probably a library issue (and only in a proposal), the language isn't
without fault.

The only useful semantic accessible to the average user, incapable of
writing a template or a proxy, would be a standard template
required_value<T> which would leverage the new C++11 feature = delete.
Surely the idea of operator void has been thought of before, along with
every other overload under the sun, but it might be worth reconsidering in
light of this new synergy.

--

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

<div dir=3D"ltr"><br><br>On Monday, September 2, 2013 11:30:41 PM UTC+8, Jo=
hn Bytheway wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I don't real=
ly feel comfortable with this feature, though. &nbsp;It sounds
<br>dangerous to have the semantics of an expression depend on its context
<br>in this way; C++ has mostly avoided that so far.
<br></blockquote><div><br>It's potentially dangerous, but all the downsides=
 I listed seem to result from some kind of abuse. Expression semantics <i>d=
o</i> already depend on context according to all kinds of conversion rules;=
 I'm merely suggesting a runtime hook into one existing rule.<br><br>On the=
 other hand, the throw-on-discard use case (the present motivation) address=
es situations where discarding a result is so dangerous that a library desi=
gner would otherwise opt to provide only an exception, not a return value.<=
br><br>I really don't want the performance consequences of <span style=3D"f=
ont-family: courier new,monospace;">resize()</span> throwing in the routine=
 case that memory must be reallocated, e.g. every time a <span style=3D"fon=
t-family: courier new,monospace;">string</span> or <span style=3D"font-fami=
ly: courier new,monospace;">vector</span> outgrows its capacity on a fragme=
nted heap. Although in this case it's probably a library issue (and only in=
 a proposal), the language isn't without fault.<br><br>The only useful sema=
ntic accessible to the average user, incapable of writing a template or a p=
roxy, would be a standard template <span style=3D"font-family: courier new,=
monospace;">required_value&lt;T&gt;</span> which would leverage the new C++=
11 feature <span style=3D"font-family: courier new,monospace;">=3D delete</=
span>. Surely the idea of <span style=3D"font-family: courier new,monospace=
;">operator void</span> has been thought of before, along with every other =
overload under the sun, but it might be worth reconsidering in light of thi=
s new synergy.</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_2993_12575919.1378170049061--

.

On Mon, Sep 2, 2013 at 9:20 AM, David Krauss <potswa@gmail.com> wrote:
>>>
>>> Expression templates could use such a hook to invoke evaluation.
>>
>>
>>  Could you come up with a little example?
>
>
> Not off the top of my head. It would give a library a hook indicating a
> full-expression as opposed to a subexpression. Most expression templates
> work their magic upon conversion to a concrete type. But expression template
> applications are mostly mathematical in nature, with functional as opposed
> to imperative semantics. So most results are converted to something.
> Although I can't think of any template expression would also be a useful
> full-expression, I'd bet that a use case exists.

For expression tempaltes I think it is more important to fix this scenario:

    auto x = some + expression + template + thingy;

Some way to override type inferrence would help a lot here (what I
call `operator auto`). This would require a lot of care to define
interaction with other parts of the language, though, and it probably
needs a way to override the type inferrence overriding, at least for
implementation purposes.

On Mon, Sep 2, 2013 at 5:30 PM, John Bytheway <jbytheway@gmail.com> wrote:
> We can have
>
> a = b + c;
>
> where b + c yields an expression template, and the assignment operator
> evaluates it.
>
> However, what if the user writes
>
> a = b = c + d;
>
> Now the assignment to b will trigger evaluation, and the assignment to a
> will again.  So the elements of b will be iterated over twice (once for
> writing, once for reading).

Hmm, isn't that only true if operator= for `b` returns the template
and not `*this`? As I see it, if that operator= returns this, there's
no extra evaluation; it's merely a copy. Am I missing something?

--

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

.

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

On Tue, Sep 3, 2013 at 6:20 PM, Martinho Fernandes <
martinho.fernandes@gmail.com> wrote:

> On Mon, Sep 2, 2013 at 9:20 AM, David Krauss <potswa@gmail.com> wrote:
> >>>
> >>> Expression templates could use such a hook to invoke evaluation.
> >>
> >>
> >>  Could you come up with a little example?
> >
> >
> > Not off the top of my head. It would give a library a hook indicating a
> > full-expression as opposed to a subexpression. Most expression templates
> > work their magic upon conversion to a concrete type. But expression
> template
> > applications are mostly mathematical in nature, with functional as
> opposed
> > to imperative semantics. So most results are converted to something.
> > Although I can't think of any template expression would also be a useful
> > full-expression, I'd bet that a use case exists.
>
> For expression tempaltes I think it is more important to fix this scenario:
>
>     auto x = some + expression + template + thingy;
>
> Some way to override type inferrence would help a lot here (what I
> call `operator auto`).


Note that (in N3690) the name "operator auto" is taken, and means a
conversion operator with a deduced return type.

Also, some people, myself included, think this is not the best way to
express this functionality anyway -- what we want is a way to express the
type that should be deduced, not a conversion to that type. Something like:

template<typename T> struct MatrixPlus {
  using auto = Matrix<T>;

  template<typename U>
  operator Matrix<U>() { ... }
};


> This would require a lot of care to define
> interaction with other parts of the language, though, and it probably
> needs a way to override the type inferrence overriding, at least for
> implementation purposes.


I would imagine this working by adding a paragraph after
[temp.deduct.call]p3 saying something like: "If P is a template type
parameter and the argument is an expression E with type A' for deduction
purposes, then A' is used in place of A for type deduction." This is
analogous to the special case for std::initializer_list<T> deduction
(albeit somewhat reversed), and would only apply for the specific pattern
of a (cv-qualified) (reference to) a template parameter type. So:

template<typename T> void f(MatrixPlus<T> &&); // #1, would deduce T=int
template<typename T> void f(T &&); // #2, would deduce T=Matrix<int>
f(MatrixPlus<int>{}); // calls #1, because it is more specialized

template<typename T> void f(std::vector<T>);
f(std::vector<MatrixPlus<int>>{}); // deduces T=MatrixPlus<int>, special
case doesn't apply here

I'll admit that I've given this less thought than it deserves, but the
details seem to work out OK.


> On Mon, Sep 2, 2013 at 5:30 PM, John Bytheway <jbytheway@gmail.com> wrote:
> > We can have
> >
> > a = b + c;
> >
> > where b + c yields an expression template, and the assignment operator
> > evaluates it.
> >
> > However, what if the user writes
> >
> > a = b = c + d;
> >
> > Now the assignment to b will trigger evaluation, and the assignment to a
> > will again.  So the elements of b will be iterated over twice (once for
> > writing, once for reading).
>
> Hmm, isn't that only true if operator= for `b` returns the template
> and not `*this`? As I see it, if that operator= returns this, there's
> no extra evaluation; it's merely a copy. Am I missing something?
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">On Tue, Sep 3, 2013 at 6:20 PM, Martinho Fernandes <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:martinho.fernandes@gmail.com" target=3D"_b=
lank">martinho.fernandes@gmail.com</a>&gt;</span> wrote:<br><div class=3D"g=
mail_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"=
>On Mon, Sep 2, 2013 at 9:20 AM, David Krauss &lt;<a href=3D"mailto:potswa@=
gmail.com">potswa@gmail.com</a>&gt; wrote:<br>

&gt;&gt;&gt;<br>
&gt;&gt;&gt; Expression templates could use such a hook to invoke evaluatio=
n.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0Could you come up with a little example?<br>
&gt;<br>
&gt;<br>
&gt; Not off the top of my head. It would give a library a hook indicating =
a<br>
&gt; full-expression as opposed to a subexpression. Most expression templat=
es<br>
&gt; work their magic upon conversion to a concrete type. But expression te=
mplate<br>
&gt; applications are mostly mathematical in nature, with functional as opp=
osed<br>
&gt; to imperative semantics. So most results are converted to something.<b=
r>
&gt; Although I can&#39;t think of any template expression would also be a =
useful<br>
&gt; full-expression, I&#39;d bet that a use case exists.<br>
<br>
</div>For expression tempaltes I think it is more important to fix this sce=
nario:<br>
<br>
=A0 =A0 auto x =3D some + expression + template + thingy;<br>
<br>
Some way to override type inferrence would help a lot here (what I<br>
call `operator auto`).</blockquote><div><br></div><div>Note that (in N3690)=
 the name &quot;operator auto&quot; is taken, and means a conversion operat=
or with a deduced return type.</div><div><br></div><div>Also, some people, =
myself included, think this is not the best way to express this functionali=
ty anyway -- what we want is a way to express the type that should be deduc=
ed, not a conversion to that type. Something like:</div>
<div><br></div><div>template&lt;typename T&gt; struct MatrixPlus {</div><di=
v>=A0 using auto =3D Matrix&lt;T&gt;;</div><div><br></div><div>=A0 template=
&lt;typename U&gt;</div><div>=A0 operator Matrix&lt;U&gt;() { ... }</div><d=
iv>};</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">This would require a lot of ca=
re to define<br>
interaction with other parts of the language, though, and it probably<br>
needs a way to override the type inferrence overriding, at least for<br>
implementation purposes.</blockquote><div><br></div><div>I would imagine th=
is working by adding a paragraph after [temp.deduct.call]p3 saying somethin=
g like: &quot;If P is a template type parameter and the argument is an expr=
ession E with type A&#39; for deduction purposes, then A&#39; is used in pl=
ace of A for type deduction.&quot; This is analogous to the special case fo=
r std::initializer_list&lt;T&gt; deduction (albeit somewhat reversed), and =
would only apply for the specific pattern of a (cv-qualified) (reference to=
) a template parameter type. So:</div>
<div><br></div><div>template&lt;typename T&gt; void f(MatrixPlus&lt;T&gt; &=
amp;&amp;); // #1, would deduce T=3Dint</div><div>template&lt;typename T&gt=
; void f(T &amp;&amp;); // #2, would deduce T=3DMatrix&lt;int&gt;</div><div=
>
f(MatrixPlus&lt;int&gt;{}); // calls #1, because it is more specialized</di=
v><div><br></div><div>template&lt;typename T&gt; void f(std::vector&lt;T&gt=
;);</div><div>f(std::vector&lt;MatrixPlus&lt;int&gt;&gt;{}); // deduces T=
=3DMatrixPlus&lt;int&gt;, special case doesn&#39;t apply here</div>
<div><br></div><div>I&#39;ll admit that I&#39;ve given this less thought th=
an it deserves, but the details seem to work out OK.</div><div>=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<div class=3D"im">
On Mon, Sep 2, 2013 at 5:30 PM, John Bytheway &lt;<a href=3D"mailto:jbythew=
ay@gmail.com">jbytheway@gmail.com</a>&gt; wrote:<br>
&gt; We can have<br>
&gt;<br>
&gt; a =3D b + c;<br>
&gt;<br>
&gt; where b + c yields an expression template, and the assignment operator=
<br>
&gt; evaluates it.<br>
&gt;<br>
&gt; However, what if the user writes<br>
&gt;<br>
&gt; a =3D b =3D c + d;<br>
&gt;<br>
&gt; Now the assignment to b will trigger evaluation, and the assignment to=
 a<br>
&gt; will again. =A0So the elements of b will be iterated over twice (once =
for<br>
&gt; writing, once for reading).<br>
<br>
</div>Hmm, isn&#39;t that only true if operator=3D for `b` returns the temp=
late<br>
and not `*this`? As I see it, if that operator=3D returns this, there&#39;s=
<br>
no extra evaluation; it&#39;s merely a copy. Am I missing something?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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 />
&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 />

--047d7b414aa4cc838504e584ee59--

.

------=_Part_69_32666930.1378261506576
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, September 4, 2013 9:20:24 AM UTC+8, R. Martinho Fernandes
wrote:
>
> For expression tempaltes I think it is more important to fix this
> scenario:
>
>     auto x = some + expression + template + thingy;
>

Perhaps a ref-qualified destructor could forbid destroying (and therefore
having in the first place) a named object.


> On Mon, Sep 2, 2013 at 5:30 PM, John Bytheway <jbyt...@gmail.com<javascript:>>
> wrote:
> > Now the assignment to b will trigger evaluation, and the assignment to a
> > will again.  So the elements of b will be iterated over twice (once for
> > writing, once for reading).
>
> Hmm, isn't that only true if operator= for `b` returns the template
> and not `*this`? As I see it, if that operator= returns this, there's
> no extra evaluation; it's merely a copy. Am I missing something?
>

Copying b to a is more expensive than writing the results into both a and bin the first place. So C++ may be less efficient than Fortran in such cases.

Following the expression template paradigm to its logical conclusion would
suggest that assignments should be treated like other subexpressions. But
evaluation just has to happen somewhere.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, September 4, 2013 9:20:24 AM UTC+8, =
R. Martinho Fernandes wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Fo=
r expression tempaltes I think it is more important to fix this scenario:
<br>
<br>&nbsp; &nbsp; auto x =3D some + expression + template + thingy;
<br></blockquote><div>&nbsp;</div><div>Perhaps a ref-qualified destructor c=
ould forbid destroying (and therefore having in the first place) a named ob=
ject.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
On Mon, Sep 2, 2013 at 5:30 PM, John Bytheway &lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"pk-Ii-sxjk8J">jbyt...@gmail.com</=
a>&gt; wrote:
<br>&gt; Now the assignment to b will trigger evaluation, and the assignmen=
t to a
<br>&gt; will again. &nbsp;So the elements of b will be iterated over twice=
 (once for
<br>&gt; writing, once for reading).
<br>
<br>Hmm, isn't that only true if operator=3D for `b` returns the template
<br>and not `*this`? As I see it, if that operator=3D returns this, there's
<br>no extra evaluation; it's merely a copy. Am I missing something?
<br></blockquote><div>&nbsp;<br>Copying <span style=3D"font-family: courier=
 new,monospace;">b</span> to <span style=3D"font-family: courier new,monosp=
ace;">a</span> is more expensive than writing the results into both <span s=
tyle=3D"font-family: courier new,monospace;">a</span> and <span style=3D"fo=
nt-family: courier new,monospace;">b</span> in the first place. So C++ may =
be less efficient than Fortran in such cases.<br><br>Following the expressi=
on template paradigm to its logical conclusion would suggest that assignmen=
ts should be treated like other subexpressions. But evaluation just has to =
happen somewhere.<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_69_32666930.1378261506576--

.