------=_Part_11113_487753511.1515334749571
Content-Type: multipart/alternative;
 boundary="----=_Part_11114_1634142241.1515334749572"

------=_Part_11114_1634142241.1515334749572
Content-Type: text/plain; charset="UTF-8"

Currently some decl specifiers are not allowed on structured bindings, for
no reason at all it
seems (https://stackoverflow.com/questions/41622896/why-cant-decomposition-declarations-be-constexpr).
Attached you'll find my proposal, but beware, it's not that good yet, as
this is my first time writing an actual proposal. But first I want to make
sure that it is reasonable, maybe you all might find a major problem that I
haven't thought of yet.

TL;DR: I want to propose to allow constexpr, static and thread_local for
structured bindings. This will allow for example

    constexpr auto[x, y] = std::tuple(1, 2); // currently ill-formed

Any suggestions are welcome :)

--
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/8a5b7f07-8e4d-4df8-9977-9056e9c9a74b%40isocpp.org.

------=_Part_11114_1634142241.1515334749572
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Currently some decl specifiers are not allowed on structur=
ed bindings, for no reason at all=C2=A0it seems=C2=A0(https://stackoverflow=
..com/questions/41622896/why-cant-decomposition-declarations-be-constexpr).<=
div>Attached you&#39;ll find my proposal, but beware, it&#39;s not that goo=
d yet, as this is my first time writing an actual proposal. But first I wan=
t to make sure that it is reasonable, maybe you all might find a major prob=
lem that I haven&#39;t thought of yet.</div><div><br></div><div>TL;DR: I wa=
nt to propose to allow constexpr, static and thread_local for structured bi=
ndings. This will allow for example</div><div><br></div><div>=C2=A0 =C2=A0 =
constexpr auto[x, y] =3D std::tuple(1, 2); // currently ill-formed</div><di=
v><br></div><div>Any suggestions are welcome :)</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/8a5b7f07-8e4d-4df8-9977-9056e9c9a74b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8a5b7f07-8e4d-4df8-9977-9056e9c9a74b=
%40isocpp.org</a>.<br />

------=_Part_11114_1634142241.1515334749572--

------=_Part_11113_487753511.1515334749571
Content-Type: text/html; charset=UTF-8;
 name="More decl-specifiers for structured bindings.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="More decl-specifiers for structured bindings.html"
X-Attachment-Id: f730af3f-1724-4036-8850-4c43e65b5473
Content-ID: <f730af3f-1724-4036-8850-4c43e65b5473>

=EF=BB=BF<h1 id=3D"constexpr-static-threadlocal-for-structured-bindings">co=
nstexpr, static, thread_local for structured bindings</h1>

<p>Currently, constexpr, static, thread_local are not allowed to be used on=
 structured bindings:</p>

<pre><code>constexpr auto[x, y] =3D std::tuple(1, 2); // ill-formed
// same for static and thread_local
</code></pre>

<p>This problem was already mentioned in US-95 of <a href=3D"https://wg21.l=
ink/P0488r0">P0488r0</a>:</p>

<blockquote>
  <p>There is no obvious reason why decomposition declarations cannot be de=
clared as static, thread_local, or constexpr.</p>
</blockquote>

<p>But this change wasn=E2=80=99t incorporated in the November 2016 meeting=
, due to the unclear meaning of those specifiers on structured bindings.</p=
>



<h3 id=3D"solution">Solution</h3>

<p>I propose that the either one of the decl specifiers apply to the variab=
le from which the structured binding is constructed, as well as the individ=
ual elements.</p>

<pre><code>constexpr auto[x, y] =3D std::tuple(1, 2);
// is equivalent to today's
constexpr auto __var =3D std::tuple(1, 2);
constexpr auto x =3D std::get&lt;0&gt;(__var);
constexpr auto y =3D std::get&lt;1&gt;(__var);
</code></pre>

<p>Having the decl specifier apply to both <code>__var</code> and the indiv=
idual declarations inside the brackets allows for the most consistent and u=
nsurprising behavior. Let=E2=80=99s consider the three other cases:</p>

<ol>
<li><strong>Decl specifiers should have no effect</strong>. This is a nonse=
nsical, allowing a decl specifier on a declaration without it having the =
=E2=80=9Cnormal=E2=80=9D effect. This is basically what we have now, but wo=
rse.</li>
<li><p><strong>Decl specifiers should only apply to <code>__var</code></str=
ong>. This solution has several problems. One is that the programmer in the=
 declaration of x and y above would reasonably expect for them to be conste=
xpr, but this isn=E2=80=99t the case! As the constexpr specifier would only=
 apply to <code>__var</code>, x and y would be unaffected by it. </p>

<p>Also, if instead I=E2=80=99d use static, the problem would cause really =
hard to track down bugs, because that would cause x and y to be reconstruct=
ed every time, instead of of only once.</p></li>
<li><p><strong>Decl specifiers should only apply to x and y.</strong> This =
solution suffers from the same problem as mentioned above with static, only=
 now, <code>__var</code> would be reinitialized every time. Additionally, t=
he actual problem happens when using constexpr. The declaration above would=
 not even compile! Because <code>__var</code> wouldn=E2=80=99t be a constan=
t expression, and thus wouldn=E2=80=99t be able to be used to initialize x =
and y. This is very counterintuitive and goes against the reason of marking=
 the structured binding constexpr in the first place.</p></li>
</ol>

<p>Here is an example from one of my projects:</p>

<pre><code>static const auto Background =3D getColorOnScreen(64, 128);
static const auto Red =3D std::get&lt;0&gt;(Background);
static const auto Green =3D std::get&lt;1&gt;(Background);
static const auto Blue =3D std::get&lt;2&gt;(Background);
</code></pre>

<p>I need to get the individual color components of the background, which d=
oesn=E2=80=99t change and thus should be static. Using this proposal:</p>

<pre><code> static const auto[Red, Green, Blue] =3D getColorOnScreen(64, 12=
8); // way shorter
</code></pre>
------=_Part_11113_487753511.1515334749571--

.