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

In a recent thread here, there was a proposal for a special variable name
__ that could be used multiple times within a block, essentially
introducing a new case in [basic.scope.hiding].

Now the question is, why can't we introduce such a case there for *any*
local variable? Then one would be able to define multiple identically named
variables within one and the same scope; all except the latest will be
hidden.

That will trivially address all of the points of the __ proposal. For
example:

lock_guard g(mutex1);
lock_guard g(mutex2);

auto [a, x, x, b] = foo();

The advantage of that would be in the avoidance of magic variable names,
and having to reach consensus as to what they should be.

The disadvantage... I am actually not that sure there is a serious
disadvantage. An obvious point can be made that accidental typos might
introduce subtle errors. But the same kind of accidental typos is possible
today, except that the accidental typo must reside in a nested block.
However, lengthy and flat blocks are rare in regular C++. A typical block
either is short and flat, or is lengthy and contains nested blocks, so the
typos are more likely to be made in nested blocks, so no significant new
risk is introduced.

Other opinions?

Cheers,
V.

--
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/CAA7YVg36Lk6wGAHNcWky-NCQpPPKmVq9sAnWrXYmj-DLqzTObA%40mail.gmail.com.

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

<div dir=3D"ltr">In a recent thread here, there was a proposal for a specia=
l variable name __ that could be used multiple times within a block, essent=
ially introducing a new case in [basic.scope.hiding].<div><br></div><div>No=
w the question is, why can&#39;t we introduce such a case there for <i>any<=
/i> local variable? Then one would be able to define multiple identically n=
amed variables within one and the same scope; all except the latest will be=
 hidden.</div><div><br></div><div>That will trivially address all of the po=
ints of the __ proposal. For example:</div><div><br></div><div>lock_guard g=
(mutex1);</div><div>lock_guard g(mutex2);</div><div><br></div><div>auto [a,=
 x, x, b] =3D foo();</div><div><br></div><div>The advantage of that would b=
e in the avoidance of magic variable names, and having to reach consensus a=
s to what they should be.</div><div><br></div><div>The disadvantage... I am=
 actually not that sure there is a serious disadvantage. An obvious point c=
an be made that accidental typos might introduce subtle errors. But the sam=
e kind of accidental typos is possible today, except that the accidental ty=
po must reside in a nested block. However, lengthy and flat blocks are rare=
 in regular C++. A typical block either is short and flat, or is lengthy an=
d contains nested blocks, so the typos are more likely to be made in nested=
 blocks, so no significant new risk is introduced.</div><div><br></div><div=
>Other opinions?<br></div><div><br></div><div>Cheers,</div><div>V.</div></d=
iv>

<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/CAA7YVg36Lk6wGAHNcWky-NCQpPPKmVq9sAnW=
rXYmj-DLqzTObA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg36Lk6wGAHN=
cWky-NCQpPPKmVq9sAnWrXYmj-DLqzTObA%40mail.gmail.com</a>.<br />

--94eb2c04420e4febe2054c2dd71a--

.

On 2 April 2017 at 15:04, Viacheslav Usov <via.usov@gmail.com> wrote:
> In a recent thread here, there was a proposal for a special variable name __
> that could be used multiple times within a block, essentially introducing a
> new case in [basic.scope.hiding].
>
> Now the question is, why can't we introduce such a case there for any local
> variable? Then one would be able to define multiple identically named
> variables within one and the same scope; all except the latest will be
> hidden.

The whole point is having a name that can't be referred to. In
addition, allowing multiple
variables with the same name sounds like a recipe for bugs.

--
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/CAFk2RUZBDyBuz7XnnK5pawZ0F_26AVLFjK%2BjUo3e0JdUq4G6Ng%40mail.gmail.com.

.

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

On Sun, Apr 2, 2017 at 2:12 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> The whole point is having a name that can't be referred to.

No, not in this thread. And even in the other thread, that view is not
unversally held, as the recent branch of discussion initiated by Richard
Smith indicates plainly.

The whole point of this proposal is to allow infinitely many identically
named variables within one block scope, with variables introduced later
hiding those declared earlier. That addresses the need of having something
purely for RAII, and also the need of a placeholder for structured
bindings. It also addresses the discussion (which, in my opinion, ranges
from bikeshedding to nonsense) about the name of such variables, by
eliminating the discussion.

> In addition, allowing multiple variables with the same name sounds like a
recipe for bugs.

I did assess that in the original message, which you seem to have ignored
fully. For the record, my conclusion was the opposite of yours.

Cheers,
V.

--
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/CAA7YVg2T%2BMt6Las_QMwhFP8Oqn1BSS%2BiQG-_JqxCTxsu04VEnA%40mail.gmail.com.

--94eb2c070e9810147a054c3eeb2f
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, Apr 2, 2017 at 2:12 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br><div><br></div><div>&gt; The whole poin=
t is having a name that can&#39;t be referred to.</div><div><br></div><div>=
No, not in this thread. And even in the other thread, that view is not unve=
rsally held, as the recent branch of discussion initiated by Richard Smith =
indicates plainly.</div><div><br></div><div>The whole point of this proposa=
l is to allow infinitely many identically named variables within one block =
scope, with variables introduced later hiding those declared earlier. That =
addresses the need of having something purely for RAII, and also the need o=
f a placeholder for structured bindings. It also addresses the discussion (=
which, in my opinion, ranges from bikeshedding to nonsense) about the name =
of such variables, by eliminating the discussion.</div><div><br></div><div>=
&gt; In addition, allowing multiple variables with the same name sounds lik=
e a recipe for bugs.</div><div><br></div><div>I did assess that in the orig=
inal message, which you seem to have ignored fully. For the record, my conc=
lusion was the opposite of yours.</div><div><br></div><div>Cheers,</div><di=
v>V.</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/CAA7YVg2T%2BMt6Las_QMwhFP8Oqn1BSS%2Bi=
QG-_JqxCTxsu04VEnA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2T%2BM=
t6Las_QMwhFP8Oqn1BSS%2BiQG-_JqxCTxsu04VEnA%40mail.gmail.com</a>.<br />

--94eb2c070e9810147a054c3eeb2f--

.

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

If Viacheslav's proposal goes forward I'd like to see the scoping working
in initialization of such variables like this:

int x=5;
{
  double x=x; // initialized from int
}
{
  float x=x; // initialized from int, not from double
}

if (double x=x) // initialized from int
{
  long double x=x; // initialized from double
}
else
{
  float x=x; // initialized from double
}

That would work roughly as lambda captures [double x=x] and would be
especially useful with inline lambdas ("Statement expressions proposal").

Thanks,
Maxim


On Mon, Apr 3, 2017 at 4:26 PM, Viacheslav Usov <via.usov@gmail.com> wrote:

> On Sun, Apr 2, 2017 at 2:12 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
> > The whole point is having a name that can't be referred to.
>
> No, not in this thread. And even in the other thread, that view is not
> unversally held, as the recent branch of discussion initiated by Richard
> Smith indicates plainly.
>
> The whole point of this proposal is to allow infinitely many identically
> named variables within one block scope, with variables introduced later
> hiding those declared earlier. That addresses the need of having something
> purely for RAII, and also the need of a placeholder for structured
> bindings. It also addresses the discussion (which, in my opinion, ranges
> from bikeshedding to nonsense) about the name of such variables, by
> eliminating the discussion.
>
> > In addition, allowing multiple variables with the same name sounds like
> a recipe for bugs.
>
> I did assess that in the original message, which you seem to have ignored
> fully. For the record, my conclusion was the opposite of yours.
>
> Cheers,
> V.
>
> --
> 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/is
> ocpp.org/d/msgid/std-proposals/CAA7YVg2T%2BMt6Las_QMwhFP8Oqn
> 1BSS%2BiQG-_JqxCTxsu04VEnA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2T%2BMt6Las_QMwhFP8Oqn1BSS%2BiQG-_JqxCTxsu04VEnA%40mail.gmail.com?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/CA%2B6mTDcNM%2BV1Lxsu4-gqthq88WjvQq9s_CEWnw5M7JqR%2Bj5FAw%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div><div>If Viacheslav&#39;s proposal goes forward I=
&#39;d like to see the scoping working in initialization of such variables =
like this:<br><br></div>int x=3D5;<br>{<br></div>=C2=A0 double x=3Dx; // in=
itialized from int<br>}<br>{ <br>=C2=A0 float x=3Dx; // initialized from in=
t, not from double<br>}<br><br></div>if (double x=3Dx)  // initialized from=
 int<br>{<br><div>=C2=A0 long double x=3Dx; // initialized from double<br>}=
<br></div><div>else<br></div><div>{ <br>=C2=A0 float x=3Dx; // initialized =
from double<br>}<br><br></div><div>That would work roughly as lambda captur=
es [double x=3Dx] and would be especially useful with inline lambdas (&quot=
;Statement expressions proposal&quot;).<br><br></div><div></div><div>Thanks=
,<br></div><div>Maxim<br></div><div><br></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On Mon, Apr 3, 2017 at 4:26 PM, Viacheslav Uso=
v <span dir=3D"ltr">&lt;<a href=3D"mailto:via.usov@gmail.com" target=3D"_bl=
ank">via.usov@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><span>On Sun, Apr 2, 2017 at 2:12 PM, Ville Voutilainen=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" targe=
t=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div><br>=
</div><div>&gt; The whole point is having a name that can&#39;t be referred=
 to.</div><div><br></div></span><div>No, not in this thread. And even in th=
e other thread, that view is not unversally held, as the recent branch of d=
iscussion initiated by Richard Smith indicates plainly.</div><div><br></div=
><div>The whole point of this proposal is to allow infinitely many identica=
lly named variables within one block scope, with variables introduced later=
 hiding those declared earlier. That addresses the need of having something=
 purely for RAII, and also the need of a placeholder for structured binding=
s. It also addresses the discussion (which, in my opinion, ranges from bike=
shedding to nonsense) about the name of such variables, by eliminating the =
discussion.</div><span><div><br></div><div>&gt; In addition, allowing multi=
ple variables with the same name sounds like a recipe for bugs.</div><div><=
br></div></span><div>I did assess that in the original message, which you s=
eem to have ignored fully. For the record, my conclusion was the opposite o=
f yours.</div><div><br></div><div>Cheers,</div><div>V.</div></div></div></d=
iv><span>

<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@isoc<wbr>pp.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/CAA7YVg2T%2BMt6Las_QMwhFP8Oqn1BSS%2Bi=
QG-_JqxCTxsu04VEnA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/=
std-proposals<wbr>/CAA7YVg2T%2BMt6Las_QMwhFP8Oqn<wbr>1BSS%2BiQG-_JqxCTxsu04=
VEnA%<wbr>40mail.gmail.com</a>.<br>
</blockquote></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/CA%2B6mTDcNM%2BV1Lxsu4-gqthq88WjvQq9s=
_CEWnw5M7JqR%2Bj5FAw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2B6mTDcN=
M%2BV1Lxsu4-gqthq88WjvQq9s_CEWnw5M7JqR%2Bj5FAw%40mail.gmail.com</a>.<br />

--001a113d17961096ea054c3f96d8--

.

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

On Mon, Apr 3, 2017 at 11:13 AM, Maxim Yanchenko <maxim.yanchenko@gmail.com=
>
wrote:

> If Viacheslav's proposal goes forward I'd like to see the scoping working
> in initialization of such variables like this:
>
> int x=3D5;
> {
>   double x=3Dx; // initialized from int
> }
> {
>   float x=3Dx; // initialized from int, not from double
> }
>
>
The above would conflict with [basic.scope.pdecl]:

The point of declaration for a name is immediately after its complete
declarator (Clause 8) and before its initializer (if any), except as noted
below. [ Example:

 unsigned char x =3D 12;
 { unsigned char x =3D x; }

Here the second x is initialized with its own (indeterminate) value. =E2=80=
=94 end
example ]

(end)

I doubt we can change that easily.

Cheers,
V.

--=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/CAA7YVg2JX6_sSFzyMV3hw9QfUw4JAmq7qr-J6NMC8Roez3k=
Vhg%40mail.gmail.com.

--94eb2c070e988967b0054c3fde79
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 M=
on, Apr 3, 2017 at 11:13 AM, Maxim Yanchenko <span dir=3D"ltr">&lt;<a href=
=3D"mailto:maxim.yanchenko@gmail.com" target=3D"_blank">maxim.yanchenko@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div><div><div>If Viacheslav&#39;s proposal goes fo=
rward I&#39;d like to see the scoping working in initialization of such var=
iables like this:<br><br></div>int x=3D5;<br>{<br></div>=C2=A0 double x=3Dx=
; // initialized from int<br>}<br>{ <br>=C2=A0 float x=3Dx; // initialized =
from int, not from double<br>}<br><br></div></div></blockquote><div><br></d=
iv><div>The above would conflict with [basic.scope.pdecl]:<br></div><div><b=
r></div><div>The point of declaration for a name is immediately after its c=
omplete declarator (Clause 8) and before its
initializer (if any), except as noted below. [ Example:</div><div><br></div=
><div>=C2=A0unsigned char x =3D 12;</div><div>=C2=A0{ unsigned char x =3D x=
; }</div><div><br></div><div>Here the second x is initialized with its own =
(indeterminate) value. =E2=80=94 end example ]<br></div><div><br></div><div=
>(end)</div><div><br></div><div>I doubt we can change that easily.</div><di=
v><br></div><div>Cheers,</div><div>V.</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/CAA7YVg2JX6_sSFzyMV3hw9QfUw4JAmq7qr-J=
6NMC8Roez3kVhg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2JX6_sSFzy=
MV3hw9QfUw4JAmq7qr-J6NMC8Roez3kVhg%40mail.gmail.com</a>.<br />

--94eb2c070e988967b0054c3fde79--

.