------=_Part_7023_540985742.1468172220403
Content-Type: multipart/alternative;
 boundary="----=_Part_7024_1854639186.1468172220403"

------=_Part_7024_1854639186.1468172220403
Content-Type: text/plain; charset=UTF-8

I'm moving the "deferred destruction"
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/S6zsTqrYCQAJ>topic
here to make things clearer.

The current proposal idea I'm moving forward with allowing (semi) anonymous
variables.
The idea is to adopt _ as a special variable name that supports overriding,
but in a backwards
compatible way:


   - _ should be allowed as a variable name.
   - _ should be allowed in redeclarations, overriding the previous
   declaration in the same scope.

This special variable would, for example, improve usage of:

   - any kind of guards, like std::lock_guard for example
   - multiple return (P0217R2)
   - scope_exit (P0052R2)

Here's some example code showing these features:


#include <mutex>
#include <tuple>
#include <scope>
#include <thread>
#include <memory>
#include <iostream>

using namespace std;

mutex m1, m2;

tuple<int, int> divide(int dividend, int divisor) {
    return  make_tuple(dividend / divisor, dividend % divisor);
}

int main() {
    auto _ = make_scope_exit([]{ cout << " bye"; }); // no need to care
about scope_exit naming
    auto _ = make_scope_exit([]{ cout << "bye"; });  // _ is the only
variable name that supports being overriding
    lock_guard<mutex> _(m1), _(m2);                  // it always refers to
the last declaration in the current scope
    auto [_, remainder] = divide(14, 3);             // works on multiple
return
}

Thanks Tony V E for the input in the previous thread
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/JWkYRnndCQAJ>
..

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org.

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

<div dir=3D"ltr">I&#39;m moving the <a href=3D"https://groups.google.com/a/=
isocpp.org/d/msg/std-proposals/8lsCinlSO1w/S6zsTqrYCQAJ">&quot;deferred des=
truction&quot; </a>topic here to make things clearer.<br><br>The current pr=
oposal idea I&#39;m moving forward with allowing (semi) anonymous variables=
..<br>The idea is to adopt _ as a special variable name that supports overri=
ding, but in a backwards<br>compatible way:<br><br><ul><li>_ should be allo=
wed as a variable name.</li><li>_ should be allowed in redeclarations, over=
riding the previous declaration in the same scope.</li></ul><span style=3D"=
font-family: courier new,monospace;">This special variable would, for examp=
le, improve usage of:<br></span><ul><li>any kind of guards, like std::lock_=
guard for example<br></li><li>multiple return (P0217R2)</li><li>scope_exit =
(P0052R2)</li></ul><p>Here&#39;s some example code showing these features:<=
br></p><p><br></p><span style=3D"font-family: courier new,monospace;">#incl=
ude &lt;mutex&gt;<br>#include &lt;tuple&gt;<br>#include &lt;scope&gt;<br>#i=
nclude &lt;thread&gt;<br>#include &lt;memory&gt;<br>#include &lt;iostream&g=
t;<br><br>using namespace std;<br><br>mutex m1, m2;<br><br>tuple&lt;int, in=
t&gt; divide(int dividend, int divisor) {<br>=C2=A0=C2=A0=C2=A0 return=C2=
=A0 make_tuple(dividend / divisor, dividend % divisor);<br>}<br><br>int mai=
n() {<br>=C2=A0=C2=A0=C2=A0 auto _ =3D make_scope_exit([]{ cout &lt;&lt; &q=
uot; bye&quot;; }); // no need to care about scope_exit naming<br>=C2=A0=C2=
=A0=C2=A0 auto _ =3D make_scope_exit([]{ cout &lt;&lt; &quot;bye&quot;; });=
=C2=A0 // _ is the only variable name that supports being overriding<br>=C2=
=A0=C2=A0=C2=A0 lock_guard&lt;mutex&gt; _(m1), _(m2);=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 // it always refers to the last declaration in the current scope<br>=
=C2=A0=C2=A0=C2=A0 auto [_, remainder] =3D divide(14, 3);=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // works on multiple=
 return<br>}</span><br><br>Thanks Tony V E for the <a href=3D"https://group=
s.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/JWkYRnndCQAJ">inp=
ut in the previous thread</a>.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6=
%40isocpp.org</a>.<br />

------=_Part_7024_1854639186.1468172220403--

------=_Part_7023_540985742.1468172220403--

.

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

I think "last declaration" is somewhat good for:

    Foo _{ 1, 2, 3 };
    _.setX(4); // unfortunately not available via constructor
    Foo _{ 5, 6, 7 };
    _.setX(8);

But I worry about cases like:

    // currently valid code
    Foo _{1,2,3};
    _.use();
    more();
    code();
    if (lots())
       of();
    else
      code();
    code();
    code();
    code();
    _.use_again();

And then someone copy-pastes another _ snippet in the middle.

    // currently valid code
    Foo _{1,2,3};
    _.use();
    more();
    code();
    if (lots())
       of();
    else
      code();
    Foo _{5,6,7};
    code();
    code();
    code();
    _.use_again();

Particularly when '_.use_again()' is '_.unlock()' on a scope-guard.

Of course, anyone who is currently using _ as a variable name AND is using
it throughout their function, probably has other problems.

But I can imagine code that was using _ as a lock guard, then later someone
realized that the guard should unlock early, so just added a _.unlock()
without renaming the variable.

And then, later, the code evolves some more and another _ is added in the
middle.

That is, unfortunately, how code is written.

Tony




On Sun, Jul 10, 2016 at 1:37 PM, Francisco Lopes <
francisco.mailing.lists@oblita.com> wrote:

> I'm moving the "deferred destruction"
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/S6zsTqrYCQAJ>topic
> here to make things clearer.
>
> The current proposal idea I'm moving forward with allowing (semi)
> anonymous variables.
> The idea is to adopt _ as a special variable name that supports
> overriding, but in a backwards
> compatible way:
>
>
>    - _ should be allowed as a variable name.
>    - _ should be allowed in redeclarations, overriding the previous
>    declaration in the same scope.
>
> This special variable would, for example, improve usage of:
>
>    - any kind of guards, like std::lock_guard for example
>    - multiple return (P0217R2)
>    - scope_exit (P0052R2)
>
> Here's some example code showing these features:
>
>
> #include <mutex>
> #include <tuple>
> #include <scope>
> #include <thread>
> #include <memory>
> #include <iostream>
>
> using namespace std;
>
> mutex m1, m2;
>
> tuple<int, int> divide(int dividend, int divisor) {
>     return  make_tuple(dividend / divisor, dividend % divisor);
> }
>
> int main() {
>     auto _ = make_scope_exit([]{ cout << " bye"; }); // no need to care
> about scope_exit naming
>     auto _ = make_scope_exit([]{ cout << "bye"; });  // _ is the only
> variable name that supports being overriding
>     lock_guard<mutex> _(m1), _(m2);                  // it always refers
> to the last declaration in the current scope
>     auto [_, remainder] = divide(14, 3);             // works on multiple
> return
> }
>
> Thanks Tony V E for the input in the previous thread
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/JWkYRnndCQAJ>
> .
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitGgsJk9Viv6fxDduxBXVqX5wuJjsrHWDH0%2B9qoxQT8kA%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div><di=
v><div><div>I think &quot;last declaration&quot; is somewhat good for:<br><=
br></div>=C2=A0=C2=A0=C2=A0 Foo _{ 1, 2, 3 };<br></div>=C2=A0=C2=A0=C2=A0 _=
..setX(4); // unfortunately not available via constructor<br></div>=C2=A0=C2=
=A0=C2=A0 Foo _{ 5, 6, 7 };<br></div>=C2=A0=C2=A0=C2=A0 _.setX(8);<br><br><=
/div>But I worry about cases like:<br><br></div><div>=C2=A0=C2=A0=C2=A0 // =
currently valid code<br></div>=C2=A0=C2=A0=C2=A0 Foo _{1,2,3};<br></div>=C2=
=A0=C2=A0=C2=A0 _.use();<br></div>=C2=A0=C2=A0=C2=A0 more();<br></div>=C2=
=A0=C2=A0=C2=A0 code();<br></div>=C2=A0=C2=A0=C2=A0 if (lots())<br></div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of();<br></div>=C2=A0=C2=A0=C2=A0 else=
<br></div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code();<br></div><div>=C2=A0=C2=A0=
=C2=A0 code();<br></div><div>=C2=A0=C2=A0=C2=A0 code();<br></div><div>=C2=
=A0=C2=A0=C2=A0 code();<br></div>=C2=A0=C2=A0=C2=A0 _.use_again();<br><br><=
div><div><div><div><div><div><div><div><div><div><div><div><div>And then so=
meone copy-pastes another _ snippet in the middle.<br><br><div>=C2=A0=C2=A0=
=C2=A0 // currently valid code<br></div>=C2=A0=C2=A0=C2=A0 Foo _{1,2,3};<br=
>=C2=A0=C2=A0=C2=A0 _.use();<br>=C2=A0=C2=A0=C2=A0 more();<br>=C2=A0=C2=A0=
=C2=A0 code();<br>=C2=A0=C2=A0=C2=A0 if (lots())<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 of();<br>=C2=A0=C2=A0=C2=A0 else<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 code();<br><div>=C2=A0=C2=A0=C2=A0 Foo _{5,6,7};<br>=C2=A0=C2=A0=
=C2=A0 code();<br></div><div>=C2=A0=C2=A0=C2=A0 code();<br></div><div>=C2=
=A0=C2=A0=C2=A0 code();<br></div>=C2=A0=C2=A0=C2=A0 _.use_again();<br><br><=
/div><div>Particularly when &#39;_.use_again()&#39; is &#39;_.unlock()&#39;=
 on a scope-guard.<br><br></div><div>Of course, anyone who is currently usi=
ng _ as a variable name AND is using it throughout their function, probably=
 has other problems.<br><br></div><div>But I can imagine code that was usin=
g _ as a lock guard, then later someone realized that the guard should unlo=
ck early, so just added a _.unlock() without renaming the variable.<br><br>=
</div><div>And then, later, the code evolves some more and another _ is add=
ed in the middle.<br><br></div><div>That is, unfortunately, how code is wri=
tten.<br><br></div><div>Tony<br><br><br></div><div><br></div></div></div></=
div></div></div></div></div></div></div></div></div></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Jul 10, 2016 at 1:3=
7 PM, Francisco Lopes <span dir=3D"ltr">&lt;<a href=3D"mailto:francisco.mai=
ling.lists@oblita.com" target=3D"_blank">francisco.mailing.lists@oblita.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I=
&#39;m moving the <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/s=
td-proposals/8lsCinlSO1w/S6zsTqrYCQAJ" target=3D"_blank">&quot;deferred des=
truction&quot; </a>topic here to make things clearer.<br><br>The current pr=
oposal idea I&#39;m moving forward with allowing (semi) anonymous variables=
..<br>The idea is to adopt _ as a special variable name that supports overri=
ding, but in a backwards<br>compatible way:<br><br><ul><li>_ should be allo=
wed as a variable name.</li><li>_ should be allowed in redeclarations, over=
riding the previous declaration in the same scope.</li></ul><span style=3D"=
font-family:courier new,monospace">This special variable would, for example=
, improve usage of:<br></span><ul><li>any kind of guards, like std::lock_gu=
ard for example<br></li><li>multiple return (P0217R2)</li><li>scope_exit (P=
0052R2)</li></ul><p>Here&#39;s some example code showing these features:<br=
></p><p><br></p><span style=3D"font-family:courier new,monospace">#include =
&lt;mutex&gt;<br>#include &lt;tuple&gt;<br>#include &lt;scope&gt;<br>#inclu=
de &lt;thread&gt;<br>#include &lt;memory&gt;<br>#include &lt;iostream&gt;<b=
r><br>using namespace std;<br><br>mutex m1, m2;<br><br>tuple&lt;int, int&gt=
; divide(int dividend, int divisor) {<br>=C2=A0=C2=A0=C2=A0 return=C2=A0 ma=
ke_tuple(dividend / divisor, dividend % divisor);<br>}<br><br>int main() {<=
br>=C2=A0=C2=A0=C2=A0 auto _ =3D make_scope_exit([]{ cout &lt;&lt; &quot; b=
ye&quot;; }); // no need to care about scope_exit naming<br>=C2=A0=C2=A0=C2=
=A0 auto _ =3D make_scope_exit([]{ cout &lt;&lt; &quot;bye&quot;; });=C2=A0=
 // _ is the only variable name that supports being overriding<br>=C2=A0=C2=
=A0=C2=A0 lock_guard&lt;mutex&gt; _(m1), _(m2);=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 // it always refers to the last declaration in the current scope<br>=C2=A0=
=C2=A0=C2=A0 auto [_, remainder] =3D divide(14, 3);=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // works on multiple retur=
n<br>}</span><br><br>Thanks Tony V E for the <a href=3D"https://groups.goog=
le.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/JWkYRnndCQAJ" target=3D=
"_blank">input in the previous thread</a>.<span class=3D"HOEnZb"><font colo=
r=3D"#888888"><br></font></span></div><span class=3D"HOEnZb"><font color=3D=
"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-=
4974-b1cb-df03ea39a5c6%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitGgsJk9Viv6fxDduxBXVqX5wuJjsrH=
WDH0%2B9qoxQT8kA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitGgsJk9V=
iv6fxDduxBXVqX5wuJjsrHWDH0%2B9qoxQT8kA%40mail.gmail.com</a>.<br />

--001a1146a0ea6f870105374bb4b2--

.

------=_Part_7077_1341274508.1468174177119
Content-Type: multipart/alternative;
 boundary="----=_Part_7078_1056269332.1468174177127"

------=_Part_7078_1056269332.1468174177127
Content-Type: text/plain; charset=UTF-8

Thanks for the input again. Well that's an awful sample of bad practices, I
agree with your point
though. So, between overring with accessibility vs overrinding disallowing
accessibility, I'm left
in doubt which is nicer.

In any case I'd advocate that _.foo() should be frowned upon always.

Regards

Em domingo, 10 de julho de 2016 14:52:54 UTC-3, Tony V E escreveu:
>
> I think "last declaration" is somewhat good for:
>
>     Foo _{ 1, 2, 3 };
>     _.setX(4); // unfortunately not available via constructor
>     Foo _{ 5, 6, 7 };
>     _.setX(8);
>
> But I worry about cases like:
>
>     // currently valid code
>     Foo _{1,2,3};
>     _.use();
>     more();
>     code();
>     if (lots())
>        of();
>     else
>       code();
>     code();
>     code();
>     code();
>     _.use_again();
>
> And then someone copy-pastes another _ snippet in the middle.
>
>     // currently valid code
>     Foo _{1,2,3};
>     _.use();
>     more();
>     code();
>     if (lots())
>        of();
>     else
>       code();
>     Foo _{5,6,7};
>     code();
>     code();
>     code();
>     _.use_again();
>
> Particularly when '_.use_again()' is '_.unlock()' on a scope-guard.
>
> Of course, anyone who is currently using _ as a variable name AND is using
> it throughout their function, probably has other problems.
>
> But I can imagine code that was using _ as a lock guard, then later
> someone realized that the guard should unlock early, so just added a
> _.unlock() without renaming the variable.
>
> And then, later, the code evolves some more and another _ is added in the
> middle.
>
> That is, unfortunately, how code is written.
>
> Tony
>
>
>
>
> On Sun, Jul 10, 2016 at 1:37 PM, Francisco Lopes <
> francisco.m...@oblita.com <javascript:>> wrote:
>
>> I'm moving the "deferred destruction"
>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/S6zsTqrYCQAJ>topic
>> here to make things clearer.
>>
>> The current proposal idea I'm moving forward with allowing (semi)
>> anonymous variables.
>> The idea is to adopt _ as a special variable name that supports
>> overriding, but in a backwards
>> compatible way:
>>
>>
>>    - _ should be allowed as a variable name.
>>    - _ should be allowed in redeclarations, overriding the previous
>>    declaration in the same scope.
>>
>> This special variable would, for example, improve usage of:
>>
>>    - any kind of guards, like std::lock_guard for example
>>    - multiple return (P0217R2)
>>    - scope_exit (P0052R2)
>>
>> Here's some example code showing these features:
>>
>>
>> #include <mutex>
>> #include <tuple>
>> #include <scope>
>> #include <thread>
>> #include <memory>
>> #include <iostream>
>>
>> using namespace std;
>>
>> mutex m1, m2;
>>
>> tuple<int, int> divide(int dividend, int divisor) {
>>     return  make_tuple(dividend / divisor, dividend % divisor);
>> }
>>
>> int main() {
>>     auto _ = make_scope_exit([]{ cout << " bye"; }); // no need to care
>> about scope_exit naming
>>     auto _ = make_scope_exit([]{ cout << "bye"; });  // _ is the only
>> variable name that supports being overriding
>>     lock_guard<mutex> _(m1), _(m2);                  // it always refers
>> to the last declaration in the current scope
>>     auto [_, remainder] = divide(14, 3);             // works on multiple
>> return
>> }
>>
>> Thanks Tony V E for the input in the previous thread
>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/JWkYRnndCQAJ>
>> .
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b236289c-3757-4047-a1b4-7781148af265%40isocpp.org.

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

<div dir=3D"ltr">Thanks for the input again. Well that&#39;s an awful sampl=
e of bad practices, I agree with your point<br>though. So, between overring=
 with accessibility vs overrinding disallowing accessibility, I&#39;m left<=
br>in doubt which is nicer.<br><br>In any case I&#39;d advocate that _.foo(=
) should be frowned upon always.<br><br>Regards<br><br>Em domingo, 10 de ju=
lho de 2016 14:52:54 UTC-3, Tony V E  escreveu:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div><div><div><div><div><div><div><div><=
div><div><div><div><div><div>I think &quot;last declaration&quot; is somewh=
at good for:<br><br></div>=C2=A0=C2=A0=C2=A0 Foo _{ 1, 2, 3 };<br></div>=C2=
=A0=C2=A0=C2=A0 _.setX(4); // unfortunately not available via constructor<b=
r></div>=C2=A0=C2=A0=C2=A0 Foo _{ 5, 6, 7 };<br></div>=C2=A0=C2=A0=C2=A0 _.=
setX(8);<br><br></div>But I worry about cases like:<br><br></div><div>=C2=
=A0=C2=A0=C2=A0 // currently valid code<br></div>=C2=A0=C2=A0=C2=A0 Foo _{1=
,2,3};<br></div>=C2=A0=C2=A0=C2=A0 _.use();<br></div>=C2=A0=C2=A0=C2=A0 mor=
e();<br></div>=C2=A0=C2=A0=C2=A0 code();<br></div>=C2=A0=C2=A0=C2=A0 if (lo=
ts())<br></div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of();<br></div>=C2=A0=
=C2=A0=C2=A0 else<br></div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code();<br></div>=
<div>=C2=A0=C2=A0=C2=A0 code();<br></div><div>=C2=A0=C2=A0=C2=A0 code();<br=
></div><div>=C2=A0=C2=A0=C2=A0 code();<br></div>=C2=A0=C2=A0=C2=A0 _.use_ag=
ain();<br><br><div><div><div><div><div><div><div><div><div><div><div><div><=
div>And then someone copy-pastes another _ snippet in the middle.<br><br><d=
iv>=C2=A0=C2=A0=C2=A0 // currently valid code<br></div>=C2=A0=C2=A0=C2=A0 F=
oo _{1,2,3};<br>=C2=A0=C2=A0=C2=A0 _.use();<br>=C2=A0=C2=A0=C2=A0 more();<b=
r>=C2=A0=C2=A0=C2=A0 code();<br>=C2=A0=C2=A0=C2=A0 if (lots())<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 of();<br>=C2=A0=C2=A0=C2=A0 else<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 code();<br><div>=C2=A0=C2=A0=C2=A0 Foo _{5,6,7};<br>=
=C2=A0=C2=A0=C2=A0 code();<br></div><div>=C2=A0=C2=A0=C2=A0 code();<br></di=
v><div>=C2=A0=C2=A0=C2=A0 code();<br></div>=C2=A0=C2=A0=C2=A0 _.use_again()=
;<br><br></div><div>Particularly when &#39;_.use_again()&#39; is &#39;_.unl=
ock()&#39; on a scope-guard.<br><br></div><div>Of course, anyone who is cur=
rently using _ as a variable name AND is using it throughout their function=
, probably has other problems.<br><br></div><div>But I can imagine code tha=
t was using _ as a lock guard, then later someone realized that the guard s=
hould unlock early, so just added a _.unlock() without renaming the variabl=
e.<br><br></div><div>And then, later, the code evolves some more and anothe=
r _ is added in the middle.<br><br></div><div>That is, unfortunately, how c=
ode is written.<br><br></div><div>Tony<br><br><br></div><div><br></div></di=
v></div></div></div></div></div></div></div></div></div></div></div></div><=
div><br><div class=3D"gmail_quote">On Sun, Jul 10, 2016 at 1:37 PM, Francis=
co Lopes <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"f1m7hqgZCgAJ" rel=3D"nofollow" onmousedown=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javas=
cript:&#39;;return true;">francisco.m...@<wbr>oblita.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39;m moving the <=
a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCin=
lSO1w/S6zsTqrYCQAJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsC=
inlSO1w/S6zsTqrYCQAJ&#39;;return true;" onclick=3D"this.href=3D&#39;https:/=
/groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/S6zsTqrYCQA=
J&#39;;return true;">&quot;deferred destruction&quot; </a>topic here to mak=
e things clearer.<br><br>The current proposal idea I&#39;m moving forward w=
ith allowing (semi) anonymous variables.<br>The idea is to adopt _ as a spe=
cial variable name that supports overriding, but in a backwards<br>compatib=
le way:<br><br><ul><li>_ should be allowed as a variable name.</li><li>_ sh=
ould be allowed in redeclarations, overriding the previous declaration in t=
he same scope.</li></ul><span style=3D"font-family:courier new,monospace">T=
his special variable would, for example, improve usage of:<br></span><ul><l=
i>any kind of guards, like std::lock_guard for example<br></li><li>multiple=
 return (P0217R2)</li><li>scope_exit (P0052R2)</li></ul><p>Here&#39;s some =
example code showing these features:<br></p><p><br></p><span style=3D"font-=
family:courier new,monospace">#include &lt;mutex&gt;<br>#include &lt;tuple&=
gt;<br>#include &lt;scope&gt;<br>#include &lt;thread&gt;<br>#include &lt;me=
mory&gt;<br>#include &lt;iostream&gt;<br><br>using namespace std;<br><br>mu=
tex m1, m2;<br><br>tuple&lt;int, int&gt; divide(int dividend, int divisor) =
{<br>=C2=A0=C2=A0=C2=A0 return=C2=A0 make_tuple(dividend / divisor, dividen=
d % divisor);<br>}<br><br>int main() {<br>=C2=A0=C2=A0=C2=A0 auto _ =3D mak=
e_scope_exit([]{ cout &lt;&lt; &quot; bye&quot;; }); // no need to care abo=
ut scope_exit naming<br>=C2=A0=C2=A0=C2=A0 auto _ =3D make_scope_exit([]{ c=
out &lt;&lt; &quot;bye&quot;; });=C2=A0 // _ is the only variable name that=
 supports being overriding<br>=C2=A0=C2=A0=C2=A0 lock_guard&lt;mutex&gt; _(=
m1), _(m2);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // it always refers to the last dec=
laration in the current scope<br>=C2=A0=C2=A0=C2=A0 auto [_, remainder] =3D=
 divide(14, 3);=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 // works on multiple return<br>}</span><br><br>Thanks Tony V E=
 for the <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-propos=
als/8lsCinlSO1w/JWkYRnndCQAJ" target=3D"_blank" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-prop=
osals/8lsCinlSO1w/JWkYRnndCQAJ&#39;;return true;" onclick=3D"this.href=3D&#=
39;https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/J=
WkYRnndCQAJ&#39;;return true;">input in the previous thread</a>.<span><font=
 color=3D"#888888"><br></font></span></div><span><font color=3D"#888888">

<p></p>

-- <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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
f1m7hqgZCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"f1m7hqgZCgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/505fe073-a45b-4974-<wbr>b1cb-=
df03ea39a5c6%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b236289c-3757-4047-a1b4-7781148af265%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b236289c-3757-4047-a1b4-7781148af265=
%40isocpp.org</a>.<br />

------=_Part_7078_1056269332.1468174177127--

------=_Part_7077_1341274508.1468174177119--

.

------=_Part_2371_1482468882.1468175947221
Content-Type: multipart/alternative;
 boundary="----=_Part_2372_2046792812.1468175947222"

------=_Part_2372_2046792812.1468175947222
Content-Type: text/plain; charset=UTF-8

Isn't _ typically / often used as alias for GNU gettext()? This could cause
some resistance to the proposal as it is (regardless of how bad -- though
convenient -- a choice it was to use this alias). Maybe it could be dealt
with by treating this as a special case in the grammar? Again, likely to
meet some resistance. Maybe reuse the now defunct register keyword /s ?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0939a10e-9790-4286-b5b8-2fb816b2422c%40isocpp.org.

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

<div dir=3D"ltr">Isn&#39;t _ typically / often used as alias for GNU gettex=
t()? This could cause some resistance to the proposal as it is (regardless =
of how bad -- though convenient -- a choice it was to use this alias). Mayb=
e it could be dealt with by treating this as a special case in the grammar?=
 Again, likely to meet some resistance. Maybe reuse the now defunct registe=
r keyword /s ?<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0939a10e-9790-4286-b5b8-2fb816b2422c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0939a10e-9790-4286-b5b8-2fb816b2422c=
%40isocpp.org</a>.<br />

------=_Part_2372_2046792812.1468175947222--

------=_Part_2371_1482468882.1468175947221--

.

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

One could envision "fun" things such as :

int _ = 3;
auto _ = _; // code maintenance just became even more frightening

An idea would be to make use of _ incorrect past initialization, such that
the use of _ on the right hand would not compile, but I guess someone could
want to use _ as a way to avoid caring about a pass-by-reference argument
in some function :

pair<string,float> fct(int);
void f(int &, int&);
auto g() {
   int x = 3;
   auto _ = ""; // useless but would be legal
   auto [s,_] = fct(x); // fair enough, can live with this...
   f(x, _); // don't care about the 2nd argument... this seems like a
legitimate use case, I guess, but f(_,_) and other unusual things become
possible...
   return x + s.size();
}

I'm not totally against this feature, but it deserves detailed scrutiny
before moving ahead...



2016-07-10 14:09 GMT-04:00 Francisco Lopes <
francisco.mailing.lists@oblita.com>:

> Thanks for the input again. Well that's an awful sample of bad practices,
> I agree with your point
> though. So, between overring with accessibility vs overrinding disallowing
> accessibility, I'm left
> in doubt which is nicer.
>
> In any case I'd advocate that _.foo() should be frowned upon always.
>
> Regards
>
>
> Em domingo, 10 de julho de 2016 14:52:54 UTC-3, Tony V E escreveu:
>
>> I think "last declaration" is somewhat good for:
>>
>>     Foo _{ 1, 2, 3 };
>>     _.setX(4); // unfortunately not available via constructor
>>     Foo _{ 5, 6, 7 };
>>     _.setX(8);
>>
>> But I worry about cases like:
>>
>>     // currently valid code
>>     Foo _{1,2,3};
>>     _.use();
>>     more();
>>     code();
>>     if (lots())
>>        of();
>>     else
>>       code();
>>     code();
>>     code();
>>     code();
>>     _.use_again();
>>
>> And then someone copy-pastes another _ snippet in the middle.
>>
>>     // currently valid code
>>     Foo _{1,2,3};
>>     _.use();
>>     more();
>>     code();
>>     if (lots())
>>        of();
>>     else
>>       code();
>>     Foo _{5,6,7};
>>     code();
>>     code();
>>     code();
>>     _.use_again();
>>
>> Particularly when '_.use_again()' is '_.unlock()' on a scope-guard.
>>
>> Of course, anyone who is currently using _ as a variable name AND is
>> using it throughout their function, probably has other problems.
>>
>> But I can imagine code that was using _ as a lock guard, then later
>> someone realized that the guard should unlock early, so just added a
>> _.unlock() without renaming the variable.
>>
>> And then, later, the code evolves some more and another _ is added in the
>> middle.
>>
>> That is, unfortunately, how code is written.
>>
>> Tony
>>
>>
>>
>>
>> On Sun, Jul 10, 2016 at 1:37 PM, Francisco Lopes <
>> francisco.m...@oblita.com> wrote:
>>
>>> I'm moving the "deferred destruction"
>>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/S6zsTqrYCQAJ>topic
>>> here to make things clearer.
>>>
>>> The current proposal idea I'm moving forward with allowing (semi)
>>> anonymous variables.
>>> The idea is to adopt _ as a special variable name that supports
>>> overriding, but in a backwards
>>> compatible way:
>>>
>>>
>>>    - _ should be allowed as a variable name.
>>>    - _ should be allowed in redeclarations, overriding the previous
>>>    declaration in the same scope.
>>>
>>> This special variable would, for example, improve usage of:
>>>
>>>    - any kind of guards, like std::lock_guard for example
>>>    - multiple return (P0217R2)
>>>    - scope_exit (P0052R2)
>>>
>>> Here's some example code showing these features:
>>>
>>>
>>> #include <mutex>
>>> #include <tuple>
>>> #include <scope>
>>> #include <thread>
>>> #include <memory>
>>> #include <iostream>
>>>
>>> using namespace std;
>>>
>>> mutex m1, m2;
>>>
>>> tuple<int, int> divide(int dividend, int divisor) {
>>>     return  make_tuple(dividend / divisor, dividend % divisor);
>>> }
>>>
>>> int main() {
>>>     auto _ = make_scope_exit([]{ cout << " bye"; }); // no need to care
>>> about scope_exit naming
>>>     auto _ = make_scope_exit([]{ cout << "bye"; });  // _ is the only
>>> variable name that supports being overriding
>>>     lock_guard<mutex> _(m1), _(m2);                  // it always refers
>>> to the last declaration in the current scope
>>>     auto [_, remainder] = divide(14, 3);             // works on
>>> multiple return
>>> }
>>>
>>> Thanks Tony V E for the input in the previous thread
>>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/JWkYRnndCQAJ>
>>> .
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b236289c-3757-4047-a1b4-7781148af265%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b236289c-3757-4047-a1b4-7781148af265%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1mYrv4fid5HMhtiw%3DrU5TvnAWVO1MhUfeNVo%2Bj9JqdFA%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div>One could envision &quot;fun&quot; things such a=
s :<br><br></div>int _ =3D 3;<br></div>auto _ =3D _; // code maintenance ju=
st became even more frightening<br><div><div><div><div><br>An idea would be=
 to make use of _ incorrect past initialization, such that the use of _ on =
the right hand would not compile, but I guess someone could want to use _ a=
s a way to avoid caring about a pass-by-reference argument in some function=
 :<br><br></div><div>pair&lt;string,float&gt; fct(int);<br></div><div>void =
f(int &amp;, int&amp;);<br></div><div>auto g() {<br></div><div>=C2=A0=C2=A0=
 int x =3D 3;<br></div><div>=C2=A0=C2=A0 auto _ =3D &quot;&quot;; // useles=
s but would be legal<br></div><div>=C2=A0=C2=A0 auto [s,_] =3D fct(x); // f=
air enough, can live with this...<br></div><div>=C2=A0=C2=A0 f(x, _); // do=
n&#39;t care about the 2nd argument... this seems like a legitimate use cas=
e, I guess, but f(_,_) and other unusual things become possible...<br></div=
><div>=C2=A0=C2=A0 return x + s.size();<br></div><div>}<br><br></div><div><=
/div><div>I&#39;m not totally against this feature, but it deserves detaile=
d scrutiny before moving ahead...<br></div><div><br></div><div><br></div></=
div></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">2016-07-10 14:09 GMT-04:00 Francisco Lopes <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:francisco.mailing.lists@oblita.com" target=3D"_blank">francisc=
o.mailing.lists@oblita.com</a>&gt;</span>:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">Thanks for the input again. Well that&#39;s an awful sam=
ple of bad practices, I agree with your point<br>though. So, between overri=
ng with accessibility vs overrinding disallowing accessibility, I&#39;m lef=
t<br>in doubt which is nicer.<br><br>In any case I&#39;d advocate that _.fo=
o() should be frowned upon always.<br><br>Regards<div><div class=3D"h5"><br=
><br>Em domingo, 10 de julho de 2016 14:52:54 UTC-3, Tony V E  escreveu:</d=
iv></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><di=
v dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div><div><=
div><div>I think &quot;last declaration&quot; is somewhat good for:<br><br>=
</div>=C2=A0=C2=A0=C2=A0 Foo _{ 1, 2, 3 };<br></div>=C2=A0=C2=A0=C2=A0 _.se=
tX(4); // unfortunately not available via constructor<br></div>=C2=A0=C2=A0=
=C2=A0 Foo _{ 5, 6, 7 };<br></div>=C2=A0=C2=A0=C2=A0 _.setX(8);<br><br></di=
v>But I worry about cases like:<br><br></div><div>=C2=A0=C2=A0=C2=A0 // cur=
rently valid code<br></div>=C2=A0=C2=A0=C2=A0 Foo _{1,2,3};<br></div>=C2=A0=
=C2=A0=C2=A0 _.use();<br></div>=C2=A0=C2=A0=C2=A0 more();<br></div>=C2=A0=
=C2=A0=C2=A0 code();<br></div>=C2=A0=C2=A0=C2=A0 if (lots())<br></div>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of();<br></div>=C2=A0=C2=A0=C2=A0 else<br=
></div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code();<br></div><div>=C2=A0=C2=A0=C2=
=A0 code();<br></div><div>=C2=A0=C2=A0=C2=A0 code();<br></div><div>=C2=A0=
=C2=A0=C2=A0 code();<br></div>=C2=A0=C2=A0=C2=A0 _.use_again();<br><br><div=
><div><div><div><div><div><div><div><div><div><div><div><div>And then someo=
ne copy-pastes another _ snippet in the middle.<br><br><div>=C2=A0=C2=A0=C2=
=A0 // currently valid code<br></div>=C2=A0=C2=A0=C2=A0 Foo _{1,2,3};<br>=
=C2=A0=C2=A0=C2=A0 _.use();<br>=C2=A0=C2=A0=C2=A0 more();<br>=C2=A0=C2=A0=
=C2=A0 code();<br>=C2=A0=C2=A0=C2=A0 if (lots())<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 of();<br>=C2=A0=C2=A0=C2=A0 else<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 code();<br><div>=C2=A0=C2=A0=C2=A0 Foo _{5,6,7};<br>=C2=A0=C2=A0=
=C2=A0 code();<br></div><div>=C2=A0=C2=A0=C2=A0 code();<br></div><div>=C2=
=A0=C2=A0=C2=A0 code();<br></div>=C2=A0=C2=A0=C2=A0 _.use_again();<br><br><=
/div><div>Particularly when &#39;_.use_again()&#39; is &#39;_.unlock()&#39;=
 on a scope-guard.<br><br></div><div>Of course, anyone who is currently usi=
ng _ as a variable name AND is using it throughout their function, probably=
 has other problems.<br><br></div><div>But I can imagine code that was usin=
g _ as a lock guard, then later someone realized that the guard should unlo=
ck early, so just added a _.unlock() without renaming the variable.<br><br>=
</div><div>And then, later, the code evolves some more and another _ is add=
ed in the middle.<br><br></div><div>That is, unfortunately, how code is wri=
tten.<br><br></div><div>Tony<br><br><br></div><div><br></div></div></div></=
div></div></div></div></div></div></div></div></div></div></div></div></div=
><div><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Sun, Jul 10,=
 2016 at 1:37 PM, Francisco Lopes <span dir=3D"ltr">&lt;<a rel=3D"nofollow"=
>francisco.m...@oblita.com</a>&gt;</span> wrote:<br></div></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr">I&#39;m moving =
the <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/8=
lsCinlSO1w/S6zsTqrYCQAJ" rel=3D"nofollow" target=3D"_blank">&quot;deferred =
destruction&quot; </a>topic here to make things clearer.<br><br>The current=
 proposal idea I&#39;m moving forward with allowing (semi) anonymous variab=
les.<br>The idea is to adopt _ as a special variable name that supports ove=
rriding, but in a backwards<br>compatible way:<br><br><ul><li>_ should be a=
llowed as a variable name.</li><li>_ should be allowed in redeclarations, o=
verriding the previous declaration in the same scope.</li></ul><span style=
=3D"font-family:courier new,monospace">This special variable would, for exa=
mple, improve usage of:<br></span><ul><li>any kind of guards, like std::loc=
k_guard for example<br></li><li>multiple return (P0217R2)</li><li>scope_exi=
t (P0052R2)</li></ul><p>Here&#39;s some example code showing these features=
:<br></p><p><br></p><span style=3D"font-family:courier new,monospace">#incl=
ude &lt;mutex&gt;<br>#include &lt;tuple&gt;<br>#include &lt;scope&gt;<br>#i=
nclude &lt;thread&gt;<br>#include &lt;memory&gt;<br>#include &lt;iostream&g=
t;<br><br>using namespace std;<br><br>mutex m1, m2;<br><br>tuple&lt;int, in=
t&gt; divide(int dividend, int divisor) {<br>=C2=A0=C2=A0=C2=A0 return=C2=
=A0 make_tuple(dividend / divisor, dividend % divisor);<br>}<br><br>int mai=
n() {<br>=C2=A0=C2=A0=C2=A0 auto _ =3D make_scope_exit([]{ cout &lt;&lt; &q=
uot; bye&quot;; }); // no need to care about scope_exit naming<br>=C2=A0=C2=
=A0=C2=A0 auto _ =3D make_scope_exit([]{ cout &lt;&lt; &quot;bye&quot;; });=
=C2=A0 // _ is the only variable name that supports being overriding<br>=C2=
=A0=C2=A0=C2=A0 lock_guard&lt;mutex&gt; _(m1), _(m2);=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 // it always refers to the last declaration in the current scope<br>=
=C2=A0=C2=A0=C2=A0 auto [_, remainder] =3D divide(14, 3);=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // works on multiple=
 return<br>}</span><br><br>Thanks Tony V E for the <a href=3D"https://group=
s.google.com/a/isocpp.org/d/msg/std-proposals/8lsCinlSO1w/JWkYRnndCQAJ" rel=
=3D"nofollow" target=3D"_blank">input in the previous thread</a>.<span><fon=
t color=3D"#888888"><br></font></span></div></div></div><span><font color=
=3D"#888888"><div><div class=3D"h5">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></div></div>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/505fe073-a45b-4974-b1cb-df03ea39a5c6%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/505fe073-a45b-4974-b1cb-df03ea39a5c6%40isocpp.org</a>.<br>
</span></font></span></blockquote></div><br></div>
</blockquote></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b236289c-3757-4047-a1b4-7781148af265%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b236289c-3757-=
4047-a1b4-7781148af265%40isocpp.org</a>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1mYrv4fid5HMhtiw%3DrU5TvnAWVO1=
MhUfeNVo%2Bj9JqdFA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1mYrv4=
fid5HMhtiw%3DrU5TvnAWVO1MhUfeNVo%2Bj9JqdFA%40mail.gmail.com</a>.<br />

--001a11467f9eccadf705374c5b9b--

.

------=_Part_256_1597255747.1468176684216
Content-Type: multipart/alternative;
 boundary="----=_Part_257_540811703.1468176684217"

------=_Part_257_540811703.1468176684217
Content-Type: text/plain; charset=UTF-8

Initially I was thinking about using ... instead of _ to avoid such naming
issue. If adopting ...
as the placeholder, then I'd go for it not being referenciable at all, and
would touch the current
usage of _.

Personally I'm open to such changes because I'm caring more for the core
functionality.

Em domingo, 10 de julho de 2016 15:39:07 UTC-3, Brandon Kentel escreveu:
>
> Isn't _ typically / often used as alias for GNU gettext()? This could
> cause some resistance to the proposal as it is (regardless of how bad --
> though convenient -- a choice it was to use this alias). Maybe it could be
> dealt with by treating this as a special case in the grammar? Again, likely
> to meet some resistance. Maybe reuse the now defunct register keyword /s ?
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f7eb64e3-0ed0-4f6e-a827-5f3936a162ae%40isocpp.org.

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

<div dir=3D"ltr">Initially I was thinking about using ... instead of _ to a=
void such naming issue. If adopting ...<br>as the placeholder, then I&#39;d=
 go for it not being referenciable at all, and would touch the current<br>u=
sage of _.<br><br>Personally I&#39;m open to such changes because I&#39;m c=
aring more for the core functionality.<br><br>Em domingo, 10 de julho de 20=
16 15:39:07 UTC-3, Brandon Kentel  escreveu:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">Isn&#39;t _ typically / often used as alias =
for GNU gettext()? This could cause some resistance to the proposal as it i=
s (regardless of how bad -- though convenient -- a choice it was to use thi=
s alias). Maybe it could be dealt with by treating this as a special case i=
n the grammar? Again, likely to meet some resistance. Maybe reuse the now d=
efunct register keyword /s ?<br></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f7eb64e3-0ed0-4f6e-a827-5f3936a162ae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f7eb64e3-0ed0-4f6e-a827-5f3936a162ae=
%40isocpp.org</a>.<br />

------=_Part_257_540811703.1468176684217--

------=_Part_256_1597255747.1468176684216--

.

------=_Part_1111_168248488.1468176857805
Content-Type: multipart/alternative;
 boundary="----=_Part_1112_390127567.1468176857805"

------=_Part_1112_390127567.1468176857805
Content-Type: text/plain; charset=UTF-8

woudn't touch*

Em domingo, 10 de julho de 2016 15:51:24 UTC-3, Francisco Lopes escreveu:
>
> Initially I was thinking about using ... instead of _ to avoid such naming
> issue. If adopting ...
> as the placeholder, then I'd go for it not being referenciable at all, and
> would touch the current
> usage of _.
>
> Personally I'm open to such changes because I'm caring more for the core
> functionality.
>
> Em domingo, 10 de julho de 2016 15:39:07 UTC-3, Brandon Kentel escreveu:
>>
>> Isn't _ typically / often used as alias for GNU gettext()? This could
>> cause some resistance to the proposal as it is (regardless of how bad --
>> though convenient -- a choice it was to use this alias). Maybe it could be
>> dealt with by treating this as a special case in the grammar? Again, likely
>> to meet some resistance. Maybe reuse the now defunct register keyword /s ?
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f48cea87-4905-4bb4-bc8e-6065414125f5%40isocpp.org.

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

<div dir=3D"ltr">woudn&#39;t touch*<br><br>Em domingo, 10 de julho de 2016 =
15:51:24 UTC-3, Francisco Lopes  escreveu:<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">Initially I was thinking about using ... inste=
ad of _ to avoid such naming issue. If adopting ...<br>as the placeholder, =
then I&#39;d go for it not being referenciable at all, and would touch the =
current<br>usage of _.<br><br>Personally I&#39;m open to such changes becau=
se I&#39;m caring more for the core functionality.<br><br>Em domingo, 10 de=
 julho de 2016 15:39:07 UTC-3, Brandon Kentel  escreveu:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Isn&#39;t _ typically / often used =
as alias for GNU gettext()? This could cause some resistance to the proposa=
l as it is (regardless of how bad -- though convenient -- a choice it was t=
o use this alias). Maybe it could be dealt with by treating this as a speci=
al case in the grammar? Again, likely to meet some resistance. Maybe reuse =
the now defunct register keyword /s ?<br></div></blockquote></div></blockqu=
ote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f48cea87-4905-4bb4-bc8e-6065414125f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f48cea87-4905-4bb4-bc8e-6065414125f5=
%40isocpp.org</a>.<br />

------=_Part_1112_390127567.1468176857805--

------=_Part_1111_168248488.1468176857805--

.

------=_Part_4018_1382904614.1468181404060
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

_ is already used as a placeholder in the MPL. It's also sometimes used as =
a local macro name.  You have a neat idea, but _ seems pretty well spoken f=
or.  It's also unclear that this proposal would solve a real pain point, or=
 whether it's convenience would be outweighed by (arguably) less readable c=
ode.

I would find the feature more useful if it offered slightly less functional=
ity; in particular, I'd like a guarantee that no operation at all can be pe=
rformed on such variables except the automatic destruction at end of scope.

To these ends, would it make sense to dispense with the variable name altog=
ether, making the objects truly anonymous?

auto =3D std::lock_guard<std::mutex>(mtx1);
auto =3D std::lock_guard<std::mutex>(mtx2);

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3f13ce4d-7481-46d1-bf39-ad07424c6460%40isocpp.or=
g.

------=_Part_4018_1382904614.1468181404060--

.

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

On Sun, Jul 10, 2016 at 9:10 PM, <jeff@unbuggy.com> wrote:

> _ is already used as a placeholder in the MPL. It's also sometimes used as
> a local macro name.  You have a neat idea, but _ seems pretty well spoken
> for.  It's also unclear that this proposal would solve a real pain point,
> or whether it's convenience would be outweighed by (arguably) less readable
> code.
>
> I would find the feature more useful if it offered slightly less
> functionality; in particular, I'd like a guarantee that no operation at all
> can be performed on such variables except the automatic destruction at end
> of scope.
>
> To these ends, would it make sense to dispense with the variable name
> altogether, making the objects truly anonymous?
>
> auto = std::lock_guard<std::mutex>(mtx1);
> auto = std::lock_guard<std::mutex>(mtx2);
>


Can we be sure no one will ever want to specify a different type at LHS in
order to force a conversion operator from RHS? I know use-cases for this
are limited, but are they *that* limited?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGFVmqMCRqmbzrXsL%2BuC_Z%2BR3_dtEt9H8AEYPcSt8HQQg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jul 10, 2016 at 9:10 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:jeff@=
unbuggy.com" target=3D"_blank">jeff@unbuggy.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">_ is already used as a placeholder in the MPL.=
 It&#39;s also sometimes used as a local macro name.=C2=A0 You have a neat =
idea, but _ seems pretty well spoken for.=C2=A0 It&#39;s also unclear that =
this proposal would solve a real pain point, or whether it&#39;s convenienc=
e would be outweighed by (arguably) less readable code.<br>
<br>
I would find the feature more useful if it offered slightly less functional=
ity; in particular, I&#39;d like a guarantee that no operation at all can b=
e performed on such variables except the automatic destruction at end of sc=
ope.<br>
<br>
To these ends, would it make sense to dispense with the variable name altog=
ether, making the objects truly anonymous?<br>
<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(mtx1);<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(mtx2);<br>
<span class=3D""></span></blockquote><div><br><br></div><div>Can we be sure=
 no one will ever want to specify a different type at LHS in order to force=
 a conversion operator from RHS? I know use-cases for this are limited, but=
 are they <i>that</i> limited?<br><br>=C2=A0<br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhGFVmqMCRqmbzrXsL%2BuC_Z%2BR3_d=
tEt9H8AEYPcSt8HQQg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGFVmqM=
CRqmbzrXsL%2BuC_Z%2BR3_dtEt9H8AEYPcSt8HQQg%40mail.gmail.com</a>.<br />

--001a114228b888e4ee05374dc4d5--

.

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

On Sun, Jul 10, 2016 at 9:20 PM, D. B. <db0451@gmail.com> wrote:

> On Sun, Jul 10, 2016 at 9:10 PM, <jeff@unbuggy.com> wrote:
>
>> _ is already used as a placeholder in the MPL. It's also sometimes used
>> as a local macro name.  You have a neat idea, but _ seems pretty well
>> spoken for.  It's also unclear that this proposal would solve a real pain
>> point, or whether it's convenience would be outweighed by (arguably) less
>> readable code.
>>
>> I would find the feature more useful if it offered slightly less
>> functionality; in particular, I'd like a guarantee that no operation at all
>> can be performed on such variables except the automatic destruction at end
>> of scope.
>>
>> To these ends, would it make sense to dispense with the variable name
>> altogether, making the objects truly anonymous?
>>
>> auto = std::lock_guard<std::mutex>(mtx1);
>> auto = std::lock_guard<std::mutex>(mtx2);
>>
>
>
> Can we be sure no one will ever want to specify a different type at LHS in
> order to force a conversion operator from RHS? I know use-cases for this
> are limited, but are they *that* limited?
>
>
Course, maybe i'm just being overly literal, and you meant that "auto"
could be any type, in which case, carry on

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFPp%3D%3Di3z5%2BCP24w60RPYiS7hcfgZ2cbTrckbk3Ax424A%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jul 10, 2016 at 9:20 PM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto:=
db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><span class=3D"">On Sun, Jul 10, 2016 at 9:10=
 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:jeff@unbuggy.com" target=3D"_=
blank">jeff@unbuggy.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">_ is already used as a placeholder in the MPL. It&#39;s also sometimes=
 used as a local macro name.=C2=A0 You have a neat idea, but _ seems pretty=
 well spoken for.=C2=A0 It&#39;s also unclear that this proposal would solv=
e a real pain point, or whether it&#39;s convenience would be outweighed by=
 (arguably) less readable code.<br>
<br>
I would find the feature more useful if it offered slightly less functional=
ity; in particular, I&#39;d like a guarantee that no operation at all can b=
e performed on such variables except the automatic destruction at end of sc=
ope.<br>
<br>
To these ends, would it make sense to dispense with the variable name altog=
ether, making the objects truly anonymous?<br>
<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(mtx1);<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(mtx2);<br>
<span></span></blockquote><div><br><br></div></span><div>Can we be sure no =
one will ever want to specify a different type at LHS in order to force a c=
onversion operator from RHS? I know use-cases for this are limited, but are=
 they <i>that</i> limited?<br><br></div></div></div></div></blockquote><div=
><br></div><div>Course, maybe i&#39;m just being overly literal, and you me=
ant that &quot;auto&quot; could be any type, in which case, carry on <br></=
div></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CACGiwhFPp%3D%3Di3z5%2BCP24w60RPYiS7h=
cfgZ2cbTrckbk3Ax424A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFPp%=
3D%3Di3z5%2BCP24w60RPYiS7hcfgZ2cbTrckbk3Ax424A%40mail.gmail.com</a>.<br />

--001a113d7b2e70f09d05374dc8f1--

.

------=_Part_381_2110200832.1468182599745
Content-Type: multipart/alternative;
 boundary="----=_Part_382_1184511408.1468182599745"

------=_Part_382_1184511408.1468182599745
Content-Type: text/plain; charset=UTF-8

Agree with D.B., I'd not remove this from the original idea. Not allowing
referencing _ once it's
declared multiple times in the same scope (a case that would exist solely
after the feature getting in)
seems acceptable tough. It's Tony V E original proposition in the previous
thread.

Em domingo, 10 de julho de 2016 17:20:34 UTC-3, D. B. escreveu:
>
> On Sun, Jul 10, 2016 at 9:10 PM, <je...@unbuggy.com <javascript:>> wrote:
>
>> _ is already used as a placeholder in the MPL. It's also sometimes used
>> as a local macro name.  You have a neat idea, but _ seems pretty well
>> spoken for.  It's also unclear that this proposal would solve a real pain
>> point, or whether it's convenience would be outweighed by (arguably) less
>> readable code.
>>
>> I would find the feature more useful if it offered slightly less
>> functionality; in particular, I'd like a guarantee that no operation at all
>> can be performed on such variables except the automatic destruction at end
>> of scope.
>>
>> To these ends, would it make sense to dispense with the variable name
>> altogether, making the objects truly anonymous?
>>
>> auto = std::lock_guard<std::mutex>(mtx1);
>> auto = std::lock_guard<std::mutex>(mtx2);
>>
>
>
> Can we be sure no one will ever want to specify a different type at LHS in
> order to force a conversion operator from RHS? I know use-cases for this
> are limited, but are they *that* limited?
>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1a21c7dd-b593-4abd-8f0a-69088b0875c0%40isocpp.org.

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

<div dir=3D"ltr">Agree with D.B., I&#39;d not remove this from the original=
 idea. Not allowing referencing _ once it&#39;s<br>declared multiple times =
in the same scope (a case that would exist solely after the feature getting=
 in)<br>seems acceptable tough. It&#39;s Tony V E original proposition in t=
he previous thread.<br><br>Em domingo, 10 de julho de 2016 17:20:34 UTC-3, =
D. B.  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote">On Sun, Jul 10, 2016 at 9:10 PM,  <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"FYXST7chCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">je...@unbuggy.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">_ is already used as a placeholder in the MPL. It&#39;s also some=
times used as a local macro name.=C2=A0 You have a neat idea, but _ seems p=
retty well spoken for.=C2=A0 It&#39;s also unclear that this proposal would=
 solve a real pain point, or whether it&#39;s convenience would be outweigh=
ed by (arguably) less readable code.<br>
<br>
I would find the feature more useful if it offered slightly less functional=
ity; in particular, I&#39;d like a guarantee that no operation at all can b=
e performed on such variables except the automatic destruction at end of sc=
ope.<br>
<br>
To these ends, would it make sense to dispense with the variable name altog=
ether, making the objects truly anonymous?<br>
<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(<wbr>mtx1);<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(<wbr>mtx2);<br>
<span></span></blockquote><div><br><br></div><div>Can we be sure no one wil=
l ever want to specify a different type at LHS in order to force a conversi=
on operator from RHS? I know use-cases for this are limited, but are they <=
i>that</i> limited?<br><br>=C2=A0<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1a21c7dd-b593-4abd-8f0a-69088b0875c0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1a21c7dd-b593-4abd-8f0a-69088b0875c0=
%40isocpp.org</a>.<br />

------=_Part_382_1184511408.1468182599745--

------=_Part_381_2110200832.1468182599745--

.

------=_Part_11635_1323620049.1468182816372
Content-Type: multipart/alternative;
 boundary="----=_Part_11636_1419556433.1468182816372"

------=_Part_11636_1419556433.1468182816372
Content-Type: text/plain; charset=UTF-8

By the way, fyi, the discussion referred by Ville tells about using __
instead of _

Em domingo, 10 de julho de 2016 17:30:00 UTC-3, Francisco Lopes escreveu:
>
> Agree with D.B., I'd not remove this from the original idea. Not allowing
> referencing _ once it's
> declared multiple times in the same scope (a case that would exist solely
> after the feature getting in)
> seems acceptable tough. It's Tony V E original proposition in the previous
> thread.
>
> Em domingo, 10 de julho de 2016 17:20:34 UTC-3, D. B. escreveu:
>>
>> On Sun, Jul 10, 2016 at 9:10 PM, <je...@unbuggy.com> wrote:
>>
>>> _ is already used as a placeholder in the MPL. It's also sometimes used
>>> as a local macro name.  You have a neat idea, but _ seems pretty well
>>> spoken for.  It's also unclear that this proposal would solve a real pain
>>> point, or whether it's convenience would be outweighed by (arguably) less
>>> readable code.
>>>
>>> I would find the feature more useful if it offered slightly less
>>> functionality; in particular, I'd like a guarantee that no operation at all
>>> can be performed on such variables except the automatic destruction at end
>>> of scope.
>>>
>>> To these ends, would it make sense to dispense with the variable name
>>> altogether, making the objects truly anonymous?
>>>
>>> auto = std::lock_guard<std::mutex>(mtx1);
>>> auto = std::lock_guard<std::mutex>(mtx2);
>>>
>>
>>
>> Can we be sure no one will ever want to specify a different type at LHS
>> in order to force a conversion operator from RHS? I know use-cases for this
>> are limited, but are they *that* limited?
>>
>>
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ffd5cbbf-7bbe-4b4c-af0b-063163eeb502%40isocpp.org.

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

<div dir=3D"ltr">By the way, fyi, the discussion referred by Ville tells ab=
out using __ instead of _<br><br>Em domingo, 10 de julho de 2016 17:30:00 U=
TC-3, Francisco Lopes  escreveu:<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">Agree with D.B., I&#39;d not remove this from the origin=
al idea. Not allowing referencing _ once it&#39;s<br>declared multiple time=
s in the same scope (a case that would exist solely after the feature getti=
ng in)<br>seems acceptable tough. It&#39;s Tony V E original proposition in=
 the previous thread.<br><br>Em domingo, 10 de julho de 2016 17:20:34 UTC-3=
, D. B.  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote">On Sun, Jul 10, 2016 at 9:10 PM,  <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">je...@unbuggy.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">_ is already used as a placeholder in the M=
PL. It&#39;s also sometimes used as a local macro name.=C2=A0 You have a ne=
at idea, but _ seems pretty well spoken for.=C2=A0 It&#39;s also unclear th=
at this proposal would solve a real pain point, or whether it&#39;s conveni=
ence would be outweighed by (arguably) less readable code.<br>
<br>
I would find the feature more useful if it offered slightly less functional=
ity; in particular, I&#39;d like a guarantee that no operation at all can b=
e performed on such variables except the automatic destruction at end of sc=
ope.<br>
<br>
To these ends, would it make sense to dispense with the variable name altog=
ether, making the objects truly anonymous?<br>
<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(<wbr>mtx1);<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(<wbr>mtx2);<br>
<span></span></blockquote><div><br><br></div><div>Can we be sure no one wil=
l ever want to specify a different type at LHS in order to force a conversi=
on operator from RHS? I know use-cases for this are limited, but are they <=
i>that</i> limited?<br><br>=C2=A0<br></div></div></div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ffd5cbbf-7bbe-4b4c-af0b-063163eeb502%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ffd5cbbf-7bbe-4b4c-af0b-063163eeb502=
%40isocpp.org</a>.<br />

------=_Part_11636_1419556433.1468182816372--

------=_Part_11635_1323620049.1468182816372--

.

------=_Part_7163_1264236742.1468185441445
Content-Type: multipart/alternative;
 boundary="----=_Part_7164_1572706642.1468185441446"

------=_Part_7164_1572706642.1468185441446
Content-Type: text/plain; charset=UTF-8

Related: I just noticed that it seems compiler writers have to special-case
treatment of
std guards to not give unused variable warnings?

#include <mutex>
#include <iostream>

using namespace std;

mutex m;

int main() {
    lock_guard<mutex> a(m);
    int b{0};
}

g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp && ./a.out

main.cpp: In function 'int main()':

main.cpp:10:9: warning: unused variable 'b' [-Wunused-variable]

     int b(0);


So, the unused variable analysis have to care about not warning on special
cases
where non-usage is the norm.

Em domingo, 10 de julho de 2016 17:33:36 UTC-3, Francisco Lopes escreveu:
>
> By the way, fyi, the discussion referred by Ville tells about using __
> instead of _
>
> Em domingo, 10 de julho de 2016 17:30:00 UTC-3, Francisco Lopes escreveu:
>>
>> Agree with D.B., I'd not remove this from the original idea. Not allowing
>> referencing _ once it's
>> declared multiple times in the same scope (a case that would exist solely
>> after the feature getting in)
>> seems acceptable tough. It's Tony V E original proposition in the
>> previous thread.
>>
>> Em domingo, 10 de julho de 2016 17:20:34 UTC-3, D. B. escreveu:
>>>
>>> On Sun, Jul 10, 2016 at 9:10 PM, <je...@unbuggy.com> wrote:
>>>
>>>> _ is already used as a placeholder in the MPL. It's also sometimes used
>>>> as a local macro name.  You have a neat idea, but _ seems pretty well
>>>> spoken for.  It's also unclear that this proposal would solve a real pain
>>>> point, or whether it's convenience would be outweighed by (arguably) less
>>>> readable code.
>>>>
>>>> I would find the feature more useful if it offered slightly less
>>>> functionality; in particular, I'd like a guarantee that no operation at all
>>>> can be performed on such variables except the automatic destruction at end
>>>> of scope.
>>>>
>>>> To these ends, would it make sense to dispense with the variable name
>>>> altogether, making the objects truly anonymous?
>>>>
>>>> auto = std::lock_guard<std::mutex>(mtx1);
>>>> auto = std::lock_guard<std::mutex>(mtx2);
>>>>
>>>
>>>
>>> Can we be sure no one will ever want to specify a different type at LHS
>>> in order to force a conversion operator from RHS? I know use-cases for this
>>> are limited, but are they *that* limited?
>>>
>>>
>>>
>>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bd2aa7e5-dc60-480f-9406-b572aa59b6c6%40isocpp.org.

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

<div dir=3D"ltr">Related: I just noticed that it seems compiler writers hav=
e to special-case treatment of<br>std guards to not give unused variable wa=
rnings?<br><br><span style=3D"font-family: courier new,monospace;">#include=
 &lt;mutex&gt;<br>#include &lt;iostream&gt;<br><br>using namespace std;<br>=
<br>mutex m;<br><br>int main() {<br>=C2=A0=C2=A0=C2=A0 lock_guard&lt;mutex&=
gt; a(m);<br>=C2=A0=C2=A0=C2=A0 int b{0};<br>}<br><br></span><div><pre clas=
s=3D"f0" style=3D"display: inline-block; margin:0; padding:0; "><span style=
=3D"font-family: courier new,monospace;">g++ -std=3Dc++14 -O2 -Wall -pedant=
ic -pthread main.cpp &amp;&amp; ./a.out
</span></pre></div><div><pre class=3D"f0" style=3D"display: inline-block; m=
argin:0; padding:0; "><span style=3D"font-family: courier new,monospace;">m=
ain.cpp: In function &#39;int main()&#39;:</span></pre></div><div><pre clas=
s=3D"f0" style=3D"display: inline-block; margin: 0px; padding: 0px; cursor:=
 auto;"><span style=3D"font-family: courier new,monospace;">main.cpp:10:9: =
warning: unused variable &#39;b&#39; [-Wunused-variable]</span></pre></div>=
<div><pre class=3D"f0" style=3D"display: inline-block; margin:0; padding:0;=
 "><span style=3D"font-family: courier new,monospace;">     int b(0);</span=
></pre></div><br>So, the unused variable analysis have to care about not wa=
rning on special cases<br>where non-usage is the norm.<br><br>Em domingo, 1=
0 de julho de 2016 17:33:36 UTC-3, Francisco Lopes  escreveu:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">By the way, fyi, the discus=
sion referred by Ville tells about using __ instead of _<br><br>Em domingo,=
 10 de julho de 2016 17:30:00 UTC-3, Francisco Lopes  escreveu:<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">Agree with D.B., I&#39;d not r=
emove this from the original idea. Not allowing referencing _ once it&#39;s=
<br>declared multiple times in the same scope (a case that would exist sole=
ly after the feature getting in)<br>seems acceptable tough. It&#39;s Tony V=
 E original proposition in the previous thread.<br><br>Em domingo, 10 de ju=
lho de 2016 17:20:34 UTC-3, D. B.  escreveu:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Sun, Jul 10, 2=
016 at 9:10 PM,  <span dir=3D"ltr">&lt;<a rel=3D"nofollow">je...@unbuggy.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_ is already used=
 as a placeholder in the MPL. It&#39;s also sometimes used as a local macro=
 name.=C2=A0 You have a neat idea, but _ seems pretty well spoken for.=C2=
=A0 It&#39;s also unclear that this proposal would solve a real pain point,=
 or whether it&#39;s convenience would be outweighed by (arguably) less rea=
dable code.<br>
<br>
I would find the feature more useful if it offered slightly less functional=
ity; in particular, I&#39;d like a guarantee that no operation at all can b=
e performed on such variables except the automatic destruction at end of sc=
ope.<br>
<br>
To these ends, would it make sense to dispense with the variable name altog=
ether, making the objects truly anonymous?<br>
<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(<wbr>mtx1);<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(<wbr>mtx2);<br>
<span></span></blockquote><div><br><br></div><div>Can we be sure no one wil=
l ever want to specify a different type at LHS in order to force a conversi=
on operator from RHS? I know use-cases for this are limited, but are they <=
i>that</i> limited?<br><br>=C2=A0<br></div></div></div></div>
</blockquote></div></blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bd2aa7e5-dc60-480f-9406-b572aa59b6c6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bd2aa7e5-dc60-480f-9406-b572aa59b6c6=
%40isocpp.org</a>.<br />

------=_Part_7164_1572706642.1468185441446--

------=_Part_7163_1264236742.1468185441445--

.

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

On 10 July 2016 at 16:17, Francisco Lopes <
francisco.mailing.lists@oblita.com> wrote:

> Related: I just noticed that it seems compiler writers have to
> special-case treatment of
> std guards to not give unused variable warnings?
>

Far more likely that they don't warn on types that have non-trivial
destructors.

--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMdqinx22J4Ry9bPeVpr%3DkXHpdpnyiUUZ_%3DzgEQ8AnzGw%40mail.gmail.com.

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

<div dir=3D"ltr">On 10 July 2016 at 16:17, Francisco Lopes <span dir=3D"ltr=
">&lt;<a href=3D"mailto:francisco.mailing.lists@oblita.com" target=3D"_blan=
k">francisco.mailing.lists@oblita.com</a>&gt;</span> wrote:<br><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">Related: I just noticed that it seems compiler writers hav=
e to special-case treatment of<br>std guards to not give unused variable wa=
rnings?<br></div></blockquote><div><br></div><div>Far more likely that they=
 don&#39;t warn on types that have non-trivial destructors.</div><div><br><=
/div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_si=
gnature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&=
quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" targ=
et=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div></d=
iv></div></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMdqinx22J4Ry9bPeVpr%3DkXHpdp=
nyiUUZ_%3DzgEQ8AnzGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMd=
qinx22J4Ry9bPeVpr%3DkXHpdpnyiUUZ_%3DzgEQ8AnzGw%40mail.gmail.com</a>.<br />

--001a1146f44cf9281905374eaff8--

.

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

On 10 July 2016 at 15:20, D. B. <db0451@gmail.com> wrote:

> On Sun, Jul 10, 2016 at 9:10 PM, <jeff@unbuggy.com> wrote:
>
>> _ is already used as a placeholder in the MPL. It's also sometimes used
>> as a local macro name.  You have a neat idea, but _ seems pretty well
>> spoken for.  It's also unclear that this proposal would solve a real pain
>> point, or whether it's convenience would be outweighed by (arguably) less
>> readable code.
>>
>> I would find the feature more useful if it offered slightly less
>> functionality; in particular, I'd like a guarantee that no operation at all
>> can be performed on such variables except the automatic destruction at end
>> of scope.
>>
>> To these ends, would it make sense to dispense with the variable name
>> altogether, making the objects truly anonymous?
>>
>> auto = std::lock_guard<std::mutex>(mtx1);
>> auto = std::lock_guard<std::mutex>(mtx2);
>>
>
>
> Can we be sure no one will ever want to specify a different type at LHS in
> order to force a conversion operator from RHS? I know use-cases for this
> are limited, but are they *that* limited?
>

Can we be sure?  Of course not.

If the user wishes to do this, they should be able to either cast the
result or just name a variable.  It need not cover every possible weird use
case.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN-PA4KmfmBvKe1jDS%2BpdmpE3%3DpbDLZwGzPYkbWf9sSDQ%40mail.gmail.com.

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

<div dir=3D"ltr">On 10 July 2016 at 15:20, D. B. <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;<=
/span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><span class=3D"">On Sun, Jul 10, 2016 at 9:10 PM,  <=
span dir=3D"ltr">&lt;<a href=3D"mailto:jeff@unbuggy.com" target=3D"_blank">=
jeff@unbuggy.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_ =
is already used as a placeholder in the MPL. It&#39;s also sometimes used a=
s a local macro name.=C2=A0 You have a neat idea, but _ seems pretty well s=
poken for.=C2=A0 It&#39;s also unclear that this proposal would solve a rea=
l pain point, or whether it&#39;s convenience would be outweighed by (argua=
bly) less readable code.<br>
<br>
I would find the feature more useful if it offered slightly less functional=
ity; in particular, I&#39;d like a guarantee that no operation at all can b=
e performed on such variables except the automatic destruction at end of sc=
ope.<br>
<br>
To these ends, would it make sense to dispense with the variable name altog=
ether, making the objects truly anonymous?<br>
<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(mtx1);<br>
auto =3D std::lock_guard&lt;std::mutex&gt;(mtx2);<br>
<span></span></blockquote><div><br><br></div></span><div>Can we be sure no =
one will ever want to specify a different type at LHS in order to force a c=
onversion operator from RHS? I know use-cases for this are limited, but are=
 they <i>that</i> limited?<br></div></div></div></div></blockquote><div><br=
></div><div>Can we be sure?=C2=A0 Of course not.</div><div><br></div><div>I=
f the user wishes to do this, they should be able to either cast the result=
 or just name a variable.=C2=A0 It need not cover every possible weird use =
case.</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gm=
ail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quo=
t;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com=
" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</d=
iv></div></div></div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN-PA4KmfmBvKe1jDS%2BpdmpE3%3=
DpbDLZwGzPYkbWf9sSDQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BN-=
PA4KmfmBvKe1jDS%2BpdmpE3%3DpbDLZwGzPYkbWf9sSDQ%40mail.gmail.com</a>.<br />

--94eb2c05ce5ee877c305374ec944--

.

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

On 10 July 2016 at 15:10, <jeff@unbuggy.com> wrote:

> _ is already used as a placeholder in the MPL. It's also sometimes used as
> a local macro name.  You have a neat idea, but _ seems pretty well spoken
> for.  It's also unclear that this proposal would solve a real pain point,
> or whether it's convenience would be outweighed by (arguably) less readable
> code.
>
> I would find the feature more useful if it offered slightly less
> functionality; in particular, I'd like a guarantee that no operation at all
> can be performed on such variables except the automatic destruction at end
> of scope.
>

This is, of course the problem.  You are looking to change functionality
which has been there since C90 (or even longer).  This would break working
code and introduce an incompatibility with C.  You could possibly mitigate
the latter with a complicated rule (for instance, it only has the desired
semantics for types with non-trivial destructors), but if you are stealing
a name, you cannot help but break the former.

__ is different than _ in that it is reserved for implementations, so
theoretically the breakage wouldn't be as bad.

IMO, finding a way to express this w/o using an identifier is a better
approach (although then comes the debate about the feature being worth the
cost of new syntax).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP8HeVQ7dq1vP%3DuKO%2Bt_r00cVj%2Bo2CVi40JNcTZp41QdA%40mail.gmail.com.

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

<div dir=3D"ltr">On 10 July 2016 at 15:10,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jeff@unbuggy.com" target=3D"_blank">jeff@unbuggy.com</a>&gt;</sp=
an> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">_ is already used as a placeholder in the MPL. It&#=
39;s also sometimes used as a local macro name.=C2=A0 You have a neat idea,=
 but _ seems pretty well spoken for.=C2=A0 It&#39;s also unclear that this =
proposal would solve a real pain point, or whether it&#39;s convenience wou=
ld be outweighed by (arguably) less readable code.<br>
<br>
I would find the feature more useful if it offered slightly less functional=
ity; in particular, I&#39;d like a guarantee that no operation at all can b=
e performed on such variables except the automatic destruction at end of sc=
ope.<br></blockquote><div><br></div><div>This is, of course the problem.=C2=
=A0 You are looking to change functionality which has been there since C90 =
(or even longer).=C2=A0 This would break working code and introduce an inco=
mpatibility with C.=C2=A0 You could possibly mitigate the latter with a com=
plicated rule (for instance, it only has the desired semantics for types wi=
th non-trivial destructors), but if you are stealing a name, you cannot hel=
p but break the former.</div><div><br></div><div>__ is different than _ in =
that it is reserved for implementations, so theoretically the breakage woul=
dn&#39;t be as bad.</div><div><br></div><div>IMO, finding a way to express =
this w/o using an identifier is a better approach (although then comes the =
debate about the feature being worth the cost of new syntax).</div></div>--=
 <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div=
 dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=
=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div></=
div></div>
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BP8HeVQ7dq1vP%3DuKO%2Bt_r00cV=
j%2Bo2CVi40JNcTZp41QdA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
P8HeVQ7dq1vP%3DuKO%2Bt_r00cVj%2Bo2CVi40JNcTZp41QdA%40mail.gmail.com</a>.<br=
 />

--001a113ef2048e9e4c05374ef95d--

.

On 11 July 2016 at 00:46, Nevin Liber <nevin@eviloverlord.com> wrote:
> IMO, finding a way to express this w/o using an identifier is a better
> approach (although then comes the debate about the feature being worth the
> cost of new syntax).


Also consider an idea like
Foobar = f();
vs. the syntax that already has a meaning, aka
Foobar() = f();
and the unfortunate subtlety of that difference.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa4XQEJmSNHd9-b-CNr_QBm8ZicZT1Q%3Do-t5N0XTu_EcA%40mail.gmail.com.

.

------=_Part_521_407637055.1468187839982
Content-Type: multipart/alternative;
 boundary="----=_Part_522_1639853388.1468187839982"

------=_Part_522_1639853388.1468187839982
Content-Type: text/plain; charset=UTF-8



Em domingo, 10 de julho de 2016 18:46:59 UTC-3, Nevin ":-)" Liber escreveu:
>
> On 10 July 2016 at 15:10, <je...@unbuggy.com <javascript:>> wrote:
>
>> _ is already used as a placeholder in the MPL. It's also sometimes used
>> as a local macro name.  You have a neat idea, but _ seems pretty well
>> spoken for.  It's also unclear that this proposal would solve a real pain
>> point, or whether it's convenience would be outweighed by (arguably) less
>> readable code.
>>
>> I would find the feature more useful if it offered slightly less
>> functionality; in particular, I'd like a guarantee that no operation at all
>> can be performed on such variables except the automatic destruction at end
>> of scope.
>>
>
> This is, of course the problem.  You are looking to change functionality
> which has been there since C90 (or even longer).  This would break working
> code and introduce an incompatibility with C.  You could possibly mitigate
> the latter with a complicated rule (for instance, it only has the desired
> semantics for types with non-trivial destructors), but if you are stealing
> a name, you cannot help but break the former.
>

A far as I can see, both my proposal at the top, as well as Tony suggestion
of disallowing being able to refer
to _ when multiple exist declarations exist in the same scope, are
backwards compatible with what's allowed
today right? Counter example?

Also, you're correct about the compiler not giving non-used variable
warnings for objects with non-trivial destructors.
I wonder whether the application of that is beneficial as such general rule
or not. Non-trivial destructor are quite
an implicit use of variable.

__ is different than _ in that it is reserved for implementations, so
> theoretically the breakage wouldn't be as bad.
>
> IMO, finding a way to express this w/o using an identifier is a better
> approach (although then comes the debate about the feature being worth the
> cost of new syntax).
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>
>  +1-847-691-1404
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2c34e0f6-2b72-4ef9-8851-20c42fee83dd%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Em domingo, 10 de julho de 2016 18:46:59 UTC-3, Ne=
vin &quot;:-)&quot; Liber  escreveu:<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">On 10 July 2016 at 15:10,  <span dir=3D"ltr">&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"A-bxf24mCgA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">je...@un=
buggy.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">_ is already used as a placeholder in the MPL. It&#3=
9;s also sometimes used as a local macro name.=C2=A0 You have a neat idea, =
but _ seems pretty well spoken for.=C2=A0 It&#39;s also unclear that this p=
roposal would solve a real pain point, or whether it&#39;s convenience woul=
d be outweighed by (arguably) less readable code.<br>
<br>
I would find the feature more useful if it offered slightly less functional=
ity; in particular, I&#39;d like a guarantee that no operation at all can b=
e performed on such variables except the automatic destruction at end of sc=
ope.<br></blockquote><div><br></div><div>This is, of course the problem.=C2=
=A0 You are looking to change functionality which has been there since C90 =
(or even longer).=C2=A0 This would break working code and introduce an inco=
mpatibility with C.=C2=A0 You could possibly mitigate the latter with a com=
plicated rule (for instance, it only has the desired semantics for types wi=
th non-trivial destructors), but if you are stealing a name, you cannot hel=
p but break the former.<br></div></div></div></div></blockquote><div><br>A =
far as I can see, both my proposal at the top, as well as Tony suggestion o=
f disallowing being able to refer<br>to _ when multiple exist declarations =
exist in the same scope, are backwards compatible with what&#39;s allowed<b=
r>today right? Counter example?<br><br>Also, you&#39;re correct about the c=
ompiler not giving non-used variable warnings for objects with non-trivial =
destructors.<br>I wonder whether the application of that is beneficial as s=
uch general rule or not. Non-trivial destructor are quite<br>an implicit us=
e of variable. <br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>__ is different than _=
 in that it is reserved for implementations, so theoretically the breakage =
wouldn&#39;t be as bad.</div><div><br></div><div>IMO, finding a way to expr=
ess this w/o using an identifier is a better approach (although then comes =
the debate about the feature being worth the cost of new syntax).</div></di=
v>-- <br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot=
;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"javascript:" target=3D"_blank"=
 gdf-obfuscated-mailto=3D"A-bxf24mCgAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;">ne...@eviloverlord.com</a><wbr>&gt; =C2=A0+1-8=
47-691-1404</div></div></div></div></div>
</div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2c34e0f6-2b72-4ef9-8851-20c42fee83dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2c34e0f6-2b72-4ef9-8851-20c42fee83dd=
%40isocpp.org</a>.<br />

------=_Part_522_1639853388.1468187839982--

------=_Part_521_407637055.1468187839982--

.

------=_Part_405_121155153.1468189106784
Content-Type: multipart/alternative;
 boundary="----=_Part_406_443489562.1468189106784"

------=_Part_406_443489562.1468189106784
Content-Type: text/plain; charset=UTF-8

Then, I'm just *really* surprised noticing this after this many years that
a simple "unused" std::string doesn't give a warning because of that
non-trivial destructor rule.

For me this is not a feature, it's sad!

I imagine a newcomer asking an instructor: "hey why int i gives a unused
warning but string s not?"

Em domingo, 10 de julho de 2016 18:57:20 UTC-3, Francisco Lopes escreveu:
>
>
>
> Em domingo, 10 de julho de 2016 18:46:59 UTC-3, Nevin ":-)" Liber escreveu:
>>
>> On 10 July 2016 at 15:10, <je...@unbuggy.com> wrote:
>>
>>> _ is already used as a placeholder in the MPL. It's also sometimes used
>>> as a local macro name.  You have a neat idea, but _ seems pretty well
>>> spoken for.  It's also unclear that this proposal would solve a real pain
>>> point, or whether it's convenience would be outweighed by (arguably) less
>>> readable code.
>>>
>>> I would find the feature more useful if it offered slightly less
>>> functionality; in particular, I'd like a guarantee that no operation at all
>>> can be performed on such variables except the automatic destruction at end
>>> of scope.
>>>
>>
>> This is, of course the problem.  You are looking to change functionality
>> which has been there since C90 (or even longer).  This would break working
>> code and introduce an incompatibility with C.  You could possibly mitigate
>> the latter with a complicated rule (for instance, it only has the desired
>> semantics for types with non-trivial destructors), but if you are stealing
>> a name, you cannot help but break the former.
>>
>
> A far as I can see, both my proposal at the top, as well as Tony
> suggestion of disallowing being able to refer
> to _ when multiple exist declarations exist in the same scope, are
> backwards compatible with what's allowed
> today right? Counter example?
>
> Also, you're correct about the compiler not giving non-used variable
> warnings for objects with non-trivial destructors.
> I wonder whether the application of that is beneficial as such general
> rule or not. Non-trivial destructor are quite
> an implicit use of variable.
>
> __ is different than _ in that it is reserved for implementations, so
>> theoretically the breakage wouldn't be as bad.
>>
>> IMO, finding a way to express this w/o using an identifier is a better
>> approach (although then comes the debate about the feature being worth the
>> cost of new syntax).
>> --
>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404
>>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/50f431c1-50cb-42ca-a368-4b0fdf5e57f2%40isocpp.org.

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

<div dir=3D"ltr">Then, I&#39;m just *really* surprised noticing this after =
this many years that<br>a simple &quot;unused&quot; std::string doesn&#39;t=
 give a warning because of that<br>non-trivial destructor rule.<br><br>For =
me this is not a feature, it&#39;s sad!<br><br>I imagine a newcomer asking =
an instructor: &quot;hey why int i gives a unused warning but string s not?=
&quot;<br><br>Em domingo, 10 de julho de 2016 18:57:20 UTC-3, Francisco Lop=
es  escreveu:<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">=
<br><br>Em domingo, 10 de julho de 2016 18:46:59 UTC-3, Nevin &quot;:-)&quo=
t; Liber  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>On 10 July 2016 at 15:10,  <span dir=3D"ltr">&lt;<a rel=3D"nofollow">je...=
@unbuggy.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">_ is already used as a placeholder in the MPL. It=
&#39;s also sometimes used as a local macro name.=C2=A0 You have a neat ide=
a, but _ seems pretty well spoken for.=C2=A0 It&#39;s also unclear that thi=
s proposal would solve a real pain point, or whether it&#39;s convenience w=
ould be outweighed by (arguably) less readable code.<br>
<br>
I would find the feature more useful if it offered slightly less functional=
ity; in particular, I&#39;d like a guarantee that no operation at all can b=
e performed on such variables except the automatic destruction at end of sc=
ope.<br></blockquote><div><br></div><div>This is, of course the problem.=C2=
=A0 You are looking to change functionality which has been there since C90 =
(or even longer).=C2=A0 This would break working code and introduce an inco=
mpatibility with C.=C2=A0 You could possibly mitigate the latter with a com=
plicated rule (for instance, it only has the desired semantics for types wi=
th non-trivial destructors), but if you are stealing a name, you cannot hel=
p but break the former.<br></div></div></div></div></blockquote><div><br>A =
far as I can see, both my proposal at the top, as well as Tony suggestion o=
f disallowing being able to refer<br>to _ when multiple exist declarations =
exist in the same scope, are backwards compatible with what&#39;s allowed<b=
r>today right? Counter example?<br><br>Also, you&#39;re correct about the c=
ompiler not giving non-used variable warnings for objects with non-trivial =
destructors.<br>I wonder whether the application of that is beneficial as s=
uch general rule or not. Non-trivial destructor are quite<br>an implicit us=
e of variable. <br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div>__ is different than _ in t=
hat it is reserved for implementations, so theoretically the breakage would=
n&#39;t be as bad.</div><div><br></div><div>IMO, finding a way to express t=
his w/o using an identifier is a better approach (although then comes the d=
ebate about the feature being worth the cost of new syntax).</div></div>-- =
<br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&=
quot; Liber=C2=A0 &lt;mailto:<a rel=3D"nofollow">ne...@eviloverlord.com</a>=
<wbr>&gt; =C2=A0+1-847-691-1404</div></div></div></div></div>
</div></div>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/50f431c1-50cb-42ca-a368-4b0fdf5e57f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/50f431c1-50cb-42ca-a368-4b0fdf5e57f2=
%40isocpp.org</a>.<br />

------=_Part_406_443489562.1468189106784--

------=_Part_405_121155153.1468189106784--

.

On Sun, Jul 10, 2016 at 4:51 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 11 July 2016 at 00:46, Nevin Liber <nevin@eviloverlord.com> wrote:
>> IMO, finding a way to express this w/o using an identifier is a better
>> approach (although then comes the debate about the feature being worth the
>> cost of new syntax).
>
>
> Also consider an idea like
> Foobar = f();
> vs. the syntax that already has a meaning, aka
> Foobar() = f();
> and the unfortunate subtlety of that difference.

My suggestion has always been a simple

  with (auto lk = unique_lock(lk)) {
  }

which is already available as `if (auto ...; true)`,
and

  with (lock_guard(lk)) {
  }

whose the wording for introducing a unique name
has already presented in the structured binding
proposal.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://blog.miator.net/

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuBQSfGCbLxpZYgyARX40occngg_c_dkH82x3vXs2W3BGA%40mail.gmail.com.

.

------=_Part_3139_1648501641.1468194243214
Content-Type: multipart/alternative;
 boundary="----=_Part_3140_1777660646.1468194243214"

------=_Part_3140_1777660646.1468194243214
Content-Type: text/plain; charset=UTF-8

Wait a minute. Let's think about what we just added to C++: structured
binding:

auto [a, b] = ...;

Now, the way structured binding works is that it takes the expression and
stores it in a hidden variable. It then gets references to the members,
either directly from public members or with a particular interface. That's
how the concept is semantically defined:

auto &&temp = make_pair(3, 4.5f);
auto &a = temp.first;
auto &b = temp.second;

So... what happens if we do this:

auto [] = ...;

If we allowed this to work for any type, then what we'd be saying is that
the expression would be stored in... a *hidden variable*. But since the
structured binding list is empty, no references would be extracted from it.
So all we'd have is what we want: an unnamed, unnamable variable that will
be destroyed when scope ends.

So we'd have code like this:

auto[] = scope_exit(...);

I admit that this isn't great syntax. It looks too much like structured
binding. But I think it's better than trying to define that a certain
identifier name would have a new meaning.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f47138a8-2eb8-47df-aa71-80363f4125b7%40isocpp.org.

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

<div dir=3D"ltr">Wait a minute. Let&#39;s think about what we just added to=
 C++: structured binding:<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">auto</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> b</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">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">...;</span></div></code></div><br>Now, the way structured bi=
nding works is that it takes the expression and stores it in a hidden varia=
ble. It then gets references to the members, either directly from public me=
mbers or with a particular interface. That&#39;s how the concept is semanti=
cally defined:<br><br><div class=3D"prettyprint" style=3D"background-color:=
 rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid;=
 border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;=
&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">temp =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> make_pair</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">3</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: #066;" class=
=3D"styled-by-prettify">4.5f</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">a </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> temp</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">first</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-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-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> temp</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">second</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></div></code></div><br>So... what happe=
ns if we do this:<br><br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">...;</span></div></code></div><br>I=
f we allowed this to work for any type, then what we&#39;d be saying is tha=
t the expression would be stored in... a <i>hidden variable</i>. But since =
the structured binding list is empty, no references would be extracted from=
 it. So all we&#39;d have is what we want: an unnamed, unnamable variable t=
hat will be destroyed when scope ends.<br><br>So we&#39;d have code like th=
is:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[]</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> scope_exit</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(...);</span></div></code></=
div><br>I admit that this isn&#39;t great syntax. It looks too much like st=
ructured binding. But I think it&#39;s better than trying to define that a =
certain identifier name would have a new meaning.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f47138a8-2eb8-47df-aa71-80363f4125b7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f47138a8-2eb8-47df-aa71-80363f4125b7=
%40isocpp.org</a>.<br />

------=_Part_3140_1777660646.1468194243214--

------=_Part_3139_1648501641.1468194243214--

.

------=_Part_1219_353283340.1468195173370
Content-Type: multipart/alternative;
 boundary="----=_Part_1220_797011491.1468195173370"

------=_Part_1220_797011491.1468195173370
Content-Type: text/plain; charset=UTF-8

That's interesting Nicol, but what about the other cases? For structured
binding itself
for example, how would I let bindings unnamed? I think this is one of the
more compelling
usecases, structured binding feels a bit lacking without that mechanism.

Em domingo, 10 de julho de 2016 20:44:03 UTC-3, Nicol Bolas escreveu:
>
> Wait a minute. Let's think about what we just added to C++: structured
> binding:
>
> auto [a, b] = ...;
>
> Now, the way structured binding works is that it takes the expression and
> stores it in a hidden variable. It then gets references to the members,
> either directly from public members or with a particular interface. That's
> how the concept is semantically defined:
>
> auto &&temp = make_pair(3, 4.5f);
> auto &a = temp.first;
> auto &b = temp.second;
>
> So... what happens if we do this:
>
> auto [] = ...;
>
> If we allowed this to work for any type, then what we'd be saying is that
> the expression would be stored in... a *hidden variable*. But since the
> structured binding list is empty, no references would be extracted from it.
> So all we'd have is what we want: an unnamed, unnamable variable that will
> be destroyed when scope ends.
>
> So we'd have code like this:
>
> auto[] = scope_exit(...);
>
> I admit that this isn't great syntax. It looks too much like structured
> binding. But I think it's better than trying to define that a certain
> identifier name would have a new meaning.
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5c4e7628-03bb-41c0-b2e2-8ba27491ccf4%40isocpp.org.

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

<div dir=3D"ltr">That&#39;s interesting Nicol, but what about the other cas=
es? For structured binding itself<br>for example, how would I let bindings =
unnamed? I think this is one of the more compelling<br>usecases, structured=
 binding feels a bit lacking without that mechanism.<br><br>Em domingo, 10 =
de julho de 2016 20:44:03 UTC-3, Nicol Bolas  escreveu:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr">Wait a minute. Let&#39;s think ab=
out what we just added to C++: structured binding:<br><br><div style=3D"bac=
kground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:s=
olid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color=
:#008">auto</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">[</span><span style=3D"color:#000">a</span><span style=3D"color:#660">=
,</span><span style=3D"color:#000"> b</span><span style=3D"color:#660">]</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">...;</span><=
/div></code></div><br>Now, the way structured binding works is that it take=
s the expression and stores it in a hidden variable. It then gets reference=
s to the members, either directly from public members or with a particular =
interface. That&#39;s how the concept is semantically defined:<br><br><div =
style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bo=
rder-style:solid;border-width:1px;word-wrap:break-word"><code><div><span st=
yle=3D"color:#008">auto</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">&amp;&amp;</span><span style=3D"color:#000">temp </span><s=
pan style=3D"color:#660">=3D</span><span style=3D"color:#000"> make_pair</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#066">3</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span =
style=3D"color:#066">4.5f</span><span style=3D"color:#660">);</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#008">auto</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">&amp;</span><span s=
tyle=3D"color:#000">a </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> temp</span><span style=3D"color:#660">.</span><span styl=
e=3D"color:#000">first</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">auto</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">&amp;</span><span style=
=3D"color:#000">b </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> temp</span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">second</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br></span></div></code></div><br>So... what happens if we =
do this:<br><br><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code><div><span style=3D"color:#008">auto</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">[]</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#660">...;</span></div></code></div><br>If we allo=
wed this to work for any type, then what we&#39;d be saying is that the exp=
ression would be stored in... a <i>hidden variable</i>. But since the struc=
tured binding list is empty, no references would be extracted from it. So a=
ll we&#39;d have is what we want: an unnamed, unnamable variable that will =
be destroyed when scope ends.<br><br>So we&#39;d have code like this:<br><b=
r><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><=
span style=3D"color:#008">auto</span><span style=3D"color:#660">[]</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span=
 style=3D"color:#000"> scope_exit</span><span style=3D"color:#660">(...);</=
span></div></code></div><br>I admit that this isn&#39;t great syntax. It lo=
oks too much like structured binding. But I think it&#39;s better than tryi=
ng to define that a certain identifier name would have a new meaning.<br></=
div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5c4e7628-03bb-41c0-b2e2-8ba27491ccf4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c4e7628-03bb-41c0-b2e2-8ba27491ccf4=
%40isocpp.org</a>.<br />

------=_Part_1220_797011491.1468195173370--

------=_Part_1219_353283340.1468195173370--

.

------=_Part_481_1003835085.1468195368309
Content-Type: multipart/alternative;
 boundary="----=_Part_482_1806777289.1468195368309"

------=_Part_482_1806777289.1468195368309
Content-Type: text/plain; charset=UTF-8

I mean, not all bindings.

Em domingo, 10 de julho de 2016 20:59:33 UTC-3, Francisco Lopes escreveu:
>
> That's interesting Nicol, but what about the other cases? For structured
> binding itself
> for example, how would I let bindings unnamed? I think this is one of the
> more compelling
> usecases, structured binding feels a bit lacking without that mechanism.
>
> Em domingo, 10 de julho de 2016 20:44:03 UTC-3, Nicol Bolas escreveu:
>>
>> Wait a minute. Let's think about what we just added to C++: structured
>> binding:
>>
>> auto [a, b] = ...;
>>
>> Now, the way structured binding works is that it takes the expression and
>> stores it in a hidden variable. It then gets references to the members,
>> either directly from public members or with a particular interface. That's
>> how the concept is semantically defined:
>>
>> auto &&temp = make_pair(3, 4.5f);
>> auto &a = temp.first;
>> auto &b = temp.second;
>>
>> So... what happens if we do this:
>>
>> auto [] = ...;
>>
>> If we allowed this to work for any type, then what we'd be saying is that
>> the expression would be stored in... a *hidden variable*. But since the
>> structured binding list is empty, no references would be extracted from it.
>> So all we'd have is what we want: an unnamed, unnamable variable that will
>> be destroyed when scope ends.
>>
>> So we'd have code like this:
>>
>> auto[] = scope_exit(...);
>>
>> I admit that this isn't great syntax. It looks too much like structured
>> binding. But I think it's better than trying to define that a certain
>> identifier name would have a new meaning.
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ac282d1a-bb17-4fc2-b654-5e347d5179c2%40isocpp.org.

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

<div dir=3D"ltr">I mean, not all bindings.<br><br>Em domingo, 10 de julho d=
e 2016 20:59:33 UTC-3, Francisco Lopes  escreveu:<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">That&#39;s interesting Nicol, but what =
about the other cases? For structured binding itself<br>for example, how wo=
uld I let bindings unnamed? I think this is one of the more compelling<br>u=
secases, structured binding feels a bit lacking without that mechanism.<br>=
<br>Em domingo, 10 de julho de 2016 20:44:03 UTC-3, Nicol Bolas  escreveu:<=
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">Wait a minute. Let&=
#39;s think about what we just added to C++: structured binding:<br><br><di=
v style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);=
border-style:solid;border-width:1px;word-wrap:break-word"><code><div><span =
style=3D"color:#008">auto</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">[</span><span style=3D"color:#000">a</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> b</span><span style=3D"=
color:#660">]</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">...;</span></div></code></div><br>Now, the way structured binding works=
 is that it takes the expression and stores it in a hidden variable. It the=
n gets references to the members, either directly from public members or wi=
th a particular interface. That&#39;s how the concept is semantically defin=
ed:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb=
(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><co=
de><div><span style=3D"color:#008">auto</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">&amp;&amp;</span><span style=3D"color:#000=
">temp </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> make_pair</span><span style=3D"color:#660">(</span><span style=3D"color=
:#066">3</span><span style=3D"color:#660">,</span><span style=3D"color:#000=
"> </span><span style=3D"color:#066">4.5f</span><span style=3D"color:#660">=
);</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">a=
uto</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&am=
p;</span><span style=3D"color:#000">a </span><span style=3D"color:#660">=3D=
</span><span style=3D"color:#000"> temp</span><span style=3D"color:#660">.<=
/span><span style=3D"color:#000">first</span><span style=3D"color:#660">;</=
span><span style=3D"color:#000"><br></span><span style=3D"color:#008">auto<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">&amp;</=
span><span style=3D"color:#000">b </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> temp</span><span style=3D"color:#660">.</spa=
n><span style=3D"color:#000">second</span><span style=3D"color:#660">;</spa=
n><span style=3D"color:#000"><br></span></div></code></div><br>So... what h=
appens if we do this:<br><br><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wr=
ap:break-word"><code><div><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">[]</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">=3D</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">...;</span></div></code></div><=
br>If we allowed this to work for any type, then what we&#39;d be saying is=
 that the expression would be stored in... a <i>hidden variable</i>. But si=
nce the structured binding list is empty, no references would be extracted =
from it. So all we&#39;d have is what we want: an unnamed, unnamable variab=
le that will be destroyed when scope ends.<br><br>So we&#39;d have code lik=
e this:<br><br><div style=3D"background-color:rgb(250,250,250);border-color=
:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"=
><code><div><span style=3D"color:#008">auto</span><span style=3D"color:#660=
">[]</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> scope_exit</span><span style=3D"color=
:#660">(...);</span></div></code></div><br>I admit that this isn&#39;t grea=
t syntax. It looks too much like structured binding. But I think it&#39;s b=
etter than trying to define that a certain identifier name would have a new=
 meaning.<br></div></blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ac282d1a-bb17-4fc2-b654-5e347d5179c2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac282d1a-bb17-4fc2-b654-5e347d5179c2=
%40isocpp.org</a>.<br />

------=_Part_482_1806777289.1468195368309--

------=_Part_481_1003835085.1468195368309--

.

------=_Part_1198_1931073672.1468199475975
Content-Type: multipart/alternative;
 boundary="----=_Part_1199_1373295689.1468199475975"

------=_Part_1199_1373295689.1468199475975
Content-Type: text/plain; charset=UTF-8

On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>
> That's interesting Nicol, but what about the other cases? For structured
> binding itself
> for example, how would I let bindings unnamed?
>

Remember the goal: you want an *object* to be unnamed, because you want to
use its construction and destruction only. The variables created by
structured binding are not objects; they're *references*. Their destructors
are irrelevant, so making them unnamed is equally irrelevant to this
particular goal.

Don't try to solve every problem at once.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f76598d9-0d2a-49ba-bfad-72cf0ac41341%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lo=
pes 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">Tha=
t&#39;s interesting Nicol, but what about the other cases? For structured b=
inding itself<br>for example, how would I let bindings unnamed?</div></bloc=
kquote><div><br>Remember the goal: you want an <i>object</i> to be unnamed,=
 because you want to use its construction and destruction only. The variabl=
es created by structured binding are not objects; they&#39;re <i>references=
</i>. Their destructors are irrelevant, so making them unnamed is equally i=
rrelevant to this particular goal.<br><br>Don&#39;t try to solve every prob=
lem at once.</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f76598d9-0d2a-49ba-bfad-72cf0ac41341%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f76598d9-0d2a-49ba-bfad-72cf0ac41341=
%40isocpp.org</a>.<br />

------=_Part_1199_1373295689.1468199475975--

------=_Part_1198_1931073672.1468199475975--

.

------=_Part_505_1885555734.1468201991270
Content-Type: multipart/alternative;
 boundary="----=_Part_506_1853718673.1468201991270"

------=_Part_506_1853718673.1468201991270
Content-Type: text/plain; charset=UTF-8


Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>
> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>
>> That's interesting Nicol, but what about the other cases? For structured
>> binding itself
>> for example, how would I let bindings unnamed?
>>
>
> Remember the goal: you want an *object* to be unnamed, because you want
> to use its construction and destruction only. The variables created by
> structured binding are not objects; they're *references*. Their
> destructors are irrelevant, so making them unnamed is equally irrelevant to
> this particular goal.
>

That may look like the *original* goal in the previous thread, but to tell
the truth it's not my goal. The rationale
here is for unnamed variables. It's just about to cover the intention of
not providing names for things
that doesn't need them, as frequently happen (and will happen) in the cases
presented.


> Don't try to solve every problem at once.
>

Why not? It's a simple solution that covers the relevant problem: having a
placeholder. It ends up
solving all in an understandable manner, in a uniform way. I ask why solve
it in a case by case form?
or solving one special case while leaving the others for the future or
plain unsolved, when in truth,
they all refer to the same core subject.


--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a8d25d8b-1c4e-47d8-9424-59adc0f9d144%40isocpp.org.

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

<div dir=3D"ltr"><br>Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol =
Bolas  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">That&#39;s interesting=
 Nicol, but what about the other cases? For structured binding itself<br>fo=
r example, how would I let bindings unnamed?</div></blockquote><div><br>Rem=
ember the goal: you want an <i>object</i> to be unnamed, because you want t=
o use its construction and destruction only. The variables created by struc=
tured binding are not objects; they&#39;re <i>references</i>. Their destruc=
tors are irrelevant, so making them unnamed is equally irrelevant to this p=
articular goal.<br></div></div></blockquote><div>=C2=A0<br>That may look li=
ke the <i>original</i> goal in the previous thread, but to tell the truth i=
t&#39;s not my goal. The rationale<br>here is for unnamed variables. It&#39=
;s just about to cover the intention of not providing names for things<br>t=
hat doesn&#39;t need them, as frequently happen (and will happen) in the ca=
ses presented.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div><br>Don&#39;t try to solve every problem at once.</div>=
</div></blockquote><div>=C2=A0<br>Why not? It&#39;s a simple solution that =
covers the relevant problem: having a placeholder. It ends up<br>solving al=
l in an understandable manner, in a uniform way. I ask why solve it in a ca=
se by case form?<br>or solving one special case while leaving the others fo=
r the future or plain unsolved, when in truth,<br>they all refer to the sam=
e core subject.<br><br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a8d25d8b-1c4e-47d8-9424-59adc0f9d144%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a8d25d8b-1c4e-47d8-9424-59adc0f9d144=
%40isocpp.org</a>.<br />

------=_Part_506_1853718673.1468201991270--

------=_Part_505_1885555734.1468201991270--

.

------=_Part_11808_234676014.1468202918810
Content-Type: multipart/alternative;
 boundary="----=_Part_11809_288669913.1468202918810"

------=_Part_11809_288669913.1468202918810
Content-Type: text/plain; charset=UTF-8

Besides _ or __ I'm thinking of other possibilities...

 @: I know of its presence solely in mangled names but I suspect it won't
be an issue.

I dunno, maybe the range of special characters may be of some use here too.

Em domingo, 10 de julho de 2016 22:53:11 UTC-3, Francisco Lopes escreveu:
>
>
> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>
>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>
>>> That's interesting Nicol, but what about the other cases? For structured
>>> binding itself
>>> for example, how would I let bindings unnamed?
>>>
>>
>> Remember the goal: you want an *object* to be unnamed, because you want
>> to use its construction and destruction only. The variables created by
>> structured binding are not objects; they're *references*. Their
>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>> this particular goal.
>>
>
> That may look like the *original* goal in the previous thread, but to
> tell the truth it's not my goal. The rationale
> here is for unnamed variables. It's just about to cover the intention of
> not providing names for things
> that doesn't need them, as frequently happen (and will happen) in the
> cases presented.
>
>
>> Don't try to solve every problem at once.
>>
>
> Why not? It's a simple solution that covers the relevant problem: having a
> placeholder. It ends up
> solving all in an understandable manner, in a uniform way. I ask why solve
> it in a case by case form?
> or solving one special case while leaving the others for the future or
> plain unsolved, when in truth,
> they all refer to the same core subject.
>
>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40ab52c1-1efe-429b-bbd3-22cedbe9958f%40isocpp.org.

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

<div dir=3D"ltr">Besides _ or __ I&#39;m thinking of other possibilities...=
<br><br>=C2=A0@: I know of its presence solely in mangled names but I suspe=
ct it won&#39;t be an issue.<br><br>I dunno, maybe the range of special cha=
racters may be of some use here too.<br><br>Em domingo, 10 de julho de 2016=
 22:53:11 UTC-3, Francisco Lopes  escreveu:<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>Em domingo, 10 de julho de 2016 22:11:16 =
UTC-3, Nicol Bolas  escreveu:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">That&#39;s int=
eresting Nicol, but what about the other cases? For structured binding itse=
lf<br>for example, how would I let bindings unnamed?</div></blockquote><div=
><br>Remember the goal: you want an <i>object</i> to be unnamed, because yo=
u want to use its construction and destruction only. The variables created =
by structured binding are not objects; they&#39;re <i>references</i>. Their=
 destructors are irrelevant, so making them unnamed is equally irrelevant t=
o this particular goal.<br></div></div></blockquote><div>=C2=A0<br>That may=
 look like the <i>original</i> goal in the previous thread, but to tell the=
 truth it&#39;s not my goal. The rationale<br>here is for unnamed variables=
.. It&#39;s just about to cover the intention of not providing names for thi=
ngs<br>that doesn&#39;t need them, as frequently happen (and will happen) i=
n the cases presented.<br><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"><div><br>Don&#39;t try to solve every problem at once.</d=
iv></div></blockquote><div>=C2=A0<br>Why not? It&#39;s a simple solution th=
at covers the relevant problem: having a placeholder. It ends up<br>solving=
 all in an understandable manner, in a uniform way. I ask why solve it in a=
 case by case form?<br>or solving one special case while leaving the others=
 for the future or plain unsolved, when in truth,<br>they all refer to the =
same core subject.<br><br><br></div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/40ab52c1-1efe-429b-bbd3-22cedbe9958f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40ab52c1-1efe-429b-bbd3-22cedbe9958f=
%40isocpp.org</a>.<br />

------=_Part_11809_288669913.1468202918810--

------=_Part_11808_234676014.1468202918810--

.

------=_Part_7305_2042998831.1468203151777
Content-Type: multipart/alternative;
 boundary="----=_Part_7306_828646430.1468203151778"

------=_Part_7306_828646430.1468203151778
Content-Type: text/plain; charset=UTF-8



Em domingo, 10 de julho de 2016 23:08:39 UTC-3, Francisco Lopes escreveu:
>
> Besides _ or __ I'm thinking of other possibilities...
>
>  @: I know of its presence solely in mangled names but I suspect it won't
> be an issue.
>
> I dunno, maybe the range of special characters may be of some use here too.
>

If adopting such alternative characters, it would be placeholder only,
without referentiability.


> Em domingo, 10 de julho de 2016 22:53:11 UTC-3, Francisco Lopes escreveu:
>>
>>
>> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>>
>>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>>
>>>> That's interesting Nicol, but what about the other cases? For
>>>> structured binding itself
>>>> for example, how would I let bindings unnamed?
>>>>
>>>
>>> Remember the goal: you want an *object* to be unnamed, because you want
>>> to use its construction and destruction only. The variables created by
>>> structured binding are not objects; they're *references*. Their
>>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>>> this particular goal.
>>>
>>
>> That may look like the *original* goal in the previous thread, but to
>> tell the truth it's not my goal. The rationale
>> here is for unnamed variables. It's just about to cover the intention of
>> not providing names for things
>> that doesn't need them, as frequently happen (and will happen) in the
>> cases presented.
>>
>>
>>> Don't try to solve every problem at once.
>>>
>>
>> Why not? It's a simple solution that covers the relevant problem: having
>> a placeholder. It ends up
>> solving all in an understandable manner, in a uniform way. I ask why
>> solve it in a case by case form?
>> or solving one special case while leaving the others for the future or
>> plain unsolved, when in truth,
>> they all refer to the same core subject.
>>
>>
>>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/041f9b81-d912-4fd1-8574-78a8f22ea4f3%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Em domingo, 10 de julho de 2016 23:08:39 UTC-3, Fr=
ancisco Lopes  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">Besides _ or __ I&#39;m thinking of other possibilities...<br><b=
r>=C2=A0@: I know of its presence solely in mangled names but I suspect it =
won&#39;t be an issue.<br><br>I dunno, maybe the range of special character=
s may be of some use here too.<br></div></blockquote><div><br>If adopting s=
uch alternative characters, it would be placeholder only, without referenti=
ability.<br><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"><br>Em domingo, 10 de julho de 2016 22:53:11 UTC-3, Francisco Lope=
s  escreveu:<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>Em=
 domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas  escreveu:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, July 10, 2016 =
at 7:59:33 PM UTC-4, Francisco Lopes wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">That&#39;s interesting Nicol, but what about the o=
ther cases? For structured binding itself<br>for example, how would I let b=
indings unnamed?</div></blockquote><div><br>Remember the goal: you want an =
<i>object</i> to be unnamed, because you want to use its construction and d=
estruction only. The variables created by structured binding are not object=
s; they&#39;re <i>references</i>. Their destructors are irrelevant, so maki=
ng them unnamed is equally irrelevant to this particular goal.<br></div></d=
iv></blockquote><div>=C2=A0<br>That may look like the <i>original</i> goal =
in the previous thread, but to tell the truth it&#39;s not my goal. The rat=
ionale<br>here is for unnamed variables. It&#39;s just about to cover the i=
ntention of not providing names for things<br>that doesn&#39;t need them, a=
s frequently happen (and will happen) in the cases presented.<br><br></div>=
<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"><div><br>Don&#39;t=
 try to solve every problem at once.</div></div></blockquote><div>=C2=A0<br=
>Why not? It&#39;s a simple solution that covers the relevant problem: havi=
ng a placeholder. It ends up<br>solving all in an understandable manner, in=
 a uniform way. I ask why solve it in a case by case form?<br>or solving on=
e special case while leaving the others for the future or plain unsolved, w=
hen in truth,<br>they all refer to the same core subject.<br><br><br></div>=
</div></blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/041f9b81-d912-4fd1-8574-78a8f22ea4f3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/041f9b81-d912-4fd1-8574-78a8f22ea4f3=
%40isocpp.org</a>.<br />

------=_Part_7306_828646430.1468203151778--

------=_Part_7305_2042998831.1468203151777--

.

------=_Part_489_800880904.1468203780802
Content-Type: multipart/alternative;
 boundary="----=_Part_490_193548834.1468203780802"

------=_Part_490_193548834.1468203780802
Content-Type: text/plain; charset=UTF-8



Em domingo, 10 de julho de 2016 23:12:32 UTC-3, Francisco Lopes escreveu:
>
>
>
> Em domingo, 10 de julho de 2016 23:08:39 UTC-3, Francisco Lopes escreveu:
>>
>> Besides _ or __ I'm thinking of other possibilities...
>>
>>  @: I know of its presence solely in mangled names but I suspect it won't
>> be an issue.
>>
>> I dunno, maybe the range of special characters may be of some use here
>> too.
>>
>
> If adopting such alternative characters, it would be placeholder only,
> without referentiability.
>

My preferred choices are _, @ or ?


>> Em domingo, 10 de julho de 2016 22:53:11 UTC-3, Francisco Lopes escreveu:
>>>
>>>
>>> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>>>
>>>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>>>
>>>>> That's interesting Nicol, but what about the other cases? For
>>>>> structured binding itself
>>>>> for example, how would I let bindings unnamed?
>>>>>
>>>>
>>>> Remember the goal: you want an *object* to be unnamed, because you
>>>> want to use its construction and destruction only. The variables created by
>>>> structured binding are not objects; they're *references*. Their
>>>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>>>> this particular goal.
>>>>
>>>
>>> That may look like the *original* goal in the previous thread, but to
>>> tell the truth it's not my goal. The rationale
>>> here is for unnamed variables. It's just about to cover the intention of
>>> not providing names for things
>>> that doesn't need them, as frequently happen (and will happen) in the
>>> cases presented.
>>>
>>>
>>>> Don't try to solve every problem at once.
>>>>
>>>
>>> Why not? It's a simple solution that covers the relevant problem: having
>>> a placeholder. It ends up
>>> solving all in an understandable manner, in a uniform way. I ask why
>>> solve it in a case by case form?
>>> or solving one special case while leaving the others for the future or
>>> plain unsolved, when in truth,
>>> they all refer to the same core subject.
>>>
>>>
>>>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69941075-9183-403b-86ac-3e37b7ddfae1%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Em domingo, 10 de julho de 2016 23:12:32 UTC-3, Fr=
ancisco Lopes  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><br><br>Em domingo, 10 de julho de 2016 23:08:39 UTC-3, Francisc=
o Lopes  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
Besides _ or __ I&#39;m thinking of other possibilities...<br><br>=C2=A0@: =
I know of its presence solely in mangled names but I suspect it won&#39;t b=
e an issue.<br><br>I dunno, maybe the range of special characters may be of=
 some use here too.<br></div></blockquote><div><br>If adopting such alterna=
tive characters, it would be placeholder only, without referentiability.<br=
></div></div></blockquote><div><br>My preferred choices are _, @ or ? <br><=
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>Em domingo, 10 de =
julho de 2016 22:53:11 UTC-3, Francisco Lopes  escreveu:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><br>Em domingo, 10 de julho de 2016=
 22:11:16 UTC-3, Nicol Bolas  escreveu:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisc=
o Lopes 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">That=
&#39;s interesting Nicol, but what about the other cases? For structured bi=
nding itself<br>for example, how would I let bindings unnamed?</div></block=
quote><div><br>Remember the goal: you want an <i>object</i> to be unnamed, =
because you want to use its construction and destruction only. The variable=
s created by structured binding are not objects; they&#39;re <i>references<=
/i>. Their destructors are irrelevant, so making them unnamed is equally ir=
relevant to this particular goal.<br></div></div></blockquote><div>=C2=A0<b=
r>That may look like the <i>original</i> goal in the previous thread, but t=
o tell the truth it&#39;s not my goal. The rationale<br>here is for unnamed=
 variables. It&#39;s just about to cover the intention of not providing nam=
es for things<br>that doesn&#39;t need them, as frequently happen (and will=
 happen) in the cases presented.<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div><br>Don&#39;t try to solve every problem a=
t once.</div></div></blockquote><div>=C2=A0<br>Why not? It&#39;s a simple s=
olution that covers the relevant problem: having a placeholder. It ends up<=
br>solving all in an understandable manner, in a uniform way. I ask why sol=
ve it in a case by case form?<br>or solving one special case while leaving =
the others for the future or plain unsolved, when in truth,<br>they all ref=
er to the same core subject.<br><br><br></div></div></blockquote></div></bl=
ockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/69941075-9183-403b-86ac-3e37b7ddfae1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/69941075-9183-403b-86ac-3e37b7ddfae1=
%40isocpp.org</a>.<br />

------=_Part_490_193548834.1468203780802--

------=_Part_489_800880904.1468203780802--

.

------=_Part_164_592135948.1468208834277
Content-Type: multipart/alternative;
 boundary="----=_Part_165_1647719339.1468208834277"

------=_Part_165_1647719339.1468208834277
Content-Type: text/plain; charset=UTF-8

On Sunday, July 10, 2016 at 9:53:11 PM UTC-4, Francisco Lopes wrote:
>
>
> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>
>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>
>>> That's interesting Nicol, but what about the other cases? For structured
>>> binding itself
>>> for example, how would I let bindings unnamed?
>>>
>>
>> Remember the goal: you want an *object* to be unnamed, because you want
>> to use its construction and destruction only. The variables created by
>> structured binding are not objects; they're *references*. Their
>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>> this particular goal.
>>
>
> That may look like the *original* goal in the previous thread, but to
> tell the truth it's not my goal. The rationale
> here is for unnamed variables. It's just about to cover the intention of
> not providing names for things
> that doesn't need them, as frequently happen (and will happen) in the
> cases presented.
>
> Don't try to solve every problem at once.
>>
>
> Why not? It's a simple solution that covers the relevant problem: having a
> placeholder. It ends up
> solving all in an understandable manner, in a uniform way.
>

But it is not a "simple solution". Indeed, I would go so far as to say that
any placeholder which is currently a valid identifier is not a solution at
all.

Breaking people's perfectly valid code should not be considered a solution
to a problem. Not without *really good* reason. And let's face facts:
unnamed variables are not *that* important.

Also, last time we tried to get something "uniform", we got Uniform
Initialization. Which very much is not.

I ask why solve it in a case by case form?
>

Because it works. Not only does it work, it makes sense. That's one of the
nice things about `auto[]`: based solely on the rules of structured
binding, it does exactly what you want.

Indeed, as I think about it, if we ever wanted structured binding to be
able to not capture all of the elements, we wouldn't *want* it to use
placeholders. We would probably want `auto [x]` to bind to the first value
of any tuple-like type. If that type has 30 variables in it, I don't care;
I just want the first one. I shouldn't have to do `auto [x, @, @, @]` or
even `auto [x, ...]` or whatever. I said that I wanted the first member, so
give it to me.

Given that, `auto []` would bind to none of the values. Therefore, it would
either be a compile error or it would work on anything, providing a hidden
object that would be destroyed at the end of scope.

So really, I don't see this as a "case-by-case form". It's really the right
way to go for *both* problems ;)

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0259895d-025e-43b4-9b8e-6052f8ee4874%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 10, 2016 at 9:53:11 PM UTC-4, Francisco Lo=
pes 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=
>Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas  escreveu:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, July 10, 20=
16 at 7:59:33 PM UTC-4, Francisco Lopes wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">That&#39;s interesting Nicol, but what about th=
e other cases? For structured binding itself<br>for example, how would I le=
t bindings unnamed?</div></blockquote><div><br>Remember the goal: you want =
an <i>object</i> to be unnamed, because you want to use its construction an=
d destruction only. The variables created by structured binding are not obj=
ects; they&#39;re <i>references</i>. Their destructors are irrelevant, so m=
aking them unnamed is equally irrelevant to this particular goal.<br></div>=
</div></blockquote><div>=C2=A0<br>That may look like the <i>original</i> go=
al in the previous thread, but to tell the truth it&#39;s not my goal. The =
rationale<br>here is for unnamed variables. It&#39;s just about to cover th=
e intention of not providing names for things<br>that doesn&#39;t need them=
, as frequently happen (and will happen) in the cases presented.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Don&#39;t =
try to solve every problem at once.</div></div></blockquote><div>=C2=A0<br>=
Why not? It&#39;s a simple solution that covers the relevant problem: havin=
g a placeholder. It ends up<br>solving all in an understandable manner, in =
a uniform way.</div></div></blockquote><div><br>But it is not a &quot;simpl=
e solution&quot;. Indeed, I would go so far as to say that any placeholder =
which is currently a valid identifier is not a solution at all.<br><br>Brea=
king people&#39;s perfectly valid code should not be considered a solution =
to a problem. Not without <i>really good</i> reason. And let&#39;s face fac=
ts: unnamed variables are not <i>that</i> important.<br><br>Also, last time=
 we tried to get something &quot;uniform&quot;, we got Uniform Initializati=
on. Which very much is not.<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div>I ask why solve it in a case by case form?=
<br></div></div></blockquote><div><br>Because it works. Not only does it wo=
rk, it makes sense. That&#39;s one of the nice things about `auto[]`: based=
 solely on the rules of structured binding, it does exactly what you want.<=
br><br>Indeed, as I think about it, if we ever wanted structured binding to=
 be able to not capture all of the elements, we wouldn&#39;t <i>want</i> it=
 to use placeholders. We would probably want `auto [x]` to bind to the firs=
t value of any tuple-like type. If that type has 30 variables in it, I don&=
#39;t care; I just want the first one. I shouldn&#39;t have to do `auto [x,=
 @, @, @]` or even `auto [x, ...]` or whatever. I said that I wanted the fi=
rst member, so give it to me.<br><br>Given that, `auto []` would bind to no=
ne of the values. Therefore, it would either be a compile error or it would=
 work on anything, providing a hidden object that would be destroyed at the=
 end of scope.<br><br>So really, I don&#39;t see this as a &quot;case-by-ca=
se form&quot;. It&#39;s really the right way to go for <i>both</i> problems=
 ;)<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0259895d-025e-43b4-9b8e-6052f8ee4874%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0259895d-025e-43b4-9b8e-6052f8ee4874=
%40isocpp.org</a>.<br />

------=_Part_165_1647719339.1468208834277--

------=_Part_164_592135948.1468208834277--

.

------=_Part_7435_595754441.1468210381686
Content-Type: multipart/alternative;
 boundary="----=_Part_7436_2141400849.1468210381686"

------=_Part_7436_2141400849.1468210381686
Content-Type: text/plain; charset=UTF-8



Em segunda-feira, 11 de julho de 2016 00:47:14 UTC-3, Nicol Bolas escreveu:
>
> On Sunday, July 10, 2016 at 9:53:11 PM UTC-4, Francisco Lopes wrote:
>>
>>
>> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>>
>>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>>
>>>> That's interesting Nicol, but what about the other cases? For
>>>> structured binding itself
>>>> for example, how would I let bindings unnamed?
>>>>
>>>
>>> Remember the goal: you want an *object* to be unnamed, because you want
>>> to use its construction and destruction only. The variables created by
>>> structured binding are not objects; they're *references*. Their
>>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>>> this particular goal.
>>>
>>
>> That may look like the *original* goal in the previous thread, but to
>> tell the truth it's not my goal. The rationale
>> here is for unnamed variables. It's just about to cover the intention of
>> not providing names for things
>> that doesn't need them, as frequently happen (and will happen) in the
>> cases presented.
>>
>> Don't try to solve every problem at once.
>>>
>>
>> Why not? It's a simple solution that covers the relevant problem: having
>> a placeholder. It ends up
>> solving all in an understandable manner, in a uniform way.
>>
>
> But it is not a "simple solution". Indeed, I would go so far as to say
> that any placeholder which is currently a valid identifier is not a
> solution at all.
>

Restating that it's not just about reusing already valid identifiers.


>
> Breaking people's perfectly valid code should not be considered a solution
> to a problem. Not without *really good* reason. And let's face facts:
> unnamed variables are not *that* important.
>

I've asked before about a sample where the proposals I've endorsed would
break people's code, do you have one (seriously)?

For the case where _ can be overridden, there's no codebase that can
compile with variables of equal name are declared, same
applies for the solution where _ can't be referenced if declared more than
once in the same scope.


>
> Also, last time we tried to get something "uniform", we got Uniform
> Initialization. Which very much is not.
>
> I ask why solve it in a case by case form?
>>
>
> Because it works. Not only does it work, it makes sense. That's one of the
> nice things about `auto[]`: based solely on the rules of structured
> binding, it does exactly what you want.
>
> Indeed, as I think about it, if we ever wanted structured binding to be
> able to not capture all of the elements, we wouldn't *want* it to use
> placeholders. We would probably want `auto [x]` to bind to the first value
> of any tuple-like type. If that type has 30 variables in it, I don't care;
> I just want the first one. I shouldn't have to do `auto [x, @, @, @]` or
> even `auto [x, ...]` or whatever. I said that I wanted the first member, so
> give it to me.
>
> Given that, `auto []` would bind to none of the values. Therefore, it
> would either be a compile error or it would work on anything, providing a
> hidden object that would be destroyed at the end of scope.
>

You may like that, I don't. You are focusing on a special solution for the
sake of bad practice on multiple return. I'm looking for this solved:

auto [x, _, y] = foo()
auto [_, y, _] = bar()
auto [x, _] = baz()

Etc, which your solution where order matters, doesn't cover (besides not
covering the other case).
The time I get a tuple of 30 as a return, I'd be looking for a refactor not
support of the language for
pattern handling of that.


>
> So really, I don't see this as a "case-by-case form". It's really the
> right way to go for *both* problems ;)
>
>
Which both? You mean the correct way is to patch the language around the
same subject, but with
particular solutions?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8688bfe4-dbb2-47c2-b135-7be266ce385c%40isocpp.org.

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

<div dir=3D"ltr"><br><br>Em segunda-feira, 11 de julho de 2016 00:47:14 UTC=
-3, Nicol Bolas  escreveu:<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">On Sunday, July 10, 2016 at 9:53:11 PM UTC-4, Francisco Lopes =
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>Em domin=
go, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas  escreveu:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, July 10, 2016 at 7:5=
9:33 PM UTC-4, Francisco Lopes wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">That&#39;s interesting Nicol, but what about the other c=
ases? For structured binding itself<br>for example, how would I let binding=
s unnamed?</div></blockquote><div><br>Remember the goal: you want an <i>obj=
ect</i> to be unnamed, because you want to use its construction and destruc=
tion only. The variables created by structured binding are not objects; the=
y&#39;re <i>references</i>. Their destructors are irrelevant, so making the=
m unnamed is equally irrelevant to this particular goal.<br></div></div></b=
lockquote><div>=C2=A0<br>That may look like the <i>original</i> goal in the=
 previous thread, but to tell the truth it&#39;s not my goal. The rationale=
<br>here is for unnamed variables. It&#39;s just about to cover the intenti=
on of not providing names for things<br>that doesn&#39;t need them, as freq=
uently happen (and will happen) in the cases presented.<br><br></div><block=
quote 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>Don&#39;t try to so=
lve every problem at once.</div></div></blockquote><div>=C2=A0<br>Why not? =
It&#39;s a simple solution that covers the relevant problem: having a place=
holder. It ends up<br>solving all in an understandable manner, in a uniform=
 way.</div></div></blockquote><div><br>But it is not a &quot;simple solutio=
n&quot;. Indeed, I would go so far as to say that any placeholder which is =
currently a valid identifier is not a solution at all.<br></div></div></blo=
ckquote><div><br>Restating that it&#39;s not just about reusing already val=
id identifiers.=C2=A0 <br></div><div>=C2=A0</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"><div><br>Breaking people&#39;s perfectl=
y valid code should not be considered a solution to a problem. Not without =
<i>really good</i> reason. And let&#39;s face facts: unnamed variables are =
not <i>that</i> important.<br></div></div></blockquote><div><br>I&#39;ve as=
ked before about a sample where the proposals I&#39;ve endorsed would break=
 people&#39;s code, do you have one (seriously)?<br><br>For the case where =
_ can be overridden, there&#39;s no codebase that can compile with variable=
s of equal name are declared, same<br>applies for the solution where _ can&=
#39;t be referenced if declared more than once in the same scope.<br></div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>Also, last time we tried to get something &quot;uniform&quot;,=
 we got Uniform Initialization. Which very much is not.<br><br></div><block=
quote 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>I ask why solve it =
in a case by case form?<br></div></div></blockquote><div><br>Because it wor=
ks. Not only does it work, it makes sense. That&#39;s one of the nice thing=
s about `auto[]`: based solely on the rules of structured binding, it does =
exactly what you want.<br><br>Indeed, as I think about it, if we ever wante=
d structured binding to be able to not capture all of the elements, we woul=
dn&#39;t <i>want</i> it to use placeholders. We would probably want `auto [=
x]` to bind to the first value of any tuple-like type. If that type has 30 =
variables in it, I don&#39;t care; I just want the first one. I shouldn&#39=
;t have to do `auto [x, @, @, @]` or even `auto [x, ...]` or whatever. I sa=
id that I wanted the first member, so give it to me.<br><br>Given that, `au=
to []` would bind to none of the values. Therefore, it would either be a co=
mpile error or it would work on anything, providing a hidden object that wo=
uld be destroyed at the end of scope.<br></div></div></blockquote><div><br>=
You may like that, I don&#39;t. You are focusing on a special solution for =
the<br>sake of bad practice on multiple return. I&#39;m looking for this so=
lved:<br><br> auto [x, _, y] =3D foo()<br>auto [_, y, _] =3D bar()<br>auto =
[x, _] =3D baz()<br><br>Etc, which your solution where order matters, doesn=
&#39;t cover (besides not covering the other case).<br>The time I get a tup=
le of 30 as a return, I&#39;d be looking for a refactor not support of the =
language for<br>pattern handling of that.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>So really, I don&#39;=
t see this as a &quot;case-by-case form&quot;. It&#39;s really the right wa=
y to go for <i>both</i> problems ;)<br><br></div></div></blockquote><div><b=
r>Which both? You mean the correct way is to patch the language around the =
same subject, but with<br>particular solutions? <br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8688bfe4-dbb2-47c2-b135-7be266ce385c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8688bfe4-dbb2-47c2-b135-7be266ce385c=
%40isocpp.org</a>.<br />

------=_Part_7436_2141400849.1468210381686--

------=_Part_7435_595754441.1468210381686--

.

------=_Part_2865_1565022154.1468211591093
Content-Type: multipart/alternative;
 boundary="----=_Part_2866_743844986.1468211591093"

------=_Part_2866_743844986.1468211591093
Content-Type: text/plain; charset=UTF-8

About "which both", nevermind. I got what you suggests covers both guards,
scope_exit
and structure binding, although for the last it doesn't look much useful as
a solution.

Em segunda-feira, 11 de julho de 2016 01:13:02 UTC-3, Francisco Lopes
escreveu:
>
>
>
> Em segunda-feira, 11 de julho de 2016 00:47:14 UTC-3, Nicol Bolas escreveu:
>>
>> On Sunday, July 10, 2016 at 9:53:11 PM UTC-4, Francisco Lopes wrote:
>>>
>>>
>>> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>>>
>>>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>>>
>>>>> That's interesting Nicol, but what about the other cases? For
>>>>> structured binding itself
>>>>> for example, how would I let bindings unnamed?
>>>>>
>>>>
>>>> Remember the goal: you want an *object* to be unnamed, because you
>>>> want to use its construction and destruction only. The variables created by
>>>> structured binding are not objects; they're *references*. Their
>>>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>>>> this particular goal.
>>>>
>>>
>>> That may look like the *original* goal in the previous thread, but to
>>> tell the truth it's not my goal. The rationale
>>> here is for unnamed variables. It's just about to cover the intention of
>>> not providing names for things
>>> that doesn't need them, as frequently happen (and will happen) in the
>>> cases presented.
>>>
>>> Don't try to solve every problem at once.
>>>>
>>>
>>> Why not? It's a simple solution that covers the relevant problem: having
>>> a placeholder. It ends up
>>> solving all in an understandable manner, in a uniform way.
>>>
>>
>> But it is not a "simple solution". Indeed, I would go so far as to say
>> that any placeholder which is currently a valid identifier is not a
>> solution at all.
>>
>
> Restating that it's not just about reusing already valid identifiers.
>
>
>>
>> Breaking people's perfectly valid code should not be considered a
>> solution to a problem. Not without *really good* reason. And let's face
>> facts: unnamed variables are not *that* important.
>>
>
> I've asked before about a sample where the proposals I've endorsed would
> break people's code, do you have one (seriously)?
>
> For the case where _ can be overridden, there's no codebase that can
> compile with variables of equal name are declared, same
> applies for the solution where _ can't be referenced if declared more than
> once in the same scope.
>
>
>>
>> Also, last time we tried to get something "uniform", we got Uniform
>> Initialization. Which very much is not.
>>
>> I ask why solve it in a case by case form?
>>>
>>
>> Because it works. Not only does it work, it makes sense. That's one of
>> the nice things about `auto[]`: based solely on the rules of structured
>> binding, it does exactly what you want.
>>
>> Indeed, as I think about it, if we ever wanted structured binding to be
>> able to not capture all of the elements, we wouldn't *want* it to use
>> placeholders. We would probably want `auto [x]` to bind to the first value
>> of any tuple-like type. If that type has 30 variables in it, I don't care;
>> I just want the first one. I shouldn't have to do `auto [x, @, @, @]` or
>> even `auto [x, ...]` or whatever. I said that I wanted the first member, so
>> give it to me.
>>
>> Given that, `auto []` would bind to none of the values. Therefore, it
>> would either be a compile error or it would work on anything, providing a
>> hidden object that would be destroyed at the end of scope.
>>
>
> You may like that, I don't. You are focusing on a special solution for the
> sake of bad practice on multiple return. I'm looking for this solved:
>
> auto [x, _, y] = foo()
> auto [_, y, _] = bar()
> auto [x, _] = baz()
>
> Etc, which your solution where order matters, doesn't cover (besides not
> covering the other case).
> The time I get a tuple of 30 as a return, I'd be looking for a refactor
> not support of the language for
> pattern handling of that.
>
>
>>
>> So really, I don't see this as a "case-by-case form". It's really the
>> right way to go for *both* problems ;)
>>
>>
> Which both? You mean the correct way is to patch the language around the
> same subject, but with
> particular solutions?
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/803fe56c-aa4f-4379-ad04-07ef756277d8%40isocpp.org.

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

<div dir=3D"ltr">About &quot;which both&quot;, nevermind. I got what you su=
ggests covers both guards, scope_exit<br>and structure binding, although fo=
r the last it doesn&#39;t look much useful as a solution.<br><br>Em segunda=
-feira, 11 de julho de 2016 01:13:02 UTC-3, Francisco Lopes  escreveu:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>Em segunda=
-feira, 11 de julho de 2016 00:47:14 UTC-3, Nicol Bolas  escreveu:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, July 10, 2016 at=
 9:53:11 PM UTC-4, Francisco Lopes 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>Em domingo, 10 de julho de 2016 22:11:16 UTC-3, =
Nicol Bolas  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">That&#39;s interestin=
g Nicol, but what about the other cases? For structured binding itself<br>f=
or example, how would I let bindings unnamed?</div></blockquote><div><br>Re=
member the goal: you want an <i>object</i> to be unnamed, because you want =
to use its construction and destruction only. The variables created by stru=
ctured binding are not objects; they&#39;re <i>references</i>. Their destru=
ctors are irrelevant, so making them unnamed is equally irrelevant to this =
particular goal.<br></div></div></blockquote><div>=C2=A0<br>That may look l=
ike the <i>original</i> goal in the previous thread, but to tell the truth =
it&#39;s not my goal. The rationale<br>here is for unnamed variables. It&#3=
9;s just about to cover the intention of not providing names for things<br>=
that doesn&#39;t need them, as frequently happen (and will happen) in the c=
ases presented.<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>Don&#39;t try to solve every problem at once.</div></div></=
blockquote><div>=C2=A0<br>Why not? It&#39;s a simple solution that covers t=
he relevant problem: having a placeholder. It ends up<br>solving all in an =
understandable manner, in a uniform way.</div></div></blockquote><div><br>B=
ut it is not a &quot;simple solution&quot;. Indeed, I would go so far as to=
 say that any placeholder which is currently a valid identifier is not a so=
lution at all.<br></div></div></blockquote><div><br>Restating that it&#39;s=
 not just about reusing already valid identifiers.=C2=A0 <br></div><div>=C2=
=A0</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"><div><br>=
Breaking people&#39;s perfectly valid code should not be considered a solut=
ion to a problem. Not without <i>really good</i> reason. And let&#39;s face=
 facts: unnamed variables are not <i>that</i> important.<br></div></div></b=
lockquote><div><br>I&#39;ve asked before about a sample where the proposals=
 I&#39;ve endorsed would break people&#39;s code, do you have one (seriousl=
y)?<br><br>For the case where _ can be overridden, there&#39;s no codebase =
that can compile with variables of equal name are declared, same<br>applies=
 for the solution where _ can&#39;t be referenced if declared more than onc=
e in the same scope.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div><br>Also, last time we tried to get somet=
hing &quot;uniform&quot;, we got Uniform Initialization. Which very much is=
 not.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>I ask why solve it in a case by case form?<br></div></div></blockquot=
e><div><br>Because it works. Not only does it work, it makes sense. That&#3=
9;s one of the nice things about `auto[]`: based solely on the rules of str=
uctured binding, it does exactly what you want.<br><br>Indeed, as I think a=
bout it, if we ever wanted structured binding to be able to not capture all=
 of the elements, we wouldn&#39;t <i>want</i> it to use placeholders. We wo=
uld probably want `auto [x]` to bind to the first value of any tuple-like t=
ype. If that type has 30 variables in it, I don&#39;t care; I just want the=
 first one. I shouldn&#39;t have to do `auto [x, @, @, @]` or even `auto [x=
, ...]` or whatever. I said that I wanted the first member, so give it to m=
e.<br><br>Given that, `auto []` would bind to none of the values. Therefore=
, it would either be a compile error or it would work on anything, providin=
g a hidden object that would be destroyed at the end of scope.<br></div></d=
iv></blockquote><div><br>You may like that, I don&#39;t. You are focusing o=
n a special solution for the<br>sake of bad practice on multiple return. I&=
#39;m looking for this solved:<br><br> auto [x, _, y] =3D foo()<br>auto [_,=
 y, _] =3D bar()<br>auto [x, _] =3D baz()<br><br>Etc, which your solution w=
here order matters, doesn&#39;t cover (besides not covering the other case)=
..<br>The time I get a tuple of 30 as a return, I&#39;d be looking for a ref=
actor not support of the language for<br>pattern handling of that.<br>=C2=
=A0</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"><div><br>=
So really, I don&#39;t see this as a &quot;case-by-case form&quot;. It&#39;=
s really the right way to go for <i>both</i> problems ;)<br><br></div></div=
></blockquote><div><br>Which both? You mean the correct way is to patch the=
 language around the same subject, but with<br>particular solutions? <br></=
div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/803fe56c-aa4f-4379-ad04-07ef756277d8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/803fe56c-aa4f-4379-ad04-07ef756277d8=
%40isocpp.org</a>.<br />

------=_Part_2866_743844986.1468211591093--

------=_Part_2865_1565022154.1468211591093--

.

------=_Part_0_283520619.1468212017085
Content-Type: multipart/alternative;
 boundary="----=_Part_1_556908580.1468212017096"

------=_Part_1_556908580.1468212017096
Content-Type: text/plain; charset=UTF-8

ah, correction, as far as I can see it doesn't work very well for normal
declarations
like with guards. Also, I have no idea whether structure binding should
support things
that I have no idea can be destructured or not. So it looks pretty much
trying to
sneak from recently added structure biding to other areas it's was not
thought for.

Em segunda-feira, 11 de julho de 2016 01:33:11 UTC-3, Francisco Lopes
escreveu:
>
> About "which both", nevermind. I got what you suggests covers both guards,
> scope_exit
> and structure binding, although for the last it doesn't look much useful
> as a solution.
>
> Em segunda-feira, 11 de julho de 2016 01:13:02 UTC-3, Francisco Lopes
> escreveu:
>>
>>
>>
>> Em segunda-feira, 11 de julho de 2016 00:47:14 UTC-3, Nicol Bolas
>> escreveu:
>>>
>>> On Sunday, July 10, 2016 at 9:53:11 PM UTC-4, Francisco Lopes wrote:
>>>>
>>>>
>>>> Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas escreveu:
>>>>>
>>>>> On Sunday, July 10, 2016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:
>>>>>>
>>>>>> That's interesting Nicol, but what about the other cases? For
>>>>>> structured binding itself
>>>>>> for example, how would I let bindings unnamed?
>>>>>>
>>>>>
>>>>> Remember the goal: you want an *object* to be unnamed, because you
>>>>> want to use its construction and destruction only. The variables created by
>>>>> structured binding are not objects; they're *references*. Their
>>>>> destructors are irrelevant, so making them unnamed is equally irrelevant to
>>>>> this particular goal.
>>>>>
>>>>
>>>> That may look like the *original* goal in the previous thread, but to
>>>> tell the truth it's not my goal. The rationale
>>>> here is for unnamed variables. It's just about to cover the intention
>>>> of not providing names for things
>>>> that doesn't need them, as frequently happen (and will happen) in the
>>>> cases presented.
>>>>
>>>> Don't try to solve every problem at once.
>>>>>
>>>>
>>>> Why not? It's a simple solution that covers the relevant problem:
>>>> having a placeholder. It ends up
>>>> solving all in an understandable manner, in a uniform way.
>>>>
>>>
>>> But it is not a "simple solution". Indeed, I would go so far as to say
>>> that any placeholder which is currently a valid identifier is not a
>>> solution at all.
>>>
>>
>> Restating that it's not just about reusing already valid identifiers.
>>
>>
>>>
>>> Breaking people's perfectly valid code should not be considered a
>>> solution to a problem. Not without *really good* reason. And let's face
>>> facts: unnamed variables are not *that* important.
>>>
>>
>> I've asked before about a sample where the proposals I've endorsed would
>> break people's code, do you have one (seriously)?
>>
>> For the case where _ can be overridden, there's no codebase that can
>> compile with variables of equal name are declared, same
>> applies for the solution where _ can't be referenced if declared more
>> than once in the same scope.
>>
>>
>>>
>>> Also, last time we tried to get something "uniform", we got Uniform
>>> Initialization. Which very much is not.
>>>
>>> I ask why solve it in a case by case form?
>>>>
>>>
>>> Because it works. Not only does it work, it makes sense. That's one of
>>> the nice things about `auto[]`: based solely on the rules of structured
>>> binding, it does exactly what you want.
>>>
>>> Indeed, as I think about it, if we ever wanted structured binding to be
>>> able to not capture all of the elements, we wouldn't *want* it to use
>>> placeholders. We would probably want `auto [x]` to bind to the first value
>>> of any tuple-like type. If that type has 30 variables in it, I don't care;
>>> I just want the first one. I shouldn't have to do `auto [x, @, @, @]` or
>>> even `auto [x, ...]` or whatever. I said that I wanted the first member, so
>>> give it to me.
>>>
>>> Given that, `auto []` would bind to none of the values. Therefore, it
>>> would either be a compile error or it would work on anything, providing a
>>> hidden object that would be destroyed at the end of scope.
>>>
>>
>> You may like that, I don't. You are focusing on a special solution for the
>> sake of bad practice on multiple return. I'm looking for this solved:
>>
>> auto [x, _, y] = foo()
>> auto [_, y, _] = bar()
>> auto [x, _] = baz()
>>
>> Etc, which your solution where order matters, doesn't cover (besides not
>> covering the other case).
>> The time I get a tuple of 30 as a return, I'd be looking for a refactor
>> not support of the language for
>> pattern handling of that.
>>
>>
>>>
>>> So really, I don't see this as a "case-by-case form". It's really the
>>> right way to go for *both* problems ;)
>>>
>>>
>> Which both? You mean the correct way is to patch the language around the
>> same subject, but with
>> particular solutions?
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cce6aa50-ad77-4567-9645-65ea0b979dc5%40isocpp.org.

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

<div dir=3D"ltr">ah, correction, as far as I can see it doesn&#39;t work ve=
ry well for normal declarations<br>like with guards. Also, I have no idea w=
hether structure binding should support things<br>that I have no idea can b=
e destructured or not. So it looks pretty much trying to<br>sneak from rece=
ntly added structure biding to other areas it&#39;s was not thought for.<br=
><br>Em segunda-feira, 11 de julho de 2016 01:33:11 UTC-3, Francisco Lopes =
 escreveu:<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">Abo=
ut &quot;which both&quot;, nevermind. I got what you suggests covers both g=
uards, scope_exit<br>and structure binding, although for the last it doesn&=
#39;t look much useful as a solution.<br><br>Em segunda-feira, 11 de julho =
de 2016 01:13:02 UTC-3, Francisco Lopes  escreveu:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><br><br>Em segunda-feira, 11 de julho de 20=
16 00:47:14 UTC-3, Nicol Bolas  escreveu:<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">On Sunday, July 10, 2016 at 9:53:11 PM UTC-4, Franci=
sco Lopes 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"><b=
r>Em domingo, 10 de julho de 2016 22:11:16 UTC-3, Nicol Bolas  escreveu:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, July 10, 2=
016 at 7:59:33 PM UTC-4, Francisco Lopes wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">That&#39;s interesting Nicol, but what about t=
he other cases? For structured binding itself<br>for example, how would I l=
et bindings unnamed?</div></blockquote><div><br>Remember the goal: you want=
 an <i>object</i> to be unnamed, because you want to use its construction a=
nd destruction only. The variables created by structured binding are not ob=
jects; they&#39;re <i>references</i>. Their destructors are irrelevant, so =
making them unnamed is equally irrelevant to this particular goal.<br></div=
></div></blockquote><div>=C2=A0<br>That may look like the <i>original</i> g=
oal in the previous thread, but to tell the truth it&#39;s not my goal. The=
 rationale<br>here is for unnamed variables. It&#39;s just about to cover t=
he intention of not providing names for things<br>that doesn&#39;t need the=
m, as frequently happen (and will happen) in the cases presented.<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Don&#39;t=
 try to solve every problem at once.</div></div></blockquote><div>=C2=A0<br=
>Why not? It&#39;s a simple solution that covers the relevant problem: havi=
ng a placeholder. It ends up<br>solving all in an understandable manner, in=
 a uniform way.</div></div></blockquote><div><br>But it is not a &quot;simp=
le solution&quot;. Indeed, I would go so far as to say that any placeholder=
 which is currently a valid identifier is not a solution at all.<br></div><=
/div></blockquote><div><br>Restating that it&#39;s not just about reusing a=
lready valid identifiers.=C2=A0 <br></div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><br>Breaking people&#39;s per=
fectly valid code should not be considered a solution to a problem. Not wit=
hout <i>really good</i> reason. And let&#39;s face facts: unnamed variables=
 are not <i>that</i> important.<br></div></div></blockquote><div><br>I&#39;=
ve asked before about a sample where the proposals I&#39;ve endorsed would =
break people&#39;s code, do you have one (seriously)?<br><br>For the case w=
here _ can be overridden, there&#39;s no codebase that can compile with var=
iables of equal name are declared, same<br>applies for the solution where _=
 can&#39;t be referenced if declared more than once in the same scope.<br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div><br>Also, last time we tried to get something &quot;uniform&quot;,=
 we got Uniform Initialization. Which very much is not.<br><br></div><block=
quote 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>I ask why solve it =
in a case by case form?<br></div></div></blockquote><div><br>Because it wor=
ks. Not only does it work, it makes sense. That&#39;s one of the nice thing=
s about `auto[]`: based solely on the rules of structured binding, it does =
exactly what you want.<br><br>Indeed, as I think about it, if we ever wante=
d structured binding to be able to not capture all of the elements, we woul=
dn&#39;t <i>want</i> it to use placeholders. We would probably want `auto [=
x]` to bind to the first value of any tuple-like type. If that type has 30 =
variables in it, I don&#39;t care; I just want the first one. I shouldn&#39=
;t have to do `auto [x, @, @, @]` or even `auto [x, ...]` or whatever. I sa=
id that I wanted the first member, so give it to me.<br><br>Given that, `au=
to []` would bind to none of the values. Therefore, it would either be a co=
mpile error or it would work on anything, providing a hidden object that wo=
uld be destroyed at the end of scope.<br></div></div></blockquote><div><br>=
You may like that, I don&#39;t. You are focusing on a special solution for =
the<br>sake of bad practice on multiple return. I&#39;m looking for this so=
lved:<br><br> auto [x, _, y] =3D foo()<br>auto [_, y, _] =3D bar()<br>auto =
[x, _] =3D baz()<br><br>Etc, which your solution where order matters, doesn=
&#39;t cover (besides not covering the other case).<br>The time I get a tup=
le of 30 as a return, I&#39;d be looking for a refactor not support of the =
language for<br>pattern handling of that.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><br>So really, I don&#39;t see=
 this as a &quot;case-by-case form&quot;. It&#39;s really the right way to =
go for <i>both</i> problems ;)<br><br></div></div></blockquote><div><br>Whi=
ch both? You mean the correct way is to patch the language around the same =
subject, but with<br>particular solutions? <br></div></div></blockquote></d=
iv></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cce6aa50-ad77-4567-9645-65ea0b979dc5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cce6aa50-ad77-4567-9645-65ea0b979dc5=
%40isocpp.org</a>.<br />

------=_Part_1_556908580.1468212017096--

------=_Part_0_283520619.1468212017085--

.

On domingo, 10 de julho de 2016 15:18:26 PDT Francisco Lopes wrote:
> I imagine a newcomer asking an instructor: "hey why int i gives a unused
> warning but string s not?"

Answer: "because int is trivial, std::string isn't"

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2623596.rD9frYuEtL%40tjmaciei-mobl1.

.

--Apple-Mail=_9E96467C-2A36-4AAF-B4A1-BC70D6D55E0B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

What is the real problem that this thread is trying to solve? Users write:

   std::lock_guard<std::mutex>(mtx); // (1)

instead of

   std::lock_guard<std::mutex> dummy(mtx); // (2)

and every attempt coming up with a new syntax like

   auto =3D std::lock_guard<std::mutex>(mtx); // (3)

will not catch the above error at (1)! If I write (3), I could just as well=
 write (2), it does not matter if I have to write dummy, dummy1, dummy2 (IM=
HO) - the real problem is when I create a temporary of std::lock_guard like=
 in (1) that is immediately discarded.

Any solution which will prevent those bugs either has to make (1) an error =
or to extend its lifetime automatically similar to the effect of (2).

My 2=C3=A7.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/B57A5356-66D9-4CE2-8069-17DC7F9F8B63%40gmx.de.

--Apple-Mail=_9E96467C-2A36-4AAF-B4A1-BC70D6D55E0B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=signature.asc
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAleDurUACgkQAUxJbew56yGrggCdFI0uxszgsg6oYIhsdtsa987G
+scAoI2dSu7GOA8a9J6qxu/B5Bp1IJYi
=FUPr
-----END PGP SIGNATURE-----

--Apple-Mail=_9E96467C-2A36-4AAF-B4A1-BC70D6D55E0B--

.

------=_Part_8165_830445107.1468251455677
Content-Type: multipart/alternative;
 boundary="----=_Part_8166_2001451747.1468251455677"

------=_Part_8166_2001451747.1468251455677
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Removing from the language the problem regarding temporaries that
pop out of existence after end of expression was never my aim.

It's more about providing a feature than fixing a bug.

Em segunda-feira, 11 de julho de 2016 12:26:48 UTC-3, Daniel Frey escreveu:
>
> What is the real problem that this thread is trying to solve? Users write=
:=20
>
>    std::lock_guard<std::mutex>(mtx); // (1)=20
>
> instead of=20
>
>    std::lock_guard<std::mutex> dummy(mtx); // (2)=20
>
> and every attempt coming up with a new syntax like=20
>
>    auto =3D std::lock_guard<std::mutex>(mtx); // (3)=20
>
> will not catch the above error at (1)! If I write (3), I could just as=20
> well write (2), it does not matter if I have to write dummy, dummy1, dumm=
y2=20
> (IMHO) - the real problem is when I create a temporary of std::lock_guard=
=20
> like in (1) that is immediately discarded.=20
>
> Any solution which will prevent those bugs either has to make (1) an erro=
r=20
> or to extend its lifetime automatically similar to the effect of (2).=20
>
> My 2=C3=A7.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a43aefe4-72c0-4d73-81ac-6c06e4992329%40isocpp.or=
g.

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

<div dir=3D"ltr">Removing from the language the problem regarding temporari=
es that<br>pop out of existence after end of expression was never my aim.<b=
r><br>It&#39;s more about providing a feature than fixing a bug.<br><br>Em =
segunda-feira, 11 de julho de 2016 12:26:48 UTC-3, Daniel Frey  escreveu:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">What is the real problem that th=
is thread is trying to solve? Users write:
<br>
<br>=C2=A0 =C2=A0std::lock_guard&lt;std::mutex&gt;(<wbr>mtx); // (1)
<br>
<br>instead of
<br>
<br>=C2=A0 =C2=A0std::lock_guard&lt;std::mutex&gt; dummy(mtx); // (2)
<br>
<br>and every attempt coming up with a new syntax like
<br>
<br>=C2=A0 =C2=A0auto =3D std::lock_guard&lt;std::mutex&gt;(<wbr>mtx); // (=
3)
<br>
<br>will not catch the above error at (1)! If I write (3), I could just as =
well write (2), it does not matter if I have to write dummy, dummy1, dummy2=
 (IMHO) - the real problem is when I create a temporary of std::lock_guard =
like in (1) that is immediately discarded.
<br>
<br>Any solution which will prevent those bugs either has to make (1) an er=
ror or to extend its lifetime automatically similar to the effect of (2).
<br>
<br>My 2=C3=A7.
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a43aefe4-72c0-4d73-81ac-6c06e4992329%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a43aefe4-72c0-4d73-81ac-6c06e4992329=
%40isocpp.org</a>.<br />

------=_Part_8166_2001451747.1468251455677--

------=_Part_8165_830445107.1468251455677--

.

------=_Part_468_1098697776.1468252193486
Content-Type: multipart/alternative;
 boundary="----=_Part_469_1301181156.1468252193486"

------=_Part_469_1301181156.1468252193486
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Of the solutions presented, many of which I think are useful, I'm
still in favor os something along the lines of the language providing
a placeholder naming mechanism.

My main bias regarding that is because: as you have *zero* on *counting*,
on *naming* you have a *placeholder*. This is what happens in many other
programming languages, Python, Haskell, Rust, ...

I'd wish C++ moved on and embedded/learned that.

Em segunda-feira, 11 de julho de 2016 12:37:36 UTC-3, Francisco Lopes=20
escreveu:
>
> Removing from the language the problem regarding temporaries that
> pop out of existence after end of expression was never my aim.
>
> It's more about providing a feature than fixing a bug.
>
> Em segunda-feira, 11 de julho de 2016 12:26:48 UTC-3, Daniel Frey escreve=
u:
>>
>> What is the real problem that this thread is trying to solve? Users=20
>> write:=20
>>
>>    std::lock_guard<std::mutex>(mtx); // (1)=20
>>
>> instead of=20
>>
>>    std::lock_guard<std::mutex> dummy(mtx); // (2)=20
>>
>> and every attempt coming up with a new syntax like=20
>>
>>    auto =3D std::lock_guard<std::mutex>(mtx); // (3)=20
>>
>> will not catch the above error at (1)! If I write (3), I could just as=
=20
>> well write (2), it does not matter if I have to write dummy, dummy1, dum=
my2=20
>> (IMHO) - the real problem is when I create a temporary of std::lock_guar=
d=20
>> like in (1) that is immediately discarded.=20
>>
>> Any solution which will prevent those bugs either has to make (1) an=20
>> error or to extend its lifetime automatically similar to the effect of (=
2).=20
>>
>> My 2=C3=A7.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/471d7934-2db8-4411-a987-de299fd6ae8b%40isocpp.or=
g.

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

<div dir=3D"ltr">Of the solutions presented, many of which I think are usef=
ul, I&#39;m<br>still in favor os something along the lines of the language =
providing<br>a placeholder naming mechanism.<br><br>My main bias regarding =
that is because: as you have <i>zero</i> on <i>counting</i>,<br>on <i>namin=
g</i> you have a <i>placeholder</i>. This is what happens in many other<br>=
programming languages, Python, Haskell, Rust, ...<br><br>I&#39;d wish C++ m=
oved on and embedded/learned that.<br><br>Em segunda-feira, 11 de julho de =
2016 12:37:36 UTC-3, Francisco Lopes  escreveu:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr">Removing from the language the problem re=
garding temporaries that<br>pop out of existence after end of expression wa=
s never my aim.<br><br>It&#39;s more about providing a feature than fixing =
a bug.<br><br>Em segunda-feira, 11 de julho de 2016 12:26:48 UTC-3, Daniel =
Frey  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">What is the real pro=
blem that this thread is trying to solve? Users write:
<br>
<br>=C2=A0 =C2=A0std::lock_guard&lt;std::mutex&gt;(<wbr>mtx); // (1)
<br>
<br>instead of
<br>
<br>=C2=A0 =C2=A0std::lock_guard&lt;std::mutex&gt; dummy(mtx); // (2)
<br>
<br>and every attempt coming up with a new syntax like
<br>
<br>=C2=A0 =C2=A0auto =3D std::lock_guard&lt;std::mutex&gt;(<wbr>mtx); // (=
3)
<br>
<br>will not catch the above error at (1)! If I write (3), I could just as =
well write (2), it does not matter if I have to write dummy, dummy1, dummy2=
 (IMHO) - the real problem is when I create a temporary of std::lock_guard =
like in (1) that is immediately discarded.
<br>
<br>Any solution which will prevent those bugs either has to make (1) an er=
ror or to extend its lifetime automatically similar to the effect of (2).
<br>
<br>My 2=C3=A7.
<br>
<br></blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/471d7934-2db8-4411-a987-de299fd6ae8b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/471d7934-2db8-4411-a987-de299fd6ae8b=
%40isocpp.org</a>.<br />

------=_Part_469_1301181156.1468252193486--

------=_Part_468_1098697776.1468252193486--

.

On 11/07/2016 17:26, Daniel Frey wrote:
> What is the real problem that this thread is trying to solve? Users write:
>
>     std::lock_guard<std::mutex>(mtx); // (1)
Catching this type of errors is taken care of in C++17 with the
attribute [[nodiscard]].
see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0068r0.pdf
for details.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/db1d9a20-0950-c871-ec39-0505aacbe8b8%40gmx.net.

.

------=_Part_2939_1914163465.1468254606537
Content-Type: multipart/alternative;
 boundary="----=_Part_2940_254229161.1468254606538"

------=_Part_2940_254229161.1468254606538
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Em segunda-feira, 11 de julho de 2016 12:49:53 UTC-3, Francisco Lopes=20
escreveu:
>
> Of the solutions presented, many of which I think are useful, I'm
> still in favor os something along the lines of the language providing
> a placeholder naming mechanism.
>
> My main bias regarding that is because: as you have *zero* on *counting*,
> on *naming* you have a *placeholder*. This is what happens in many other
> programming languages, Python, Haskell, Rust, ...
>
> I'd wish C++ moved on and embedded/learned that.
>

Ah OK,
There was another topic on the subject some months ago:

- throwaway variable:=20
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/ioi76TkG6g4/G8WC=
37LVAAAJ

I've found it being referred at:

- Allowing unnammed loop variable in range-based for loops?=20
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/ioi76TkG6g4/G8WC=
37LVAAAJ

That's another usecase, range-for loops...

Sorry I don't follow much the discussion group, but it seems
this subject has been poping up with some frequency.

As other languages show (Python, Haskell, Rust, Go,...), and as
people are requesting, having a placeholder name is the natural
solution, which ends up solving all the usecases presented here.=20


> Em segunda-feira, 11 de julho de 2016 12:37:36 UTC-3, Francisco Lopes=20
> escreveu:
>>
>> Removing from the language the problem regarding temporaries that
>> pop out of existence after end of expression was never my aim.
>>
>> It's more about providing a feature than fixing a bug.
>>
>> Em segunda-feira, 11 de julho de 2016 12:26:48 UTC-3, Daniel Frey=20
>> escreveu:
>>>
>>> What is the real problem that this thread is trying to solve? Users=20
>>> write:=20
>>>
>>>    std::lock_guard<std::mutex>(mtx); // (1)=20
>>>
>>> instead of=20
>>>
>>>    std::lock_guard<std::mutex> dummy(mtx); // (2)=20
>>>
>>> and every attempt coming up with a new syntax like=20
>>>
>>>    auto =3D std::lock_guard<std::mutex>(mtx); // (3)=20
>>>
>>> will not catch the above error at (1)! If I write (3), I could just as=
=20
>>> well write (2), it does not matter if I have to write dummy, dummy1, du=
mmy2=20
>>> (IMHO) - the real problem is when I create a temporary of std::lock_gua=
rd=20
>>> like in (1) that is immediately discarded.=20
>>>
>>> Any solution which will prevent those bugs either has to make (1) an=20
>>> error or to extend its lifetime automatically similar to the effect of =
(2).=20
>>>
>>> My 2=C3=A7.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/41d50857-faa4-4aa5-9958-5ac7a3232aa7%40isocpp.or=
g.

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

<div dir=3D"ltr">Em segunda-feira, 11 de julho de 2016 12:49:53 UTC-3, Fran=
cisco Lopes  escreveu:<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">Of the solutions presented, many of which I think are useful, I&#3=
9;m<br>still in favor os something along the lines of the language providin=
g<br>a placeholder naming mechanism.<br><br>My main bias regarding that is =
because: as you have <i>zero</i> on <i>counting</i>,<br>on <i>naming</i> yo=
u have a <i>placeholder</i>. This is what happens in many other<br>programm=
ing languages, Python, Haskell, Rust, ...<br><br>I&#39;d wish C++ moved on =
and embedded/learned that.<br></div></blockquote><div><br>Ah OK,<br>There w=
as another topic on the subject some months ago:<br><br>- throwaway variabl=
e: <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/io=
i76TkG6g4/G8WC37LVAAAJ">https://groups.google.com/a/isocpp.org/d/msg/std-pr=
oposals/ioi76TkG6g4/G8WC37LVAAAJ</a><br><br>I&#39;ve found it being referre=
d at:<br><br>- Allowing unnammed loop variable in range-based for loops? <a=
 href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/ioi76Tk=
G6g4/G8WC37LVAAAJ">https://groups.google.com/a/isocpp.org/d/msg/std-proposa=
ls/ioi76TkG6g4/G8WC37LVAAAJ<br></a><br>That&#39;s another usecase, range-fo=
r loops...<br><br>Sorry I don&#39;t follow much the discussion group, but i=
t seems<br>this subject has been poping up with some frequency.<br><br>As o=
ther languages show (Python, Haskell, Rust, Go,...), and as<br>people are r=
equesting, having a placeholder name is the natural<br>solution, which ends=
 up solving all the usecases presented here. <br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><br>Em segunda-feira, 11 de j=
ulho de 2016 12:37:36 UTC-3, Francisco Lopes  escreveu:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">Removing from the language the problem=
 regarding temporaries that<br>pop out of existence after end of expression=
 was never my aim.<br><br>It&#39;s more about providing a feature than fixi=
ng a bug.<br><br>Em segunda-feira, 11 de julho de 2016 12:26:48 UTC-3, Dani=
el Frey  escreveu:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">What is the real =
problem that this thread is trying to solve? Users write:
<br>
<br>=C2=A0 =C2=A0std::lock_guard&lt;std::mutex&gt;(<wbr>mtx); // (1)
<br>
<br>instead of
<br>
<br>=C2=A0 =C2=A0std::lock_guard&lt;std::mutex&gt; dummy(mtx); // (2)
<br>
<br>and every attempt coming up with a new syntax like
<br>
<br>=C2=A0 =C2=A0auto =3D std::lock_guard&lt;std::mutex&gt;(<wbr>mtx); // (=
3)
<br>
<br>will not catch the above error at (1)! If I write (3), I could just as =
well write (2), it does not matter if I have to write dummy, dummy1, dummy2=
 (IMHO) - the real problem is when I create a temporary of std::lock_guard =
like in (1) that is immediately discarded.
<br>
<br>Any solution which will prevent those bugs either has to make (1) an er=
ror or to extend its lifetime automatically similar to the effect of (2).
<br>
<br>My 2=C3=A7.
<br>
<br></blockquote></div></blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/41d50857-faa4-4aa5-9958-5ac7a3232aa7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/41d50857-faa4-4aa5-9958-5ac7a3232aa7=
%40isocpp.org</a>.<br />

------=_Part_2940_254229161.1468254606538--

------=_Part_2939_1914163465.1468254606537--

.

On 2016-07-10 18:25, Zhihao Yuan wrote:
> My suggestion has always been a simple
>
>   with (auto lk = unique_lock(lk)) {
>   }
>
> which is already available as `if (auto ...; true)`,
> and
>
>   with (lock_guard(lk)) {
>   }
>
> whose the wording for introducing a unique name
> has already presented in the structured binding
> proposal.

Would this be legal?

  with (lock_guard(a); lock_guard(b))
  { ... }

I definitely have cases where I want more than one "guard". I'd prefer
to not need to create a scope for each one.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nm0mub%24vda%241%40ger.gmane.org.

.

On 2016-07-10 16:33, Francisco Lopes wrote:
> By the way, fyi, the discussion referred by Ville tells about using __
> instead of _

I've probably said this before... what about `.`?

  auto . = lock_guard(m_mutex);

Since `.` is not a valid identifier, there are no possible conflicts
with existing code. (Also, I think it looks slightly prettier :-).)

....`:` could be a candidate also...

As Nevin noted, `__` is reserved for *implementations*. In theory at
least, there might be an implementation actually *using* `__` that would
be broken if `__` were used for unnamed locals.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nm0n86%244co%241%40ger.gmane.org.

.

On 2016-07-10 19:44, Nicol Bolas wrote:
> Wait a minute. Let's think about what we just added to C++: structured
> binding:
>
> auto [a, b] = ...;
>
> Now, the way structured binding works is that it takes the expression and
> stores it in a hidden variable. It then gets references to the members,
> either directly from public members or with a particular interface. That's
> how the concept is semantically defined:
>
> auto &&temp = make_pair(3, 4.5f);
> auto &a = temp.first;
> auto &b = temp.second;
>
> So... what happens if we do this:
>
> auto [] = ...;

You get an error because the number of bindings does not match the
number of things to be bound (i.e. the PT-size). *This is a good thing.*

For that to work, you'd need slicing:

  auto [] = ...[0:0];

(...or unnamed placeholders, but those only work if the PT-size is
known, or... if you don't use unpacking, in which case we're back to the
original proposal.)

That, or you're defining a new thing that *looks* like unpacking, but is
really something very different. Ick.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nm0na0%244co%242%40ger.gmane.org.

.

On 2016-07-11 14:21, D. B. wrote:
> On Mon, Jul 11, 2016 at 7:20 PM, D. B. wrote:
>> Can someone explain to me what this actually offers over
>>
>> { std::lock_guard(whatever);
>>     // do stuff
>> }
>>
>> because I must be missing something, as right now, it just looks like
>> adding a new keyword for no reason whatsoever, and eschewing a perfectly
>> valid use of temporary blocks in the process. IOW, completely redundant and
>> counterproductive.
>>
>> so i must've missed an undeniable benefit, right?
>
> sorry, of course I meant to include a variable name in that declaration,
> e.g. *a* or *b*

You don't need to name the variable, therefore:

- You are guaranteed to not accidentally shadow some other variable
without jumping through complicated hoops to do so.

- You are guaranteed that the variable cannot accidentally be accessed.

- It can interact better with compiler warnings about unused variables.

Also, by making it part of the language, you don't have to "add" it to
every project in which you want to use it.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nm0p2l%2414p%241%40ger.gmane.org.

.

On 2016-07-11 11:26, Daniel Frey wrote:
> What is the real problem that this thread is trying to solve? Users write:
>
>    std::lock_guard<std::mutex>(mtx); // (1)
>
> instead of
>
>    std::lock_guard<std::mutex> dummy(mtx); // (2)
>
> and every attempt coming up with a new syntax like
>
>    auto = std::lock_guard<std::mutex>(mtx); // (3)
>
> will not catch the above error at (1)! If I write (3), I could just
> as well write (2), it does not matter if I have to write dummy,
> dummy1, dummy2 (IMHO) - the real problem is when I create a temporary
> of std::lock_guard like in (1) that is immediately discarded.

Some folks (myself included) consider needing to provide a name to
already be a problem.

> Any solution which will prevent those bugs either has to make (1) an
> error or to extend its lifetime automatically similar to the effect
> of (2).

Doesn't [[nodiscard]] already accomplish this? Or at least offer a
significant improvement?

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nm0pbd%2414p%242%40ger.gmane.org.

.

------=_Part_449_1005052412.1468264616668
Content-Type: multipart/alternative;
 boundary="----=_Part_450_251867636.1468264616668"

------=_Part_450_251867636.1468264616668
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Em segunda-feira, 11 de julho de 2016 15:07:11 UTC-3, Matthew Woehlke=20
escreveu:
>
> On 2016-07-10 16:33, Francisco Lopes wrote:=20
> > By the way, fyi, the discussion referred by Ville tells about using __=
=20
> > instead of _=20
>
> I've probably said this before... what about `.`?=20
>
>   auto . =3D lock_guard(m_mutex);=20
>
> Since `.` is not a valid identifier, there are no possible conflicts=20
> with existing code. (Also, I think it looks slightly prettier :-).)


I also think it's pretty, I've thought about it but didn't comment. The=20
reason
I find it pretty is that it resembles mathematical notation f(=C2=B7)

....`:` could be a candidate also...=20
>

Ville commented before it woudn't be a good idea because it would clash
with parameter packs.

But, for example, Rust has both "_" and "..", C++ has no use for "..", whic=
h
coud be used, although I'd prefer to see ".." always matching 0 or more, fo=
r
which purpose "..." already fits.

So, for me it's fine having stuff like

lock_guard<mutex> .(a), .(b);

auto [ . , x , . ] =3D foo()

or

auto [ . , x , ... ] =3D foo()

As Nevin noted, `__` is reserved for *implementations*. In theory at=20
> least, there might be an implementation actually *using* `__` that would=
=20
> be broken if `__` were used for unnamed locals.=20
>
> --=20
> Matthew=20
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/70779d7b-9901-4010-8e33-49f21ad39fc1%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>Em segunda-feira, 11 de julho de 2016 15:07:11 UTC=
-3, Matthew Woehlke  escreveu:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
On 2016-07-10 16:33, Francisco Lopes wrote:
<br>&gt; By the way, fyi, the discussion referred by Ville tells about usin=
g __=20
<br>&gt; instead of _
<br>
<br>I&#39;ve probably said this before... what about `.`?
<br>
<br>=C2=A0 auto . =3D lock_guard(m_mutex);
<br>
<br>Since `.` is not a valid identifier, there are no possible conflicts
<br>with existing code. (Also, I think it looks slightly prettier :-).)</bl=
ockquote><div><br>I also think it&#39;s pretty, I&#39;ve thought about it b=
ut didn&#39;t comment. The reason<br>I find it pretty is that it resembles =
mathematical notation f(=C2=B7)<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">...`:` could be a candidate also...
<br></blockquote><div><br>Ville commented before it woudn&#39;t be a good i=
dea because it would clash<br>with parameter packs.<br><br>But, for example=
, Rust has both &quot;_&quot; and &quot;..&quot;, C++ has no use for &quot;=
...&quot;, which<br>coud be used, although I&#39;d prefer to see &quot;..&qu=
ot; always matching 0 or more, for<br>which purpose &quot;...&quot; already=
 fits.<br><br>So, for me it&#39;s fine having stuff like<br><br>lock_guard&=
lt;mutex&gt; .(a), .(b);<br><br>auto [ . , x , . ] =3D foo()<br><br>or<br><=
br>auto [ . , x , ... ] =3D foo()<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">As Nevin noted, `__` is reserved for *implementations*. In=
 theory at
<br>least, there might be an implementation actually *using* `__` that woul=
d
<br>be broken if `__` were used for unnamed locals.
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/70779d7b-9901-4010-8e33-49f21ad39fc1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/70779d7b-9901-4010-8e33-49f21ad39fc1=
%40isocpp.org</a>.<br />

------=_Part_450_251867636.1468264616668--

------=_Part_449_1005052412.1468264616668--

.

On 2016-07-11 15:16, Francisco Lopes wrote:
> Em segunda-feira, 11 de julho de 2016 15:07:11 UTC-3, Matthew Woehlke
> escreveu:
>> ...`:` could be a candidate also...
>>
>
> Ville commented before it woudn't be a good idea because it would clash
> with parameter packs.

I think you misread :-): the proposed placeholder was `:` (note: the
backticks are just to show code; they're not part of the proposed
syntax). The "..." in the above was merely grammatical.

Offhand, I can't think of a use of a single ':' except in the ternary
operator, so it seems available...

That all said, `.` would be my first choice.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nm0s08%24dbb%241%40ger.gmane.org.

.

On 2016-07-11 15:11, Zhihao Yuan wrote:
> On Mon, Jul 11, 2016 at 1:01 PM, Matthew Woehlke wrote:
>> Would this be legal?
>>
>>   with (lock_guard(a); lock_guard(b))
>>   { ... }
>
> Very likely.  But the whole suggestion depends
> on whether people can live with one extra
> nested scope.

Are you proposing `with` as a proper language extension, or as a macro
implemented with `if(expr; true)`? If the latter, is `if(expr; expr;
....; condition)` legal? (I guess it would be nice if it is, but I
haven't read the proposal or followed up on it to know offhand...)

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/nm0s43%24dbb%242%40ger.gmane.org.

.

--Apple-Mail=_6607A3F5-A246-4956-AB6A-9A12B550ED0E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> On 11.07.2016, at 20:42, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote=
:
>=20
> On 2016-07-11 11:26, Daniel Frey wrote:
>> What is the real problem that this thread is trying to solve? Users writ=
e:
>>=20
>>   std::lock_guard<std::mutex>(mtx); // (1)
>>=20
>> instead of
>>=20
>>   std::lock_guard<std::mutex> dummy(mtx); // (2)
>>=20
>> and every attempt coming up with a new syntax like
>>=20
>>   auto =3D std::lock_guard<std::mutex>(mtx); // (3)
>>=20
>> will not catch the above error at (1)! If I write (3), I could just
>> as well write (2), it does not matter if I have to write dummy,
>> dummy1, dummy2 (IMHO) - the real problem is when I create a temporary
>> of std::lock_guard like in (1) that is immediately discarded.
>=20
> Some folks (myself included) consider needing to provide a name to
> already be a problem.

Some people (like me) don't consider it a big problem. That does not mean a=
ny of us is right, though - the question is how important it is compared to=
 the many other things that could be improved and if it warrants a language=
 change.

>> Any solution which will prevent those bugs either has to make (1) an
>> error or to extend its lifetime automatically similar to the effect
>> of (2).
>=20
> Doesn't [[nodiscard]] already accomplish this? Or at least offer a
> significant improvement?

Maybe, but the compiler is (AFAIK) only encouraged to give you some warning=
, it might just as well ignore the attribute completely. Unlikely, I know, =
but the important thing is, it is still "just" a warning. I usually compile=
 with -Werror, but a lot of (commercial) projects I know of have lots of wa=
rnings which they ignore.

So even as it is an improvement, I could imagine other features like an aut=
omatically prolonged lifetime of a unbound value returned by a function or =
constructor call. Not saying this is better, just an alternative to conside=
r. Probably depends on what are the use-cases you consider important. The d=
ifference is that you'd make it invisible while this thread, so far, is con=
centrating on explicitly prolonged lifetime. My feeling is that the C++ syn=
tax is complicated enough for the caller, so I'd prefer a new attribute (or=
 something else) on the library side, maybe:

  class [[autoexpand_scope]] lock_guard { ... };

(needs better name, I know)

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5BFC915A-1467-46CC-AF2B-3EC052E26032%40gmx.de.

--Apple-Mail=_6607A3F5-A246-4956-AB6A-9A12B550ED0E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename=signature.asc
Content-Type: application/pgp-signature;
 name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAleD9UwACgkQAUxJbew56yFnDQCfWK3v5XMRPugjej38or2cK1Pl
BdEAoIceY/YMiAPzn6+Ow2aGoGSnparF
=cpJr
-----END PGP SIGNATURE-----

--Apple-Mail=_6607A3F5-A246-4956-AB6A-9A12B550ED0E--

.