Topic: Inline variables (encapsulated expressions),
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Sun, 14 Sep 2014 10:50:26 -0700 (PDT)
Raw View
------=_Part_1989_1594787045.1410717026997
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The example at the end of 2.3 is missing the `inline` keyword I think.
A larger question: how much of this facility can be emulated today using=20
variable templates? Can you have inline variable templates? Would you ever=
=20
want/need to?
On Sunday, September 14, 2014 1:59:02 AM UTC-7, David Krauss wrote:
>
> Hi all, it=E2=80=99s proposal time again!
>
> Abstract:
> =E2=80=93=E2=80=93=E2=80=93
> Inline functions have favorable behavior for some kinds of object-like=20
> entities. Often, users are encouraged to use them to wrap global variable=
s.=20
> This has long been the status quo, despite the unnatural boilerplate. Als=
o,=20
> it does not work with constexpr, leaving a gap in the language. This=20
> proposal defines the inline specifier on variable definitions to indicate=
=20
> semantics similar to inline function evaluation and linkage. More=20
> generally, this produces a facility for named values, or variables that a=
re=20
> not objects. Applications include displacing legacy value-like macros and=
=20
> introducing data-like class interfaces without impacting layout.
> =E2=80=93=E2=80=93=E2=80=93
>
> http://bit.ly/1qTSBiP
>
> Please let me know if you find anything inspiring, bewildering, or=20
> nauseating.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1989_1594787045.1410717026997
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The example at the end of 2.3 is missing the `inline` keyw=
ord I think.<div><br></div><div>A larger question: how much of this facilit=
y can be emulated today using variable templates? Can you have inline varia=
ble templates? Would you ever want/need to?<br><br>On Sunday, September 14,=
2014 1:59:02 AM UTC-7, David Krauss wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div style=3D"word-wrap:break-word">Hi all, it=E2=80=99s propo=
sal time again!<div><br></div><div>Abstract:</div><div>=E2=80=93=E2=80=93=
=E2=80=93</div><div>Inline functions have favorable behavior for some kinds=
of object-like entities. Often, users are encouraged to use them to wrap g=
lobal variables. This has long been the status quo, despite the unnatu=
ral boilerplate. Also, it does not work with constexpr, leaving a gap =
in the language. This proposal defines the inline specifier =
on variable definitions to indicate semantics similar to inline function ev=
aluation and linkage. More generally, this produces a facility for nam=
ed values, or variables that are not objects. Applications include displaci=
ng legacy value-like macros and introducing data-like class interfaces with=
out impacting layout.<br>=E2=80=93=E2=80=93=E2=80=93</div><div><br></div><d=
iv><a href=3D"http://bit.ly/1qTSBiP" target=3D"_blank" onmousedown=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2F1qTSBiP\46sa\75=
D\46sntz\0751\46usg\75AFQjCNFTCYOa2OnQSCobZqUy4JEqmNHVUA';return true;" onc=
lick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fbit.ly%2F1q=
TSBiP\46sa\75D\46sntz\0751\46usg\75AFQjCNFTCYOa2OnQSCobZqUy4JEqmNHVUA';retu=
rn true;"><span>http://</span>bit.ly/1qTSBiP</a></div><div><br></div><div>P=
lease let me know if you find anything inspiring, bewildering, or nauseatin=
g.</div></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1989_1594787045.1410717026997--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 14 Sep 2014 11:44:44 -0700
Raw View
--bcaec5014c1d6f488c05030ae916
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 14 Sep 2014 10:50, "Sean Middleditch" <sean.middleditch@gmail.com> wrote=
:
>
> The example at the end of 2.3 is missing the `inline` keyword I think.
>
> A larger question: how much of this facility can be emulated today using
variable templates? Can you have inline variable templates? Would you ever
want/need to?
I would expect the answers to be exactly the same as for function
templates: you can make a variable template inline, but it has (almost) no
semantic effect. Likewise, making a variable template explicit
specialization inline would allow it to be defined in a header.
> On Sunday, September 14, 2014 1:59:02 AM UTC-7, David Krauss wrote:
>>
>> Hi all, it=E2=80=99s proposal time again!
>>
>> Abstract:
>> =E2=80=93=E2=80=93=E2=80=93
>> Inline functions have favorable behavior for some kinds of object-like
entities. Often, users are encouraged to use them to wrap global variables.
This has long been the status quo, despite the unnatural boilerplate. Also,
it does not work with constexpr, leaving a gap in the language. This
proposal defines the inline specifier on variable definitions to indicate
semantics similar to inline function evaluation and linkage. More
generally, this produces a facility for named values, or variables that are
not objects. Applications include displacing legacy value-like macros and
introducing data-like class interfaces without impacting layout.
>> =E2=80=93=E2=80=93=E2=80=93
>>
>> http://bit.ly/1qTSBiP
>>
>> Please let me know if you find anything inspiring, bewildering, or
nauseating.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--bcaec5014c1d6f488c05030ae916
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On 14 Sep 2014 10:50, "Sean Middleditch" <<a hr=
ef=3D"mailto:sean.middleditch@gmail.com">sean.middleditch@gmail.com</a>>=
wrote:<br>
><br>
> The example at the end of 2.3 is missing the `inline` keyword I think.=
<br>
><br>
> A larger question: how much of this facility can be emulated today usi=
ng variable templates? Can you have inline variable templates? Would you ev=
er want/need to?</p>
<p dir=3D"ltr">I would expect the answers to be exactly the same as for fun=
ction templates: you can make a variable template inline, but it has (almos=
t) no semantic effect. Likewise, making a variable template explicit specia=
lization inline would allow it to be defined in a header.</p>
<p dir=3D"ltr">> On Sunday, September 14, 2014 1:59:02 AM UTC-7, David K=
rauss wrote:<br>
>><br>
>> Hi all, it=E2=80=99s proposal time again!<br>
>><br>
>> Abstract:<br>
>> =E2=80=93=E2=80=93=E2=80=93<br>
>> Inline functions have favorable behavior for some kinds of object-=
like entities. Often, users are encouraged to use them to wrap global varia=
bles. This=C2=A0has long been the status quo, despite the unnatural boilerp=
late. Also, it does not work with=C2=A0constexpr, leaving a gap in the lang=
uage. This proposal=C2=A0defines the=C2=A0inline=C2=A0specifier on variable=
definitions to indicate semantics similar to inline function evaluation an=
d linkage. More generally, this=C2=A0produces a facility for named values, =
or variables that are not objects. Applications include displacing legacy v=
alue-like macros and introducing data-like class interfaces without impacti=
ng layout.<br>
>> =E2=80=93=E2=80=93=E2=80=93<br>
>><br>
>> <a href=3D"http://bit.ly/1qTSBiP">http://bit.ly/1qTSBiP</a><br>
>><br>
>> Please let me know if you find anything inspiring, bewildering, or=
nauseating.<br>
><br>
> -- <br>
><br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec5014c1d6f488c05030ae916--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 14 Sep 2014 20:45:01 +0200
Raw View
--001a11c3c5a076eda805030aeaa6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I was thinking about this a little.
Consider this slightly different design:
Introduce a new kind of entity called a *named expression*, and a new
keyword *exprname*.
A named expression declaration is of the form:
*exprname* identifier =3D expression;
for example:
*exprname* t =3D a + b + c;
Named expressions can be used through a normal id-expression, bound via the
usual name lookup rules:
f(t);
Named expressions are specified as syntactic transformation on lambdas. A
named expression declaration *exprname N =3D E* is accompanied by a
compiler-generated lambda definition:
auto __unique_prefix_N =3D [&]{ return E; };
so the earlier example becomes:
auto __unique_prefix_t =3D [&]{ return a + b + c; }
where the __unique_prefix is some sequence of characters that does not
otherwise appear in the program.
An id-expression *N* that names a named expression is identical (by
definition) to a call to that synthetic lambda:
__unique_prefix_N()
so our earlier example becomes:
f(__unique_prefix_t());
Not sure if this is better or worse than your design, just thought I would
mention it. I get the feeling that introducing a new kind of entity is the
better route, I think just adding an inline keyword to existing variable
declarations is too confusing.
On Sun, Sep 14, 2014 at 7:50 PM, Sean Middleditch <
sean.middleditch@gmail.com> wrote:
> The example at the end of 2.3 is missing the `inline` keyword I think.
>
> A larger question: how much of this facility can be emulated today using
> variable templates? Can you have inline variable templates? Would you eve=
r
> want/need to?
>
>
> On Sunday, September 14, 2014 1:59:02 AM UTC-7, David Krauss wrote:
>>
>> Hi all, it=E2=80=99s proposal time again!
>>
>> Abstract:
>> =E2=80=93=E2=80=93=E2=80=93
>> Inline functions have favorable behavior for some kinds of object-like
>> entities. Often, users are encouraged to use them to wrap global variabl=
es.
>> This has long been the status quo, despite the unnatural boilerplate. Al=
so,
>> it does not work with constexpr, leaving a gap in the language. This
>> proposal defines the inline specifier on variable definitions to indicat=
e
>> semantics similar to inline function evaluation and linkage. More
>> generally, this produces a facility for named values, or variables that =
are
>> not objects. Applications include displacing legacy value-like macros an=
d
>> introducing data-like class interfaces without impacting layout.
>> =E2=80=93=E2=80=93=E2=80=93
>>
>> http://bit.ly/1qTSBiP
>>
>> Please let me know if you find anything inspiring, bewildering, or
>> nauseating.
>>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c3c5a076eda805030aeaa6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I was thinking about this a little.<div><br></div><div>Con=
sider this slightly different design:</div><div><br></div><div>Introduce a =
new kind of entity called a <i>named expression</i>, and a new keyword <b>e=
xprname</b>.</div><div><br></div><div>A named expression declaration is of =
the form:</div><div><br></div><div>=C2=A0 =C2=A0 <b>exprname</b> identifier=
=3D expression;</div><div><br></div><div>for example:</div><div><br></div>=
<div>=C2=A0 =C2=A0 <b>exprname</b> t =3D a + b + c;</div><div><br></div><di=
v>Named expressions can be used through a normal id-expression, bound via t=
he usual name lookup rules:</div><div><br></div><div>=C2=A0 =C2=A0f(t);</di=
v><div><br></div><div>Named expressions are specified as syntactic transfor=
mation on lambdas. =C2=A0A named expression declaration <b>exprname N =3D E=
</b> is accompanied by a compiler-generated lambda definition:</div><div><b=
r></div><div>=C2=A0 =C2=A0 auto __unique_prefix_N =3D [&]{ return E; };=
</div><div><br></div><div>so the earlier example becomes:</div><div><br></d=
iv><div>=C2=A0 =C2=A0 auto __unique_prefix_t =3D [&]{ return a + b + c;=
}</div><div><br></div><div>where the __unique_prefix is some sequence of c=
haracters that does not otherwise appear in the program.</div><div><br></di=
v><div>An id-expression <b>N</b> that names a named expression is identical=
(by definition) to a call to that synthetic lambda:</div><div><br></div><d=
iv>=C2=A0 =C2=A0__unique_prefix_N()</div><div><br></div><div>so our earlier=
example becomes:</div><div><br></div><div>=C2=A0 =C2=A0f(__unique_prefix_t=
());</div><div><br></div><div>Not sure if this is better or worse than your=
design, just thought I would mention it. =C2=A0I get the feeling that intr=
oducing a new kind of entity is the better route, I think just adding an in=
line keyword to existing variable declarations is too confusing.</div><div>=
<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Sun, Sep 14, 2014 at 7:50 PM, Sean Middleditch <span dir=3D"ltr"><<a h=
ref=3D"mailto:sean.middleditch@gmail.com" target=3D"_blank">sean.middleditc=
h@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">The example at the end of 2.3 is missing the `inline` keyword I t=
hink.<div><br></div><div>A larger question: how much of this facility can b=
e emulated today using variable templates? Can you have inline variable tem=
plates? Would you ever want/need to?<div><div class=3D"h5"><br><br>On Sunda=
y, September 14, 2014 1:59:02 AM UTC-7, David Krauss wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word">Hi all, it=E2=
=80=99s proposal time again!<div><br></div><div>Abstract:</div><div>=E2=80=
=93=E2=80=93=E2=80=93</div><div>Inline functions have favorable behavior fo=
r some kinds of object-like entities. Often, users are encouraged to use th=
em to wrap global variables. This=C2=A0has long been the status quo, despit=
e the unnatural boilerplate. Also, it does not work with=C2=A0constexpr, le=
aving a gap in the language. This proposal=C2=A0defines the=C2=A0inline=C2=
=A0specifier on variable definitions to indicate semantics similar to inlin=
e function evaluation and linkage. More generally, this=C2=A0produces a fac=
ility for named values, or variables that are not objects. Applications inc=
lude displacing legacy value-like macros and introducing data-like class in=
terfaces without impacting layout.<br>=E2=80=93=E2=80=93=E2=80=93</div><div=
><br></div><div><a href=3D"http://bit.ly/1qTSBiP" target=3D"_blank"><span>h=
ttp://</span>bit.ly/1qTSBiP</a></div><div><br></div><div>Please let me know=
if you find anything inspiring, bewildering, or nauseating.</div></div></b=
lockquote></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c3c5a076eda805030aeaa6--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 14 Sep 2014 12:38:38 -0700
Raw View
--bcaec51a70a2362cc205030baa89
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 14 Sep 2014 11:44, "Richard Smith" <richard@metafoo.co.uk> wrote:
>
> On 14 Sep 2014 10:50, "Sean Middleditch" <sean.middleditch@gmail.com>
wrote:
> >
> > The example at the end of 2.3 is missing the `inline` keyword I think.
> >
> > A larger question: how much of this facility can be emulated today
using variable templates? Can you have inline variable templates? Would you
ever want/need to?
>
> I would expect the answers to be exactly the same as for function
templates: you can make a variable template inline, but it has (almost) no
semantic effect. Likewise, making a variable template explicit
specialization inline would allow it to be defined in a header.
.... sorry, should actually read the proposal before assuming it does the
"obvious thing". I think this is a suboptimal syntax for what you're
proposing. The "natural" (IMO) fit for the language would be
using identifier =3D expression;
An inline variable would "naturally" be one for which multiple definitions
are permitted and merged by the ODR (which is an independently valuable
feature that I hope to get into c++17).
> > On Sunday, September 14, 2014 1:59:02 AM UTC-7, David Krauss wrote:
> >>
> >> Hi all, it=E2=80=99s proposal time again!
> >>
> >> Abstract:
> >> =E2=80=93=E2=80=93=E2=80=93
> >> Inline functions have favorable behavior for some kinds of object-like
entities. Often, users are encouraged to use them to wrap global variables.
This has long been the status quo, despite the unnatural boilerplate. Also,
it does not work with constexpr, leaving a gap in the language. This
proposal defines the inline specifier on variable definitions to indicate
semantics similar to inline function evaluation and linkage. More
generally, this produces a facility for named values, or variables that are
not objects. Applications include displacing legacy value-like macros and
introducing data-like class interfaces without impacting layout.
> >> =E2=80=93=E2=80=93=E2=80=93
> >>
> >> http://bit.ly/1qTSBiP
> >>
> >> Please let me know if you find anything inspiring, bewildering, or
nauseating.
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send
an email to std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--bcaec51a70a2362cc205030baa89
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On 14 Sep 2014 11:44, "Richard Smith" <<a href=
=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
><br>
> On 14 Sep 2014 10:50, "Sean Middleditch" <<a href=3D"mail=
to:sean.middleditch@gmail.com">sean.middleditch@gmail.com</a>> wrote:<br=
>
> ><br>
> > The example at the end of 2.3 is missing the `inline` keyword I t=
hink.<br>
> ><br>
> > A larger question: how much of this facility can be emulated toda=
y using variable templates? Can you have inline variable templates? Would y=
ou ever want/need to?<br>
><br>
> I would expect the answers to be exactly the same as for function temp=
lates: you can make a variable template inline, but it has (almost) no sema=
ntic effect. Likewise, making a variable template explicit specialization i=
nline would allow it to be defined in a header.</p>
<p dir=3D"ltr">... sorry, should actually read the proposal before assuming=
it does the "obvious thing". I think this is a suboptimal syntax=
for what you're proposing. The "natural" (IMO) fit for the l=
anguage would be</p>
<p dir=3D"ltr">=C2=A0 using identifier =3D expression;</p>
<p dir=3D"ltr">An inline variable would "naturally" be one for wh=
ich multiple definitions are permitted and merged by the ODR (which is an i=
ndependently valuable feature that I hope to get into c++17).</p>
<p dir=3D"ltr">> > On Sunday, September 14, 2014 1:59:02 AM UTC-7, Da=
vid Krauss wrote:<br>
> >><br>
> >> Hi all, it=E2=80=99s proposal time again!<br>
> >><br>
> >> Abstract:<br>
> >> =E2=80=93=E2=80=93=E2=80=93<br>
> >> Inline functions have favorable behavior for some kinds of ob=
ject-like entities. Often, users are encouraged to use them to wrap global =
variables. This=C2=A0has long been the status quo, despite the unnatural bo=
ilerplate. Also, it does not work with=C2=A0constexpr, leaving a gap in the=
language. This proposal=C2=A0defines the=C2=A0inline=C2=A0specifier on var=
iable definitions to indicate semantics similar to inline function evaluati=
on and linkage. More generally, this=C2=A0produces a facility for named val=
ues, or variables that are not objects. Applications include displacing leg=
acy value-like macros and introducing data-like class interfaces without im=
pacting layout.<br>
> >> =E2=80=93=E2=80=93=E2=80=93<br>
> >><br>
> >> <a href=3D"http://bit.ly/1qTSBiP">http://bit.ly/1qTSBiP</a><b=
r>
> >><br>
> >> Please let me know if you find anything inspiring, bewilderin=
g, or nauseating.<br>
> ><br>
> > -- <br>
> ><br>
> > --- <br>
> > You received this message because you are subscribed to the Googl=
e Groups "ISO C++ Standard - Future Proposals" group.<br>
> > To unsubscribe from this group and stop receiving emails from it,=
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"=
>std-proposals+unsubscribe@isocpp.org</a>.<br>
> > To post to this group, send email to <a href=3D"mailto:std-propos=
als@isocpp.org">std-proposals@isocpp.org</a>.<br>
> > Visit this group at <a href=3D"http://groups.google.com/a/isocpp.=
org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-p=
roposals/</a>.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec51a70a2362cc205030baa89--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Sun, 14 Sep 2014 22:07:59 +0200
Raw View
--001a11c2e39627937605030c1387
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Sep 14, 2014 at 8:45 PM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:
> I was thinking about this a little.
>
> Consider this slightly different design:
>
> Introduce a new kind of entity called a *named expression*, and a new
> keyword *exprname*.
>
> A named expression declaration is of the form:
>
> *exprname* identifier =3D expression;
>
> for example:
>
> *exprname* t =3D a + b + c;
>
> Named expressions can be used through a normal id-expression, bound via
> the usual name lookup rules:
>
> f(t);
>
> Named expressions are specified as syntactic transformation on lambdas. =
A
> named expression declaration *exprname N =3D E* is accompanied by a
> compiler-generated lambda definition:
>
> auto __unique_prefix_N =3D [&]{ return E; };
>
> so the earlier example becomes:
>
> auto __unique_prefix_t =3D [&]{ return a + b + c; }
>
> where the __unique_prefix is some sequence of characters that does not
> otherwise appear in the program.
>
> An id-expression *N* that names a named expression is identical (by
> definition) to a call to that synthetic lambda:
>
> __unique_prefix_N()
>
> so our earlier example becomes:
>
> f(__unique_prefix_t());
>
> Not sure if this is better or worse than your design, just thought I woul=
d
> mention it. I get the feeling that introducing a new kind of entity is t=
he
> better route, I think just adding an inline keyword to existing variable
> declarations is too confusing.
>
>
I can't find it again but I believe someone did post something similar on
these forums or in the reflection group forum.
>
> On Sun, Sep 14, 2014 at 7:50 PM, Sean Middleditch <
> sean.middleditch@gmail.com> wrote:
>
>> The example at the end of 2.3 is missing the `inline` keyword I think.
>>
>> A larger question: how much of this facility can be emulated today using
>> variable templates? Can you have inline variable templates? Would you ev=
er
>> want/need to?
>>
>>
>> On Sunday, September 14, 2014 1:59:02 AM UTC-7, David Krauss wrote:
>>>
>>> Hi all, it=E2=80=99s proposal time again!
>>>
>>> Abstract:
>>> =E2=80=93=E2=80=93=E2=80=93
>>> Inline functions have favorable behavior for some kinds of object-like
>>> entities. Often, users are encouraged to use them to wrap global variab=
les.
>>> This has long been the status quo, despite the unnatural boilerplate. A=
lso,
>>> it does not work with constexpr, leaving a gap in the language. This
>>> proposal defines the inline specifier on variable definitions to indica=
te
>>> semantics similar to inline function evaluation and linkage. More
>>> generally, this produces a facility for named values, or variables that=
are
>>> not objects. Applications include displacing legacy value-like macros a=
nd
>>> introducing data-like class interfaces without impacting layout.
>>> =E2=80=93=E2=80=93=E2=80=93
>>>
>>> http://bit.ly/1qTSBiP
>>>
>>> Please let me know if you find anything inspiring, bewildering, or
>>> nauseating.
>>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2e39627937605030c1387
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Sep 14, 2014 at 8:45 PM, Andrew Tomazos <span dir=3D"ltr"><<=
a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@g=
mail.com</a>></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 was thinking about this a little.<div><br></div><div>Consider th=
is slightly different design:</div><div><br></div><div>Introduce a new kind=
of entity called a <i>named expression</i>, and a new keyword <b>exprname<=
/b>.</div><div><br></div><div>A named expression declaration is of the form=
:</div><div><br></div><div>=C2=A0 =C2=A0 <b>exprname</b> identifier =3D exp=
ression;</div><div><br></div><div>for example:</div><div><br></div><div>=C2=
=A0 =C2=A0 <b>exprname</b> t =3D a + b + c;</div><div><br></div><div>Named =
expressions can be used through a normal id-expression, bound via the usual=
name lookup rules:</div><div><br></div><div>=C2=A0 =C2=A0f(t);</div><div><=
br></div><div>Named expressions are specified as syntactic transformation o=
n lambdas. =C2=A0A named expression declaration <b>exprname N =3D E</b> is =
accompanied by a compiler-generated lambda definition:</div><div><br></div>=
<div>=C2=A0 =C2=A0 auto __unique_prefix_N =3D [&]{ return E; };</div><d=
iv><br></div><div>so the earlier example becomes:</div><div><br></div><div>=
=C2=A0 =C2=A0 auto __unique_prefix_t =3D [&]{ return a + b + c; }</div>=
<div><br></div><div>where the __unique_prefix is some sequence of character=
s that does not otherwise appear in the program.</div><div><br></div><div>A=
n id-expression <b>N</b> that names a named expression is identical (by def=
inition) to a call to that synthetic lambda:</div><div><br></div><div>=C2=
=A0 =C2=A0__unique_prefix_N()</div><div><br></div><div>so our earlier examp=
le becomes:</div><div><br></div><div>=C2=A0 =C2=A0f(__unique_prefix_t());</=
div><div><br></div><div>Not sure if this is better or worse than your desig=
n, just thought I would mention it. =C2=A0I get the feeling that introducin=
g a new kind of entity is the better route, I think just adding an inline k=
eyword to existing variable declarations is too confusing.</div><div><br></=
div></div></blockquote><div><br></div><div>I can't find it again but I =
believe someone did post something similar on these forums or in the reflec=
tion group forum.</div><div><br></div><div><br></div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div></div></div><div class=3D"H=
OEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Sun, Sep 14, 2014 at 7:50 PM, Sean Middleditch <span dir=3D"ltr"=
><<a href=3D"mailto:sean.middleditch@gmail.com" target=3D"_blank">sean.m=
iddleditch@gmail.com</a>></span> wrote:<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">The example at the end of 2.3 is missing the `inline` ke=
yword I think.<div><br></div><div>A larger question: how much of this facil=
ity can be emulated today using variable templates? Can you have inline var=
iable templates? Would you ever want/need to?<div><div><br><br>On Sunday, S=
eptember 14, 2014 1:59:02 AM UTC-7, David Krauss wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div style=3D"word-wrap:break-word">Hi all, it=E2=80=99=
s proposal time again!<div><br></div><div>Abstract:</div><div>=E2=80=93=E2=
=80=93=E2=80=93</div><div>Inline functions have favorable behavior for some=
kinds of object-like entities. Often, users are encouraged to use them to =
wrap global variables. This=C2=A0has long been the status quo, despite the =
unnatural boilerplate. Also, it does not work with=C2=A0constexpr, leaving =
a gap in the language. This proposal=C2=A0defines the=C2=A0inline=C2=A0spec=
ifier on variable definitions to indicate semantics similar to inline funct=
ion evaluation and linkage. More generally, this=C2=A0produces a facility f=
or named values, or variables that are not objects. Applications include di=
splacing legacy value-like macros and introducing data-like class interface=
s without impacting layout.<br>=E2=80=93=E2=80=93=E2=80=93</div><div><br></=
div><div><a href=3D"http://bit.ly/1qTSBiP" target=3D"_blank"><span>http://<=
/span>bit.ly/1qTSBiP</a></div><div><br></div><div>Please let me know if you=
find anything inspiring, bewildering, or nauseating.</div></div></blockquo=
te></div></div></div></div><div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2e39627937605030c1387--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 14 Sep 2014 23:09:26 +0200
Raw View
--001a11c31858f0673105030ceeb4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Sep 14, 2014 at 9:38 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
> On 14 Sep 2014 11:44, "Richard Smith" <richard@metafoo.co.uk> wrote:
> >
> > On 14 Sep 2014 10:50, "Sean Middleditch" <sean.middleditch@gmail.com>
> wrote:
> > >
> > > The example at the end of 2.3 is missing the `inline` keyword I think=
..
> > >
> > > A larger question: how much of this facility can be emulated today
> using variable templates? Can you have inline variable templates? Would y=
ou
> ever want/need to?
> >
> > I would expect the answers to be exactly the same as for function
> templates: you can make a variable template inline, but it has (almost) n=
o
> semantic effect. Likewise, making a variable template explicit
> specialization inline would allow it to be defined in a header.
>
> ... sorry, should actually read the proposal before assuming it does the
> "obvious thing". I think this is a suboptimal syntax for what you're
> proposing. The "natural" (IMO) fit for the language would be
>
> using identifier =3D expression;
>
I thought about that, but I think introducing a new keyword is better,
because the reader can distinguish it quickly from an alias declaration:
using x =3D /* ... */; // oh, x is a type
exprname y =3D /* ... */; // oh, y is a named expression
without having to mentally analyze the RHS to disambiguate.
If we made typename another keyword that could lead an alias declaration it
would look even better:
typename x =3D /* ... */; // oh, x is a type
exprname y =3D /* ... */; // oh, y is a named expression
or perhaps:
typedef x =3D /* ... */; // oh, x is a type
exprdef y =3D /* ... */; // oh, y is a named expression
But I'm not sure if these later four would parse easily with the existing
grammar.
An inline variable would "naturally" be one for which multiple definitions
> are permitted and merged by the ODR (which is an independently valuable
> feature that I hope to get into c++17).
>
> > > On Sunday, September 14, 2014 1:59:02 AM UTC-7, David Krauss wrote:
> > >>
> > >> Hi all, it=E2=80=99s proposal time again!
> > >>
> > >> Abstract:
> > >> =E2=80=93=E2=80=93=E2=80=93
> > >> Inline functions have favorable behavior for some kinds of
> object-like entities. Often, users are encouraged to use them to wrap
> global variables. This has long been the status quo, despite the unnatura=
l
> boilerplate. Also, it does not work with constexpr, leaving a gap in the
> language. This proposal defines the inline specifier on variable
> definitions to indicate semantics similar to inline function evaluation a=
nd
> linkage. More generally, this produces a facility for named values, or
> variables that are not objects. Applications include displacing legacy
> value-like macros and introducing data-like class interfaces without
> impacting layout.
> > >> =E2=80=93=E2=80=93=E2=80=93
> > >>
> > >> http://bit.ly/1qTSBiP
> > >>
> > >> Please let me know if you find anything inspiring, bewildering, or
> nauseating.
> > >
> > > --
> > >
> > > ---
> > > 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, sen=
d
> an email to std-proposals+unsubscribe@isocpp.org.
> > > To post to this group, send email to std-proposals@isocpp.org.
> > > Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c31858f0673105030ceeb4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Sep 14, 2014 at 9:38 PM, Richard Smith <span dir=3D"ltr"><<a=
href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co=
..uk</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><span class=3D""><p dir=3D"lt=
r">On 14 Sep 2014 11:44, "Richard Smith" <<a href=3D"mailto:ri=
chard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>> wrote:=
<br>
><br>
> On 14 Sep 2014 10:50, "Sean Middleditch" <<a href=3D"mail=
to:sean.middleditch@gmail.com" target=3D"_blank">sean.middleditch@gmail.com=
</a>> wrote:<br>
> ><br>
> > The example at the end of 2.3 is missing the `inline` keyword I t=
hink.<br>
> ><br>
> > A larger question: how much of this facility can be emulated toda=
y using variable templates? Can you have inline variable templates? Would y=
ou ever want/need to?<br>
><br>
> I would expect the answers to be exactly the same as for function temp=
lates: you can make a variable template inline, but it has (almost) no sema=
ntic effect. Likewise, making a variable template explicit specialization i=
nline would allow it to be defined in a header.</p>
</span><p dir=3D"ltr">... sorry, should actually read the proposal before a=
ssuming it does the "obvious thing". I think this is a suboptimal=
syntax for what you're proposing. The "natural" (IMO) fit fo=
r the language would be</p>
<p dir=3D"ltr">=C2=A0 using identifier =3D expression;</p></blockquote><div=
>I thought about that, but I think introducing a new keyword is better, bec=
ause the reader can distinguish it quickly from an alias declaration:</div>=
<div><br></div><div>=C2=A0 =C2=A0 using x =3D /* ... */; // oh, x is a type=
</div><div>=C2=A0 =C2=A0 exprname y =3D /* ... */; // oh, y is a named expr=
ession</div><div><br></div><div>without having to mentally analyze the RHS =
to disambiguate.</div><div><br></div><div>If we made typename another keywo=
rd that could lead an alias declaration it would look even better:</div><di=
v><br></div><div><div>=C2=A0 =C2=A0 typename x =3D /* ... */; // oh, x is a=
type</div><div>=C2=A0 =C2=A0 exprname y =3D /* ... */; // oh, y is a named=
expression</div></div><div><br></div><div>or perhaps:</div><div><br></div>=
<div><div><div>=C2=A0 =C2=A0 typedef x =3D /* ... */; // oh, x is a type</d=
iv><div>=C2=A0 =C2=A0 exprdef y =3D /* ... */; // oh, y is a named expressi=
on</div></div></div><div><br></div><div>But I'm not sure if these later=
four would parse easily with the existing grammar.</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">
<p dir=3D"ltr">An inline variable would "naturally" be one for wh=
ich multiple definitions are permitted and merged by the ODR (which is an i=
ndependently valuable feature that I hope to get into c++17).</p><div class=
=3D""><div class=3D"h5">
<p dir=3D"ltr">> > On Sunday, September 14, 2014 1:59:02 AM UTC-7, Da=
vid Krauss wrote:<br>
> >><br>
> >> Hi all, it=E2=80=99s proposal time again!<br>
> >><br>
> >> Abstract:<br>
> >> =E2=80=93=E2=80=93=E2=80=93<br>
> >> Inline functions have favorable behavior for some kinds of ob=
ject-like entities. Often, users are encouraged to use them to wrap global =
variables. This=C2=A0has long been the status quo, despite the unnatural bo=
ilerplate. Also, it does not work with=C2=A0constexpr, leaving a gap in the=
language. This proposal=C2=A0defines the=C2=A0inline=C2=A0specifier on var=
iable definitions to indicate semantics similar to inline function evaluati=
on and linkage. More generally, this=C2=A0produces a facility for named val=
ues, or variables that are not objects. Applications include displacing leg=
acy value-like macros and introducing data-like class interfaces without im=
pacting layout.<br>
> >> =E2=80=93=E2=80=93=E2=80=93<br>
> >><br>
> >> <a href=3D"http://bit.ly/1qTSBiP" target=3D"_blank">http://bi=
t.ly/1qTSBiP</a><br>
> >><br>
> >> Please let me know if you find anything inspiring, bewilderin=
g, or nauseating.<br>
> ><br>
> > -- <br>
> ><br>
> > --- <br>
> > You received this message because you are subscribed to the Googl=
e Groups "ISO C++ Standard - Future Proposals" group.<br>
> > To unsubscribe from this group and stop receiving emails from it,=
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@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-propos=
als@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
> > Visit this group at <a href=3D"http://groups.google.com/a/isocpp.=
org/group/std-proposals/" target=3D"_blank">http://groups.google.com/a/isoc=
pp.org/group/std-proposals/</a>.<br>
</p>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c31858f0673105030ceeb4--
.
Author: Sean Middleditch <sean@middleditch.us>
Date: Sun, 14 Sep 2014 15:49:02 -0700
Raw View
On Sun, Sep 14, 2014 at 2:09 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>
>
> On Sun, Sep 14, 2014 at 9:38 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
>
> I thought about that, but I think introducing a new keyword is better,
It's also a bit better when you remember that the value aliases
(constexpr) and corresponding syntax for variable templates also use a
different keyword rather than `using`.
> because the reader can distinguish it quickly from an alias declaration:
>
> using x = /* ... */; // oh, x is a type
> exprname y = /* ... */; // oh, y is a named expression
constexpr z = /* ... */; // oh, z is a (constant-expression) value
Though that makes me think `nameexpr` or `lambdaexpr` or something
might be more consistent with the language. The bike shed should be
mauve!
--
Sean Middleditch
http://seanmiddleditch.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 15 Sep 2014 07:07:27 +0800
Raw View
--Apple-Mail=_494A07F4-5009-4820-8331-A4BF6F273D09
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Urgh, time zones. Here's a combo reply.
On 2014-09-15, at 1:50 AM, Sean Middleditch <sean.middleditch@gmail.com> wr=
ote:
> The example at the end of 2.3 is missing the `inline` keyword I think.
Yes, thanks!
> A larger question: how much of this facility can be emulated today using =
variable templates?
I suppose variable templates avoid the constexpr linkage issue, because a t=
emplate has its own external linkage by default, which specializations cann=
ot override.
But I would consider that a workaround, not emulation, because a variable t=
emplate specialization must always be named with a template argument list, =
even an empty one ("my_var<>"). You do have a point, though; I meant to men=
tion that all C++14 implementations already have the linker machinery to pr=
ovide common storage to constexpr inline variables.
> Can you have inline variable templates? Would you ever want/need to?
Sure, why not? It would be evaluated at each use. I can't think of a use ca=
se, but a constexpr inline variable template would behave mostly the same a=
s a non-inline one, except that the implementation is notionally allowed to=
perform evaluation per use. I think the inline keyword should be harmless =
there.
On 2014-09-15, at 2:44 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> Likewise, making a variable template explicit specialization inline would=
allow it to be defined in a header.
>=20
Perhaps I still need my morning coffee, but I think they already can.
On 2014-09-15, at 2:45 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> Introduce a new kind of entity called a named expression, and a new keywo=
rd exprname.
>=20
> Not sure if this is better or worse than your design, just thought I woul=
d mention it. I get the feeling that introducing a new kind of entity is t=
he better route, I think just adding an inline keyword to existing variable=
declarations is too confusing.
You've only introduced syntactic sugar for lambdas. The process of entering=
and returning from the function is interposed into evaluation, which my pr=
oposal goes to lengths to avoid.
I think the inline syntax is not confusing because the definition is substi=
tuted just-about-literally inline for each use. It works mostly like an inl=
ine function, but purely with expression-value semantics.
Also, linkage is the same as for an inline function, so applying the same p=
roperty to both saves a bit of specification. I'd really be going out of my=
way to not use the inline keyword.
On 2014-09-15, at 3:38 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> ... sorry, should actually read the proposal before assuming it does the =
"obvious thing". I think this is a suboptimal syntax for what you're propos=
ing. The "natural" (IMO) fit for the language would be
>=20
> using identifier =3D expression;
>=20
Yes, I mentioned you in the acknowledgements for this idea but didn't menti=
on the idea :P . Perhaps I should?
This syntax always lacks type specificity. Mine allows perfect deduction wi=
th decltype(auto), or guaranteed evaluation to value or reference semantics=
with auto or auto && respectively, or in the usual case encourages a type =
to be specified.
> An inline variable would "naturally" be one for which multiple definition=
s are permitted and merged by the ODR (which is an independently valuable f=
eature that I hope to get into c++17).
>=20
This is already true of my proposal. I mentioned the ODR and linkage, but p=
erhaps I should clarify the interactions better.
Thanks all for the feedback!
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_494A07F4-5009-4820-8331-A4BF6F273D09
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">Urgh, time zones. Here=
’s a combo reply.<div><br></div><div><br><div><div>On 2014–09&n=
dash;15, at 1:50 AM, Sean Middleditch <<a href=3D"mailto:sean.middleditc=
h@gmail.com">sean.middleditch@gmail.com</a>> wrote:</div><br class=3D"Ap=
ple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">The exa=
mple at the end of 2.3 is missing the `inline` keyword I think.</div></bloc=
kquote><div><br></div>Yes, thanks!</div><div><br><blockquote type=3D"cite">=
<div dir=3D"ltr"><div>A larger question: how much of this facility can be e=
mulated today using variable templates? </div></div></blockquote><div><br><=
/div><div>I suppose variable templates avoid the constexpr linkage issue, b=
ecause a template has its own external linkage by default, which specializa=
tions cannot override.</div><div><br></div><div>But I would consider that a=
workaround, not emulation, because a variable template specialization must=
always be named with a template argument list, even an empty one (“<=
font face=3D"Courier">my_var<></font>”). You do have a point, t=
hough; I meant to mention that all C++14 implementations already have the l=
inker machinery to provide common storage to <font face=3D"Courier">constex=
pr inline</font> variables.</div><br><blockquote type=3D"cite"><div dir=3D"=
ltr"><div>Can you have inline variable templates? Would you ever want/need =
to?</div></div></blockquote><div><br></div><div>Sure, why not? It would be =
evaluated at each use. I can’t think of a use case, but a <font face=
=3D"Courier">constexpr inline</font> variable template would behave mostly =
the same as a non-inline one, except that the implementation is notionally =
allowed to perform evaluation per use. I think the inline keyword should be=
harmless there.</div><div><br></div><div><br></div><div><div>On 2014&ndash=
;09–15, at 2:44 AM, Richard Smith <<a href=3D"mailto:richard@metaf=
oo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><blockquote type=3D"cit=
e"><p dir=3D"ltr">Likewise, making a variable template explicit specializat=
ion inline would allow it to be defined in a header.</p></blockquote><div>P=
erhaps I still need my morning coffee, but I think they already can.</div><=
div><br></div></div></div></div><div><br></div><div><div>On 2014–09&n=
dash;15, at 2:45 AM, Andrew Tomazos <<a href=3D"mailto:andrewtomazos@gma=
il.com">andrewtomazos@gmail.com</a>> wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>Introduce =
a new kind of entity called a <i>named expression</i>, and a new keywo=
rd <b>exprname</b>.</div><div><br></div><div>Not sure if this is bette=
r or worse than your design, just thought I would mention it. I get t=
he feeling that introducing a new kind of entity is the better route, I thi=
nk just adding an inline keyword to existing variable declarations is too c=
onfusing.</div></div></blockquote></div><div><div dir=3D"ltr"><div><br></di=
v><div>You’ve only introduced syntactic sugar for lambdas. The proces=
s of entering and returning from the function is interposed into evaluation=
, which my proposal goes to lengths to avoid.</div><div><br></div><div>I th=
ink the <font face=3D"Courier">inline</font> syntax is not confusing becaus=
e the definition is substituted just-about-literally inline for each use. I=
t works mostly like an <font face=3D"Courier">inline</font> function, but p=
urely with expression-value semantics.</div><div><br></div><div>Also, linka=
ge is the same as for an inline function, so applying the same property to =
both saves a bit of specification. I’d really be going out of my way =
to <i>not</i> use the <font face=3D"Courier">inline</font> keyword.</div><d=
iv><br></div><div><br></div><div><div>On 2014–09–15, at 3:38 AM=
, Richard Smith <<a href=3D"mailto:richard@metafoo.co.uk">richard@metafo=
o.co.uk</a>> wrote:</div><br class=3D"Apple-interchange-newline"><blockq=
uote type=3D"cite"><p dir=3D"ltr">... sorry, should actually read the propo=
sal before assuming it does the "obvious thing". I think this is a suboptim=
al syntax for what you're proposing. The "natural" (IMO) fit for the langua=
ge would be</p><p dir=3D"ltr"> using identifier =3D expression;</p></=
blockquote><div>Yes, I mentioned you in the acknowledgements for this idea =
but didn’t mention the idea :P . Perhaps I should?</div><div><br></di=
v><div>This syntax always lacks type specificity. Mine allows perfect deduc=
tion with <font face=3D"Courier">decltype(auto)</font>, or guaranteed evalu=
ation to value or reference semantics with <font face=3D"Courier">auto</fon=
t> or <font face=3D"Courier">auto &&</font> respectively, or in the=
usual case encourages a type to be specified.</div><blockquote type=3D"cit=
e"><p dir=3D"ltr">An inline variable would "naturally" be one for which mul=
tiple definitions are permitted and merged by the ODR (which is an independ=
ently valuable feature that I hope to get into c++17).</p></blockquote></di=
v><div><p dir=3D"ltr">This is already true of my proposal. I mentioned the =
ODR and linkage, but perhaps I should clarify the interactions better.</p><=
/div><div><br></div><div>Thanks all for the feedback!</div><div><br></div><=
/div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_494A07F4-5009-4820-8331-A4BF6F273D09--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 15 Sep 2014 01:46:30 +0200
Raw View
--089e013d1c46a5c24f05030f208d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Sep 15, 2014 at 1:07 AM, David Krauss <potswa@gmail.com> wrote:
> You=E2=80=99ve only introduced syntactic sugar for lambdas. The process o=
f
> entering and returning from the function is interposed into evaluation,
> which my proposal goes to lengths to avoid.
>
I don't understand. What part of the "process of entering and returning
from the function" can't be elided under as-if? As far as I can see the
implementation is free to "inline" the named expression in the most
efficient way, as none of the surrounding machinery is observable. The
lambda translation is just for specification purposes, and shouldn't effect
the efficiency of the implementation. Unless I missed something.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e013d1c46a5c24f05030f208d
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, Sep 15, 2014 at 1:07 AM, David Krauss <span dir=3D"ltr"><<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word=
"><div><div dir=3D"ltr"><div>You=E2=80=99ve only introduced syntactic sugar=
for lambdas. The process of entering and returning from the function is in=
terposed into evaluation, which my proposal goes to lengths to avoid.</div>=
<div></div></div></div></div></blockquote></div><br></div><div class=3D"gma=
il_extra">I don't understand. =C2=A0What part of the "process of e=
ntering and returning from the function" can't be elided under as-=
if? =C2=A0As far as I can see the implementation is free to "inline&qu=
ot; the named expression in the most efficient way, as none of the surround=
ing machinery is observable. =C2=A0The lambda translation is just for speci=
fication purposes, and shouldn't effect the efficiency of the implement=
ation. =C2=A0Unless I missed something.<br></div><div class=3D"gmail_extra"=
><br></div><div class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013d1c46a5c24f05030f208d--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 15 Sep 2014 08:18:17 +0800
Raw View
--Apple-Mail=_9FD5CD57-C9F5-4EB3-84D8-9F09F79354D1
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-15, at 7:46 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Mon, Sep 15, 2014 at 1:07 AM, David Krauss <potswa@gmail.com> wrote:
> You've only introduced syntactic sugar for lambdas. The process of entering and returning from the function is interposed into evaluation, which my proposal goes to lengths to avoid.
>
> I don't understand. What part of the "process of entering and returning from the function" can't be elided under as-if?
Sequencing and the requirement of movability. Object initialization is pretty nuanced, and factory functions just don't cover all the bases.
Also the question of constexpr-ness would need to be addressed. Lambdas aren't constexpr but you would need automatic constexpr qualification.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_9FD5CD57-C9F5-4EB3-84D8-9F09F79354D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–15, at 7:46 AM, Andrew Tomazos <<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, Sep 15, 2014 at 1:=
07 AM, David Krauss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.co=
m" target=3D"_blank">potswa@gmail.com</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div style=3D"word-wrap:break-word"><div dir=3D"ltr"><di=
v>You’ve only introduced syntactic sugar for lambdas. The process of =
entering and returning from the function is interposed into evaluation, whi=
ch my proposal goes to lengths to avoid.</div><div></div></div></div></bloc=
kquote></div><br></div><div class=3D"gmail_extra">I don't understand.  =
;What part of the "process of entering and returning from the function" can=
't be elided under as-if? </div></div></blockquote><div><br></div><di=
v>Sequencing and the requirement of movability. Object initialization is pr=
etty nuanced, and factory functions just don’t cover all the bases.</=
div><div><br></div><div>Also the question of constexpr-ness would need to b=
e addressed. Lambdas aren’t constexpr but you would need automatic co=
nstexpr qualification.</div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_9FD5CD57-C9F5-4EB3-84D8-9F09F79354D1--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 15 Sep 2014 17:09:33 +0800
Raw View
--Apple-Mail=_54AB1558-3D6C-470F-A466-CEBD31AEBC0B
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-14, at 4:58 PM, David Krauss <potswa@gmail.com> wrote:
> http://bit.ly/1qTSBiP
I've posted an update with a new example, "Shared global state," and more ODR discussion.
Question: how important are references? I certainly should do my best to reference prior papers, but does the audience of such a paper as this mostly get by without links to the definitions of most standard terms?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_54AB1558-3D6C-470F-A466-CEBD31AEBC0B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–14, at 4:58 PM, David Krauss <<a href=3D"mailto:potswa@gm=
ail.com">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><meta http-equiv=3D"Content-Type" cont=
ent=3D"text/html charset=3Dwindows-1252"><div style=3D"word-wrap: break-wor=
d; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><=
a href=3D"http://bit.ly/1qTSBiP" class=3D"bitmark-shortlink"><span class=3D=
"protocol">http://</span>bit.ly/1qTSBiP</a></div></div></blockquote><br></d=
iv><div>I’ve posted an update with a new example, “Shared globa=
l state,” and more ODR discussion.</div><br><div>Question: how import=
ant are references? I certainly should do my best to reference prior papers=
, but does the audience of such a paper as this mostly get by without links=
to the definitions of most standard terms?</div><div><br></div></body></ht=
ml>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_54AB1558-3D6C-470F-A466-CEBD31AEBC0B--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 15 Sep 2014 14:37:08 -0700
Raw View
--001a113403d0d30b5e0503216f87
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Sep 14, 2014 at 2:09 PM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:
>
>
> On Sun, Sep 14, 2014 at 9:38 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
>
>> On 14 Sep 2014 11:44, "Richard Smith" <richard@metafoo.co.uk> wrote:
>> >
>> > On 14 Sep 2014 10:50, "Sean Middleditch" <sean.middleditch@gmail.com>
>> wrote:
>> > >
>> > > The example at the end of 2.3 is missing the `inline` keyword I thin=
k.
>> > >
>> > > A larger question: how much of this facility can be emulated today
>> using variable templates? Can you have inline variable templates? Would =
you
>> ever want/need to?
>> >
>> > I would expect the answers to be exactly the same as for function
>> templates: you can make a variable template inline, but it has (almost) =
no
>> semantic effect. Likewise, making a variable template explicit
>> specialization inline would allow it to be defined in a header.
>>
>> ... sorry, should actually read the proposal before assuming it does the
>> "obvious thing". I think this is a suboptimal syntax for what you're
>> proposing. The "natural" (IMO) fit for the language would be
>>
>> using identifier =3D expression;
>>
> I thought about that, but I think introducing a new keyword is better,
> because the reader can distinguish it quickly from an alias declaration:
>
> using x =3D /* ... */; // oh, x is a type
> exprname y =3D /* ... */; // oh, y is a named expression
>
> without having to mentally analyze the RHS to disambiguate.
>
Do people have problems mentally analyzing a using-declaration in order to
disambiguate it? They have this same behavior.
Take a read through N1489 (one of the key papers introducing alias
templates), in particular sections 2.2 and 2.3. While the authors didn't at
that point in time see value in the feature, they did consider extending
alias-declarations to cover other kinds of entities. In particular:
"The core of this proposal concerns itself with type name aliases, but the
notation can obviously be generalized to provide alternate spellings of
namespace-aliasing or naming set of overloaded functions (see 2.3 for
further discussion)."
The keyword 'using' was deliberately chosen to be general and not limited
to types, and there was design intent to keep the door open to future
extensions. Indeed, we've been careful to allow this in the core language
(there is no 'implicit typename' on the right hand side of an alias
declaration for this reason), and the ideas of alias-declarations naming
templates and of alias-declarations naming namespaces have both already
been mentioned in committee.
If we made typename another keyword that could lead an alias declaration it
> would look even better:
>
> typename x =3D /* ... */; // oh, x is a type
> exprname y =3D /* ... */; // oh, y is a named expression
>
> or perhaps:
>
> typedef x =3D /* ... */; // oh, x is a type
> exprdef y =3D /* ... */; // oh, y is a named expression
>
> But I'm not sure if these later four would parse easily with the existing
> grammar.
>
> An inline variable would "naturally" be one for which multiple definition=
s
>> are permitted and merged by the ODR (which is an independently valuable
>> feature that I hope to get into c++17).
>>
>> > > On Sunday, September 14, 2014 1:59:02 AM UTC-7, David Krauss wrote:
>> > >>
>> > >> Hi all, it=E2=80=99s proposal time again!
>> > >>
>> > >> Abstract:
>> > >> =E2=80=93=E2=80=93=E2=80=93
>> > >> Inline functions have favorable behavior for some kinds of
>> object-like entities. Often, users are encouraged to use them to wrap
>> global variables. This has long been the status quo, despite the unnatur=
al
>> boilerplate. Also, it does not work with constexpr, leaving a gap in the
>> language. This proposal defines the inline specifier on variable
>> definitions to indicate semantics similar to inline function evaluation =
and
>> linkage. More generally, this produces a facility for named values, or
>> variables that are not objects. Applications include displacing legacy
>> value-like macros and introducing data-like class interfaces without
>> impacting layout.
>> > >> =E2=80=93=E2=80=93=E2=80=93
>> > >>
>> > >> http://bit.ly/1qTSBiP
>> > >>
>> > >> Please let me know if you find anything inspiring, bewildering, or
>> nauseating.
>> > >
>> > > --
>> > >
>> > > ---
>> > > You received this message because you are subscribed to the Google
>> Groups "ISO C++ Standard - Future Proposals" group.
>> > > To unsubscribe from this group and stop receiving emails from it,
>> send an email to std-proposals+unsubscribe@isocpp.org.
>> > > To post to this group, send email to std-proposals@isocpp.org.
>> > > Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a113403d0d30b5e0503216f87
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, Sep 14, 2014 at 2:09 PM, Andrew Tomazos <span dir=3D"ltr"><<a href=
=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Sun, S=
ep 14, 2014 at 9:38 PM, Richard Smith <span dir=3D"ltr"><<a href=3D"mail=
to:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><span><p dir=3D"ltr">On 14 Sep 2014 11:44,=
"Richard Smith" <<a href=3D"mailto:richard@metafoo.co.uk" tar=
get=3D"_blank">richard@metafoo.co.uk</a>> wrote:<br>
><br>
> On 14 Sep 2014 10:50, "Sean Middleditch" <<a href=3D"mail=
to:sean.middleditch@gmail.com" target=3D"_blank">sean.middleditch@gmail.com=
</a>> wrote:<br>
> ><br>
> > The example at the end of 2.3 is missing the `inline` keyword I t=
hink.<br>
> ><br>
> > A larger question: how much of this facility can be emulated toda=
y using variable templates? Can you have inline variable templates? Would y=
ou ever want/need to?<br>
><br>
> I would expect the answers to be exactly the same as for function temp=
lates: you can make a variable template inline, but it has (almost) no sema=
ntic effect. Likewise, making a variable template explicit specialization i=
nline would allow it to be defined in a header.</p>
</span><p dir=3D"ltr">... sorry, should actually read the proposal before a=
ssuming it does the "obvious thing". I think this is a suboptimal=
syntax for what you're proposing. The "natural" (IMO) fit fo=
r the language would be</p>
<p dir=3D"ltr">=C2=A0 using identifier =3D expression;</p></blockquote></sp=
an><div>I thought about that, but I think introducing a new keyword is bett=
er, because the reader can distinguish it quickly from an alias declaration=
:</div><div><br></div><div>=C2=A0 =C2=A0 using x =3D /* ... */; // oh, x is=
a type</div><div>=C2=A0 =C2=A0 exprname y =3D /* ... */; // oh, y is a nam=
ed expression</div><div><br></div><div>without having to mentally analyze t=
he RHS to disambiguate.</div></div></div></div></blockquote><div><br></div>=
<div>Do people have problems mentally analyzing a using-declaration in orde=
r to disambiguate it? They have this same behavior.</div><div><br></div><di=
v>Take a read through N1489 (one of the key papers introducing alias templa=
tes), in particular sections 2.2 and 2.3. While the authors didn't at t=
hat point in time see value in the feature, they did consider extending ali=
as-declarations to cover other kinds of entities. In particular:</div><div>=
<br></div><div>"The core of this proposal concerns itself with type na=
me aliases, but the notation can obviously be generalized to provide altern=
ate spellings of namespace-aliasing or naming set of overloaded functions (=
see 2.3 for further discussion)."</div><div><br></div><div>The keyword=
'using' was deliberately chosen to be general and not limited to t=
ypes, and there was design intent to keep the door open to future extension=
s. Indeed, we've been careful to allow this in the core language (there=
is no 'implicit typename' on the right hand side of an alias decla=
ration for this reason), and the ideas of alias-declarations naming templat=
es and of alias-declarations naming namespaces have both already been menti=
oned in committee.</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv class=3D"gmail_extra"><div class=3D"gmail_quote"><div>If we made typenam=
e another keyword that could lead an alias declaration it would look even b=
etter:</div><div><br></div><div><div>=C2=A0 =C2=A0 typename x =3D /* ... */=
; // oh, x is a type</div><div>=C2=A0 =C2=A0 exprname y =3D /* ... */; // o=
h, y is a named expression</div></div><div><br></div><div>or perhaps:</div>=
<div><br></div><div><div><div>=C2=A0 =C2=A0 typedef x =3D /* ... */; // oh,=
x is a type</div><div>=C2=A0 =C2=A0 exprdef y =3D /* ... */; // oh, y is a=
named expression</div></div></div><div><br></div><div>But I'm not sure=
if these later four would parse easily with the existing grammar.</div><di=
v><div class=3D"h5"><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
<p dir=3D"ltr">An inline variable would "naturally" be one for wh=
ich multiple definitions are permitted and merged by the ODR (which is an i=
ndependently valuable feature that I hope to get into c++17).</p><div><div>
<p dir=3D"ltr">> > On Sunday, September 14, 2014 1:59:02 AM UTC-7, Da=
vid Krauss wrote:<br>
> >><br>
> >> Hi all, it=E2=80=99s proposal time again!<br>
> >><br>
> >> Abstract:<br>
> >> =E2=80=93=E2=80=93=E2=80=93<br>
> >> Inline functions have favorable behavior for some kinds of ob=
ject-like entities. Often, users are encouraged to use them to wrap global =
variables. This=C2=A0has long been the status quo, despite the unnatural bo=
ilerplate. Also, it does not work with=C2=A0constexpr, leaving a gap in the=
language. This proposal=C2=A0defines the=C2=A0inline=C2=A0specifier on var=
iable definitions to indicate semantics similar to inline function evaluati=
on and linkage. More generally, this=C2=A0produces a facility for named val=
ues, or variables that are not objects. Applications include displacing leg=
acy value-like macros and introducing data-like class interfaces without im=
pacting layout.<br>
> >> =E2=80=93=E2=80=93=E2=80=93<br>
> >><br>
> >> <a href=3D"http://bit.ly/1qTSBiP" target=3D"_blank">http://bi=
t.ly/1qTSBiP</a><br>
> >><br>
> >> Please let me know if you find anything inspiring, bewilderin=
g, or nauseating.<br>
> ><br>
> > -- <br>
> ><br>
> > --- <br>
> > You received this message because you are subscribed to the Googl=
e Groups "ISO C++ Standard - Future Proposals" group.<br>
> > To unsubscribe from this group and stop receiving emails from it,=
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@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-propos=
als@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
> > Visit this group at <a href=3D"http://groups.google.com/a/isocpp.=
org/group/std-proposals/" target=3D"_blank">http://groups.google.com/a/isoc=
pp.org/group/std-proposals/</a>.<br>
</p>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div></div></div><br></div></div><div class=3D"">=
<div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113403d0d30b5e0503216f87--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 15 Sep 2014 14:45:25 -0700
Raw View
--bcaec51a70a2708fe00503218d47
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Sep 14, 2014 at 4:07 PM, David Krauss <potswa@gmail.com> wrote:
> Urgh, time zones. Here=E2=80=99s a combo reply.
>
>
> On 2014=E2=80=9309=E2=80=9315, at 1:50 AM, Sean Middleditch <sean.middled=
itch@gmail.com>
> wrote:
>
> The example at the end of 2.3 is missing the `inline` keyword I think.
>
>
> Yes, thanks!
>
> A larger question: how much of this facility can be emulated today using
> variable templates?
>
>
> I suppose variable templates avoid the constexpr linkage issue, because a
> template has its own external linkage by default, which specializations
> cannot override.
>
> But I would consider that a workaround, not emulation, because a variable
> template specialization must always be named with a template argument lis=
t,
> even an empty one (=E2=80=9Cmy_var<>=E2=80=9D). You do have a point, thou=
gh; I meant to
> mention that all C++14 implementations already have the linker machinery =
to
> provide common storage to constexpr inline variables.
>
> Can you have inline variable templates? Would you ever want/need to?
>
>
> Sure, why not? It would be evaluated at each use. I can=E2=80=99t think o=
f a use
> case, but a constexpr inline variable template would behave mostly the
> same as a non-inline one, except that the implementation is notionally
> allowed to perform evaluation per use. I think the inline keyword should =
be
> harmless there.
>
>
> On 2014=E2=80=9309=E2=80=9315, at 2:44 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>
> Likewise, making a variable template explicit specialization inline would
> allow it to be defined in a header.
>
> Perhaps I still need my morning coffee, but I think they already can.
>
>
> On 2014=E2=80=9309=E2=80=9315, at 2:45 AM, Andrew Tomazos <andrewtomazos@=
gmail.com> wrote:
>
> Introduce a new kind of entity called a *named expression*, and a new
> keyword *exprname*.
>
> Not sure if this is better or worse than your design, just thought I woul=
d
> mention it. I get the feeling that introducing a new kind of entity is t=
he
> better route, I think just adding an inline keyword to existing variable
> declarations is too confusing.
>
>
> You=E2=80=99ve only introduced syntactic sugar for lambdas. The process o=
f
> entering and returning from the function is interposed into evaluation,
> which my proposal goes to lengths to avoid.
>
> I think the inline syntax is not confusing because the definition is
> substituted just-about-literally inline for each use. It works mostly lik=
e
> an inline function, but purely with expression-value semantics.
>
> Also, linkage is the same as for an inline function, so applying the same
> property to both saves a bit of specification. I=E2=80=99d really be goin=
g out of
> my way to *not* use the inline keyword.
>
>
> On 2014=E2=80=9309=E2=80=9315, at 3:38 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>
> ... sorry, should actually read the proposal before assuming it does the
> "obvious thing". I think this is a suboptimal syntax for what you're
> proposing. The "natural" (IMO) fit for the language would be
>
> using identifier =3D expression;
>
> Yes, I mentioned you in the acknowledgements for this idea but didn=E2=80=
=99t
> mention the idea :P . Perhaps I should?
>
> This syntax always lacks type specificity. Mine allows perfect deduction
> with decltype(auto), or guaranteed evaluation to value or reference
> semantics with auto or auto && respectively, or in the usual case
> encourages a type to be specified.
>
> An inline variable would "naturally" be one for which multiple definition=
s
> are permitted and merged by the ODR (which is an independently valuable
> feature that I hope to get into c++17).
>
> This is already true of my proposal. I mentioned the ODR and linkage, but
> perhaps I should clarify the interactions better.
>
Perhaps I'm misunderstanding your proposal, but I don't think that's the
case at all. In my proposed model,
// foo.h
inline const char kStr[] =3D "blah";
.... would guarantee to give the exact same object in all translation units
in which foo.h is included, just like an inline function, and yet leave the
definition of 'kStr' visible to the optimizer, to the compiler frontend (to
see the complete type of kStr), and so on. This is a much-needed feature
that your proposal does not appear to provide.
I think the problem I have with using "inline variable" syntax for the
semantics you're proposing is threefold:
1) What you get is not 'inline' in the way an inline function is (that is,
there is exactly one entity, you define it in every translation unit that
uses it, and those definitions get odr-merged together)
2) What you get is not a variable (it's an alias to an expression instead)
3) It uses up syntactic space that is the natural place to put a useful
"inline variables" extension, whose use cases are not all covered by this
proposal.
To be clear: Love the proposal. Hate the syntax.
What you're providing is *not* inline variables, it's expression aliases.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--bcaec51a70a2708fe00503218d47
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, Sep 14, 2014 at 4:07 PM, David Krauss <span dir=3D"ltr"><<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word=
">Urgh, time zones. Here=E2=80=99s a combo reply.<div><br></div><div><br><d=
iv><span class=3D""><div>On 2014=E2=80=9309=E2=80=9315, at 1:50 AM, Sean Mi=
ddleditch <<a href=3D"mailto:sean.middleditch@gmail.com" target=3D"_blan=
k">sean.middleditch@gmail.com</a>> wrote:</div><br><blockquote type=3D"c=
ite"><div dir=3D"ltr">The example at the end of 2.3 is missing the `inline`=
keyword I think.</div></blockquote><div><br></div></span>Yes, thanks!</div=
><div><span class=3D""><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>=
A larger question: how much of this facility can be emulated today using va=
riable templates? </div></div></blockquote><div><br></div></span><div>I sup=
pose variable templates avoid the constexpr linkage issue, because a templa=
te has its own external linkage by default, which specializations cannot ov=
erride.</div><div><br></div><div>But I would consider that a workaround, no=
t emulation, because a variable template specialization must always be name=
d with a template argument list, even an empty one (=E2=80=9C<font face=3D"=
Courier">my_var<></font>=E2=80=9D). You do have a point, though; I me=
ant to mention that all C++14 implementations already have the linker machi=
nery to provide common storage to <font face=3D"Courier">constexpr inline</=
font> variables.</div><span class=3D""><br><blockquote type=3D"cite"><div d=
ir=3D"ltr"><div>Can you have inline variable templates? Would you ever want=
/need to?</div></div></blockquote><div><br></div></span><div>Sure, why not?=
It would be evaluated at each use. I can=E2=80=99t think of a use case, bu=
t a <font face=3D"Courier">constexpr inline</font> variable template would =
behave mostly the same as a non-inline one, except that the implementation =
is notionally allowed to perform evaluation per use. I think the inline key=
word should be harmless there.</div><div><br></div><div><br></div><div><spa=
n class=3D""><div>On 2014=E2=80=9309=E2=80=9315, at 2:44 AM, Richard Smith =
<<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@meta=
foo.co.uk</a>> wrote:</div><blockquote type=3D"cite"><p dir=3D"ltr">Like=
wise, making a variable template explicit specialization inline would allow=
it to be defined in a header.</p></blockquote></span><div>Perhaps I still =
need my morning coffee, but I think they already can.</div><div><br></div><=
/div></div></div><div><br></div><div><span class=3D""><div>On 2014=E2=80=93=
09=E2=80=9315, at 2:45 AM, Andrew Tomazos <<a href=3D"mailto:andrewtomaz=
os@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>> wrote:</div=
><br></span><blockquote type=3D"cite"><div dir=3D"ltr"><span class=3D""><di=
v>Introduce a new kind of entity called a=C2=A0<i>named expression</i>, and=
a new keyword=C2=A0<b>exprname</b>.</div><div><br></div></span><span class=
=3D""><div>Not sure if this is better or worse than your design, just thoug=
ht I would mention it. =C2=A0I get the feeling that introducing a new kind =
of entity is the better route, I think just adding an inline keyword to exi=
sting variable declarations is too confusing.</div></span></div></blockquot=
e></div><div><div dir=3D"ltr"><div><br></div><div>You=E2=80=99ve only intro=
duced syntactic sugar for lambdas. The process of entering and returning fr=
om the function is interposed into evaluation, which my proposal goes to le=
ngths to avoid.</div><div><br></div><div>I think the <font face=3D"Courier"=
>inline</font> syntax is not confusing because the definition is substitute=
d just-about-literally inline for each use. It works mostly like an <font f=
ace=3D"Courier">inline</font> function, but purely with expression-value se=
mantics.</div><div><br></div><div>Also, linkage is the same as for an inlin=
e function, so applying the same property to both saves a bit of specificat=
ion. I=E2=80=99d really be going out of my way to <i>not</i> use the <font =
face=3D"Courier">inline</font> keyword.</div><div><br></div><div><br></div>=
<div><span class=3D""><div>On 2014=E2=80=9309=E2=80=9315, at 3:38 AM, Richa=
rd Smith <<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">ric=
hard@metafoo.co.uk</a>> wrote:</div><br><blockquote type=3D"cite"><p dir=
=3D"ltr">... sorry, should actually read the proposal before assuming it do=
es the "obvious thing". I think this is a suboptimal syntax for w=
hat you're proposing. The "natural" (IMO) fit for the languag=
e would be</p><p dir=3D"ltr">=C2=A0 using identifier =3D expression;</p></b=
lockquote></span><div>Yes, I mentioned you in the acknowledgements for this=
idea but didn=E2=80=99t mention the idea :P . Perhaps I should?</div><div>=
<br></div><div>This syntax always lacks type specificity. Mine allows perfe=
ct deduction with <font face=3D"Courier">decltype(auto)</font>, or guarante=
ed evaluation to value or reference semantics with <font face=3D"Courier">a=
uto</font> or <font face=3D"Courier">auto &&</font> respectively, o=
r in the usual case encourages a type to be specified.</div><span class=3D"=
"><blockquote type=3D"cite"><p dir=3D"ltr">An inline variable would "n=
aturally" be one for which multiple definitions are permitted and merg=
ed by the ODR (which is an independently valuable feature that I hope to ge=
t into c++17).</p></blockquote></span></div><div><p dir=3D"ltr">This is alr=
eady true of my proposal. I mentioned the ODR and linkage, but perhaps I sh=
ould clarify the interactions better.</p></div></div></div></div></blockquo=
te><div>Perhaps I'm misunderstanding your proposal, but I don't thi=
nk that's the case at all. In my proposed model,</div><div><br></div><d=
iv>// foo.h</div><div>inline const char kStr[] =3D "blah";</div><=
div><br></div><div>... would guarantee to give the exact same object in all=
translation units in which foo.h is included, just like an inline function=
, and yet leave the definition of 'kStr' visible to the optimizer, =
to the compiler frontend (to see the complete type of kStr), and so on. Thi=
s is a much-needed feature that your proposal does not appear to provide.</=
div><div><br></div><div>I think the problem I have with using "inline =
variable" syntax for the semantics you're proposing is threefold:<=
/div><div>1) What you get is not 'inline' in the way an inline func=
tion is (that is, there is exactly one entity, you define it in every trans=
lation unit that uses it, and those definitions get odr-merged together)</d=
iv><div>2) What you get is not a variable (it's an alias to an expressi=
on instead)</div><div>3) It uses up syntactic space that is the natural pla=
ce to put a useful "inline variables" extension, whose use cases =
are not all covered by this proposal.<br></div><div><br></div><div>To be cl=
ear: Love the proposal. Hate the syntax.</div><div><br></div><div>What you&=
#39;re providing is *not* inline variables, it's expression aliases.</d=
iv></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec51a70a2708fe00503218d47--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Mon, 15 Sep 2014 17:21:27 -0700 (PDT)
Raw View
------=_Part_882_1135725434.1410826887586
Content-Type: text/plain; charset=UTF-8
>
> Here is a use case I really wish I had inline variables for:
For a vector math library with array, named accessors, and swizzle aliases.
class vec3 {
public: //data
float v[3];
public: //inline variables
inline float x = v[0];
inline float y = v[1];
inline float z = v[2];
inline vec2_proxy xy = _xy();
inline vec2_proxy xz = _xz();
inline vec2_proxy yx = _yx();
inline vec2_proxy yz = _yz();
inline vec2_proxy zx = _zx();
inline vec2_proxy zy = _zy();
inline vec3_proxy xzy = _xzy();
//etc..
};
Encapsulating a class implementation which stores its data members in a
tuple instead of creating direct members. I've been finding a lot of uses
cases where storing your data members as tuples allows you do a lot more
algorithmic processing on data members. It helps with serialization and
type erasure techniques.
template <typename... Args>
class Instruction {
protected:
std::tuple<Args> args;
};
class InsAdd : public Instruction<Regiser lreg, Register r_reg>; {
inline lreg = std::get<0>(args)
inline rreg = std::get<1>(rreg)
};
And even more use
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_882_1135725434.1410826887586
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Here is a use=
case I really wish I had inline variables for:</blockquote><div><br></div>=
<div>For a vector math library with array, named accessors, and swizz=
le aliases.</div><div><br></div><div><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><font color=3D"#000088"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">class</span></font><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> vec3 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">publ=
ic</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">//data</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">3</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">];</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">public</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">//inline variab=
les</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">inline=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">[</span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">inline</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><font color=3D"#000088"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">float</span></font><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> y </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">];</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">inline</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><font color=3D"#000088">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">float</span></fon=
t><span style=3D"color: #000;" class=3D"styled-by-prettify"> z </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">];</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br> <br> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">inline</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> vec2</span><font color=3D"#666600"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">_proxy</span></font><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> xy </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> _xy</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">inline</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><font color=3D"#000088"><span style=3D"color: #000;" =
class=3D"styled-by-prettify">vec2_proxy</span></font><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> xz </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> _xz</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-b=
y-prettify">inline</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> vec2_proxy yx </span><font color=3D"#666600"><span style=3D"color:=
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> _yx</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></font><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">inline</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> vec2_proxy yz </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> _yz</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">inl=
ine</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> vec2_p=
roxy zx</span><font color=3D"#666600"><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> _zx</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an></font><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">inline</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> vec2_proxy zy=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> _zy</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> <br> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">inline</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> vec3_proxy xzy </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> _xzy</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #800;" class=3D"styled-by-prettify">/</span><font color=3D"#000000">=
<span style=3D"color: #800;" class=3D"styled-by-prettify">/etc..</span></fo=
nt><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></cod=
e></div><br><br></div><div>Encapsulating a class implementation which store=
s its data members in a tuple instead of creating direct members. I've been=
finding a lot of uses cases where storing your data members as tuples allo=
ws you do a lot more algorithmic processing on data members. It helps with =
serialization and type erasure techniques.</div><div><br></div><div><br></d=
iv><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">template</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">typename</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Args<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Instruction</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">protected</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">tuple</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Args</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> args=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">InsAdd</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">pub=
lic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Instruction</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Regiser</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> lreg</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: #606;" =
class=3D"styled-by-prettify">Register</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> r_reg</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">>;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">inline</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> l=
reg</span><font color=3D"#666600"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">get</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">>(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">args</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span></font><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">inline</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> rreg</span><font color=3D"#666600"><span style=3D"color: #00=
0;" 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"sty=
led-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">get</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">rreg</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span></font><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span></div></code></div><div><br=
>And even more use</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_882_1135725434.1410826887586--
.
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Mon, 15 Sep 2014 17:50:49 -0700 (PDT)
Raw View
------=_Part_876_128182909.1410828650099
Content-Type: text/plain; charset=UTF-8
This proposal might also benefit from your other one, Categorically
qualified classes
Particularly for proxy types, like used in std::bitset and my vec3 example.
Proxy types are like expression templates when it comes to using auto.
vec3 xyz;
auto yz = xyz.yz;
static_assert<std::is_same<decltype(yz),vec2>::value);
On Monday, September 15, 2014 8:21:27 PM UTC-4, Matthew Fioravante wrote:
>
> Here is a use case I really wish I had inline variables for:
>
>
> For a vector math library with array, named accessors, and swizzle
> aliases.
>
> class vec3 {
> public: //data
> float v[3];
>
> public: //inline variables
> inline float x = v[0];
> inline float y = v[1];
> inline float z = v[2];
>
> inline vec2_proxy xy = _xy();
> inline vec2_proxy xz = _xz();
> inline vec2_proxy yx = _yx();
> inline vec2_proxy yz = _yz();
> inline vec2_proxy zx = _zx();
> inline vec2_proxy zy = _zy();
>
> inline vec3_proxy xzy = _xzy();
> //etc..
> };
>
>
> Encapsulating a class implementation which stores its data members in a
> tuple instead of creating direct members. I've been finding a lot of uses
> cases where storing your data members as tuples allows you do a lot more
> algorithmic processing on data members. It helps with serialization and
> type erasure techniques.
>
>
> template <typename... Args>
> class Instruction {
> protected:
> std::tuple<Args> args;
> };
>
> class InsAdd : public Instruction<Regiser lreg, Register r_reg>; {
> inline lreg = std::get<0>(args)
> inline rreg = std::get<1>(rreg)
> };
>
>
> And even more use
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_876_128182909.1410828650099
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This proposal might also benefit from your other one, Cate=
gorically qualified classes<div><br></div><div>Particularly for proxy types=
, like used in std::bitset and my vec3 example. Proxy types are like expres=
sion templates when it comes to using auto. </div><div><br></div><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">vec3 xyz</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> yz </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> xyz</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">yz</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">static_assert</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">is_same</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><</span><font color=3D"#660066"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">decltype</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">yz</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">),</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v=
ec2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">value</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></font>=
</div></code></div><div><br></div><div><br><br>On Monday, September 15, 201=
4 8:21:27 PM UTC-4, Matthew Fioravante wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Her=
e is a use case I really wish I had inline variables for:</blockquote><div>=
<br></div><div>For a vector math library with array, named accessors,=
and swizzle aliases.</div><div><br></div><div><div style=3D"background-col=
or:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word"=
><code><div><font color=3D"#000088"><span style=3D"color:#008">class</span>=
</font><span style=3D"color:#000"> vec3 </span><span style=3D"color:#660">{=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">pub=
lic</span><span style=3D"color:#660">:</span><span style=3D"color:#000"> </=
span><span style=3D"color:#800">//data</span><span style=3D"color:#000"><br=
> </span><span style=3D"color:#008">float</span><span style=3D"color:=
#000"> v</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"><b=
r><br></span><span style=3D"color:#008">public</span><span style=3D"color:#=
660">:</span><span style=3D"color:#000"> </span><span style=3D"color:#800">=
//inline variables</span><span style=3D"color:#000"><br> </span><span=
style=3D"color:#008">inline</span><span style=3D"color:#000"> </span><span=
style=3D"color:#008">float</span><span style=3D"color:#000"> x </span><spa=
n style=3D"color:#660">=3D</span><span style=3D"color:#000"> v</span><span =
style=3D"color:#660">[</span><span style=3D"color:#066">0</span><span style=
=3D"color:#660">];</span><span style=3D"color:#000"><br> </span><span=
style=3D"color:#008">inline</span><span style=3D"color:#000"> </span><font=
color=3D"#000088"><span style=3D"color:#008">float</span></font><span styl=
e=3D"color:#000"> y </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> v</span><span style=3D"color:#660">[</span><span style=3D"=
color:#066">1</span><span style=3D"color:#660">];</span><span style=3D"colo=
r:#000"><br> </span><span style=3D"color:#008">inline</span><span sty=
le=3D"color:#000"> </span><font color=3D"#000088"><span style=3D"color:#008=
">float</span></font><span style=3D"color:#000"> z </span><span style=3D"co=
lor:#660">=3D</span><span style=3D"color:#000"> v</span><span style=3D"colo=
r:#660">[</span><span style=3D"color:#066">2</span><span style=3D"color:#66=
0">];</span><span style=3D"color:#000"><br> <br> </span><span s=
tyle=3D"color:#008">inline</span><span style=3D"color:#000"> vec2</span><fo=
nt color=3D"#666600"><span style=3D"color:#000">_proxy</span></font><span s=
tyle=3D"color:#000"> xy </span><span style=3D"color:#660">=3D</span><span s=
tyle=3D"color:#000"> _xy</span><span style=3D"color:#660">();</span><span s=
tyle=3D"color:#000"><br> </span><span style=3D"color:#008">inline</sp=
an><span style=3D"color:#000"> </span><font color=3D"#000088"><span style=
=3D"color:#000">vec2_proxy</span></font><span style=3D"color:#000"> xz </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> _xz</sp=
an><span style=3D"color:#660">();</span><span style=3D"color:#000"><br>&nbs=
p; </span><span style=3D"color:#008">inline</span><span style=3D"color:#000=
"> vec2_proxy yx </span><font color=3D"#666600"><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> _yx</span><span style=3D"color:#660">=
();</span><span style=3D"color:#000"><br></span></font><span style=3D"color=
:#000"> </span><span style=3D"color:#008">inline</span><span style=3D=
"color:#000"> vec2_proxy yz </span><span style=3D"color:#660">=3D</span><sp=
an style=3D"color:#000"> _yz</span><span style=3D"color:#660">();</span><sp=
an style=3D"color:#000"><br> </span><span style=3D"color:#008">inline=
</span><span style=3D"color:#000"> vec2_proxy zx</span><font color=3D"#6666=
00"><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D</span=
><span style=3D"color:#000"> _zx</span><span style=3D"color:#660">();</span=
><span style=3D"color:#000"><br></span></font><span style=3D"color:#000">&n=
bsp; </span><span style=3D"color:#008">inline</span><span style=3D"color:#0=
00"> vec2_proxy zy </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> _zy</span><span style=3D"color:#660">();</span><span style=
=3D"color:#000"><br> <br> </span><span style=3D"color:#008">inl=
ine</span><span style=3D"color:#000"> vec3_proxy xzy </span><span style=3D"=
color:#660">=3D</span><span style=3D"color:#000"> _xzy</span><span style=3D=
"color:#660">();</span><span style=3D"color:#000"><br> </span><span s=
tyle=3D"color:#800">/</span><font color=3D"#000000"><span style=3D"color:#8=
00">/etc..</span></font><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">};</span></div></code></div><br><br></div><div>Encapsulatin=
g a class implementation which stores its data members in a tuple instead o=
f creating direct members. I've been finding a lot of uses cases where stor=
ing your data members as tuples allows you do a lot more algorithmic proces=
sing on data members. It helps with serialization and type erasure techniqu=
es.</div><div><br></div><div><br></div><div style=3D"background-color:rgb(2=
50,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><=
div><span style=3D"color:#008">template</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660"><</span><span style=3D"color:#008">type=
name</span><span style=3D"color:#660">...</span><span style=3D"color:#000">=
</span><span style=3D"color:#606">Args</span><span style=3D"color:#660">&g=
t;</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">c=
lass</span><span style=3D"color:#000"> </span><span style=3D"color:#606">In=
struction</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">{</span><span style=3D"color:#000"><br> </span><span style=3D"colo=
r:#008">protected</span><span style=3D"color:#660">:</span><span style=3D"c=
olor:#000"><br> std</span><span style=3D"color:#660">::</span>=
<span style=3D"color:#000">tuple</span><span style=3D"color:#660"><</spa=
n><span style=3D"color:#606">Args</span><span style=3D"color:#660">></sp=
an><span style=3D"color:#000"> args</span><span style=3D"color:#660">;</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#660">};</span=
><span style=3D"color:#000"><br><br></span><span style=3D"color:#008">class=
</span><span style=3D"color:#000"> </span><span style=3D"color:#606">InsAdd=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">:</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#008">public</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#606">Instruction=
</span><span style=3D"color:#660"><</span><span style=3D"color:#606">Reg=
iser</span><span style=3D"color:#000"> lreg</span><span style=3D"color:#660=
">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Reg=
ister</span><span style=3D"color:#000"> r_reg</span><span style=3D"color:#6=
60">>;</span><span style=3D"color:#000"> </span><span style=3D"color:#66=
0">{</span><span style=3D"color:#000"><br> </span><span style=3D"colo=
r:#008">inline</span><span style=3D"color:#000"> lreg</span><font color=3D"=
#666600"><span style=3D"color:#000"> </span><span style=3D"color:#660">=3D<=
/span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</=
span><span style=3D"color:#008">get</span><span style=3D"color:#660"><</=
span><span style=3D"color:#066">0</span><span style=3D"color:#660">>(</s=
pan><span style=3D"color:#000">args</span><span style=3D"color:#660">)</spa=
n><span style=3D"color:#000"><br></span></font><span style=3D"color:#000">&=
nbsp; </span><span style=3D"color:#008">inline</span><span style=3D"color:#=
000"> rreg</span><font color=3D"#666600"><span style=3D"color:#000"> </span=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> std</span=
><span style=3D"color:#660">::</span><span style=3D"color:#008">get</span><=
span style=3D"color:#660"><</span><span style=3D"color:#066">1</span><sp=
an style=3D"color:#660">>(</span><span style=3D"color:#000">rreg</span><=
span style=3D"color:#660">)</span></font><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">};</span><span style=3D"color:#000"><br><br>=
</span></div></code></div><div><br>And even more use</div><div><br></div></=
div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_876_128182909.1410828650099--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 16 Sep 2014 09:52:41 +0800
Raw View
--Apple-Mail=_81AC1703-DCBB-4020-8C34-240D5A4CF4FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-16, at 5:45 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> Perhaps I'm misunderstanding your proposal, but I don't think that's the =
case at all. In my proposed model,
>=20
> // foo.h
> inline const char kStr[] =3D "blah";
>=20
> ... would guarantee to give the exact same object in all translation unit=
s in which foo.h is included, just like an inline function, and yet leave t=
he definition of 'kStr' visible to the optimizer, to the compiler frontend =
(to see the complete type of kStr), and so on. This is a much-needed featur=
e that your proposal does not appear to provide.
For that specific case of inline const char kStr[], yes, the intent is that=
it should. The initializer of kStr has one value in every translation unit=
and the ODR guarantees the string literal to be the same object. Evaluatio=
n yields a prvalue, but prvalues of ROMable objects ideally may refer direc=
tly to ROM. This issue is mentioned in the last paragraph of =A72.2:
> Observable object identity for constants may be useful, though, for globa=
l constexpr arrays and tables. If a weak linkage semantic is required, it m=
ight as well be accessible to the user. The questions of value category, st=
orage duration, and object identity for constant expressions and temporarie=
s are interesting, but outside the scope of and orthogonal to this proposal=
..
---
> I think the problem I have with using "inline variable" syntax for the se=
mantics you're proposing is threefold:
> 1) What you get is not 'inline' in the way an inline function is (that is=
, there is exactly one entity, you define it in every translation unit that=
uses it, and those definitions get odr-merged together)
The linkage is exactly like inline functions. The difference is evaluation,=
only in that there is no separation between the initializer object and the=
return value of the (imaginary) inline function.
What's linked is a description of the expression, not the object representa=
tion of the result.
> 2) What you get is not a variable (it's an alias to an expression instead=
)
That's still a name which evaluates to a reference or object. It's not iden=
tically an object, no.
When you define an object, you need to decide when it should be initialized=
.. I don't think unordered initialization is a very good solution, and neith=
er on-demand (like local static objects) nor on-definition (like usual non-=
const namespace scope objects) are always appropriate either.
I'd rather provide a means to access any object using a simple name, than t=
ry to invent another universal solution to the static initialization order =
fiasco.
> What you're providing is *not* inline variables, it's expression aliases.
Expression aliases that are declared and behave like variables, perhaps wit=
h definite type and value category.
It's as sane as a macro facility can get.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_81AC1703-DCBB-4020-8C34-240D5A4CF4FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–16, at 5:45 AM, Richard Smith <<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Pe=
rhaps I'm misunderstanding your proposal, but I don't think that's the case=
at all. In my proposed model,</div><div><br></div><div>// foo.h</div><div>=
inline const char kStr[] =3D "blah";</div><div><br></div><div>... would gua=
rantee to give the exact same object in all translation units in which foo.=
h is included, just like an inline function, and yet leave the definition o=
f 'kStr' visible to the optimizer, to the compiler frontend (to see the com=
plete type of kStr), and so on. This is a much-needed feature that your pro=
posal does not appear to provide.</div></div></div></div></div></blockquote=
><div><br></div><div>For that specific case of <font face=3D"Courier">inlin=
e const char kStr[]</font>, yes, the intent is that it should. The initiali=
zer of kStr has one value in every translation unit and the ODR guarantees =
the string literal to be the same object. Evaluation yields a prvalue, but =
prvalues of ROMable objects ideally may refer directly to ROM. This issue i=
s mentioned in the last paragraph of =A72.2:</div><div><br></div><div><bloc=
kquote type=3D"cite">Observable object identity for constants may be useful=
, though, for global constexpr arrays and tables. If a weak linka=
ge semantic is required, it might as well be accessible to the user. T=
he questions of value category, storage duration, and object identity for c=
onstant expressions and temporaries are interesting, but outside the s=
cope of and orthogonal to this proposal.<br></blockquote><div>–&ndash=
;–</div><br></div><blockquote type=3D"cite"><div style=3D"font-family=
: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fon=
t-weight: normal; letter-spacing: normal; line-height: normal; orphans: aut=
o; text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><=
div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=
I think the problem I have with using "inline variable" syntax for the sema=
ntics you're proposing is threefold:</div><div>1) What you get is not 'inli=
ne' in the way an inline function is (that is, there is exactly one entity,=
you define it in every translation unit that uses it, and those definition=
s get odr-merged together)</div></div></div></div></div></blockquote><div><=
br></div><div>The linkage is <i>exactly</i> like inline functions. The diff=
erence is evaluation, only in that there is no separation between the initi=
alizer object and the return value of the (imaginary) inline function.</div=
><div><br></div><div>What’s linked is a description of the expression=
, not the object representation of the result.</div><br><blockquote type=3D=
"cite"><div style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>2) What you get is not a variable (it's an =
alias to an expression instead)</div></div></div></div></div></blockquote><=
div><br></div><div>That’s still a name which evaluates to a reference=
or object. It’s not identically an object, no.</div><div><br></div><=
div>When you define an object, you need to decide when it should be initial=
ized. I don’t think unordered initialization is a very good solution,=
and neither on-demand (like local <font face=3D"Courier">static</font> obj=
ects) nor on-definition (like usual non-<font face=3D"Courier">const</font>=
namespace scope objects) are always appropriate either.</div><div><br></di=
v><div>I’d rather provide a means to access any object using a simple=
name, than try to invent another universal solution to the static initiali=
zation order fiasco.</div><br><blockquote type=3D"cite"><div style=3D"font-=
family: Helvetica; font-size: 12px; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; line-height: normal; orphan=
s: auto; text-align: start; text-indent: 0px; text-transform: none; white-s=
pace: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px;"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div>What you're providing is *not* inline variables, it's expression alia=
ses.</div></div></div></div></div></blockquote><div><br></div><div>Expressi=
on aliases that are declared and behave like variables, perhaps with defini=
te type and value category.</div></div><br><div>It’s as sane as a mac=
ro facility can get.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_81AC1703-DCBB-4020-8C34-240D5A4CF4FC--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 16 Sep 2014 10:16:44 +0800
Raw View
--Apple-Mail=_3CD9006E-4E7D-44E0-BB2A-7C6BAE8B2648
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-16, at 8:50 AM, Matthew Fioravante <fmatthew5876@gmail.com> wrote:
> This proposal might also benefit from your other one, Categorically qualified classes
>
> Particularly for proxy types, like used in std::bitset and my vec3 example. Proxy types are like expression templates when it comes to using auto.
Yeah, I'm somewhat afraid to harp on what capabilities I might add to "class attributes," due to the controversy there.
I did mention,
> Also, as temporary objects, a wider variety of design patterns is available, compared to member subobjects which are permanently resident. A proxy derived from the value type would support both value type member accesses, and customized assignment.
>
Such a derived proxy would work best with rvalue qualification and lvalue conversion to the value type.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_3CD9006E-4E7D-44E0-BB2A-7C6BAE8B2648
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–16, at 8:50 AM, Matthew Fioravante <<a href=3D"mailto:fma=
tthew5876@gmail.com">fmatthew5876@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">T=
his proposal might also benefit from your other one, Categorically qualifie=
d classes<div><br></div><div>Particularly for proxy types, like used in std=
::bitset and my vec3 example. Proxy types are like expression templates whe=
n it comes to using auto. </div></div></blockquote><div><br></div><div=
>Yeah, I’m somewhat afraid to harp on what capabilities I might add t=
o “class attributes,” due to the controversy there.</div><div><=
br></div><div>I did mention,</div><div><br></div><div><blockquote type=3D"c=
ite"><p style=3D"margin: 0px 0px 6px;"><span style=3D"letter-spacing: 0.0px=
">Also, as temporary objects, a wider variety of design patterns is availab=
le, compared to member subobjects which are permanently resident. A proxy d=
erived from the value type would support both value type member accesses, a=
nd customized assignment.</span></p></blockquote><div><p style=3D"margin: 0=
px 0px 6px;"><span style=3D"letter-spacing: 0px;"><br></span></p><p style=
=3D"margin: 0px 0px 6px;"><span style=3D"letter-spacing: 0px;">Such a deriv=
ed proxy would work best with rvalue qualification and lvalue conversion to=
the value type.</span></p></div></div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_3CD9006E-4E7D-44E0-BB2A-7C6BAE8B2648--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 17 Sep 2014 14:42:26 -0700
Raw View
--bcaec52c5b977aa626050349bebe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
OK, I've re-read the proposal, and I'm no longer sure what it is you're
proposing. In particular, you say:
"So that an inline constexpr variable may have backing storage and
meaningful linkage,
its initializer must evaluate to the same value at every use, no diagnostic
required."
.... which breaks your use cases for 'errno' and 'stdout' (where the value
can change during the execution of the program, or between threads). Your
'NULL' example doesn't work in modern C++. Your bit_index has no need to be
inline. So none of the use cases in 2.1 are served by your proposal.
I have been unable to comprehend what you're saying about when or how or
how often the initializer for inline variables is run, so I can't tell if
your proposal addresses the cases in 2.2. It would be helpful if you could
clearly state some rules somewhere in the paper.
Ultimately, it looks like an 'expression alias' proposal and an 'inline
variable' proposal got conflated in here, and we've ended up with a
proposal that doesn't really do justice to either feature. (This is evident
even in the name of the paper...)
Here are two proposals that I believe together cover all of your use cases
for this feature, and all of mine:
1) 'inline' is permitted on variables. A variable marked 'inline' is an
exact analogue of a function marked 'inline': definitions are permitted in
multiple translation units, so long as they follow [basic.def.odr]p6, and
the program acts as if there is only one definition. The variable has
unordered initialization.[1]
2) An expression alias declaration, 'static[opt] using *identifier* =3D
*expression*;', is permitted. An id-expression that names an expression
alias declaration has the same type and value as the alias's expression,
and can be used in exactly the same contexts as that expression, and with
the same meaning, except as otherwise indicated. Names within the
expression are looked up, access checked, and bound in the context where
the alias declaration appears. A non-static member expression alias
declaration can contain references to 'this', and can only be referenced
via a member access expression; its references to 'this' refer to the
address of the object on which the alias is accessed.
[1] We can do better here: we can say that the initialization of the
variable is sequenced after the initialization of all earlier-defined
variables in some TU in which it is defined, and sequenced before the
initialization of all later-defined non-inline variables in every TU in
which it is defined.
On Mon, Sep 15, 2014 at 6:52 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9309=E2=80=9316, at 5:45 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>
> Perhaps I'm misunderstanding your proposal, but I don't think that's the
> case at all. In my proposed model,
>
> // foo.h
> inline const char kStr[] =3D "blah";
>
> ... would guarantee to give the exact same object in all translation unit=
s
> in which foo.h is included, just like an inline function, and yet leave t=
he
> definition of 'kStr' visible to the optimizer, to the compiler frontend (=
to
> see the complete type of kStr), and so on. This is a much-needed feature
> that your proposal does not appear to provide.
>
>
> For that specific case of inline const char kStr[], yes, the intent is
> that it should. The initializer of kStr has one value in every translatio=
n
> unit and the ODR guarantees the string literal to be the same object.
> Evaluation yields a prvalue, but prvalues of ROMable objects ideally may
> refer directly to ROM. This issue is mentioned in the last paragraph of
> =C2=A72.2:
>
> Observable object identity for constants may be useful, though, for
> global constexpr arrays and tables. If a weak linkage semantic is require=
d,
> it might as well be accessible to the user. The questions of value
> category, storage duration, and object identity for constant expressions
> and temporaries are interesting, but outside the scope of and orthogonal =
to
> this proposal.
>
> =E2=80=93=E2=80=93=E2=80=93
>
> I think the problem I have with using "inline variable" syntax for the
> semantics you're proposing is threefold:
> 1) What you get is not 'inline' in the way an inline function is (that is=
,
> there is exactly one entity, you define it in every translation unit that
> uses it, and those definitions get odr-merged together)
>
>
> The linkage is *exactly* like inline functions. The difference is
> evaluation, only in that there is no separation between the initializer
> object and the return value of the (imaginary) inline function.
>
> What=E2=80=99s linked is a description of the expression, not the object
> representation of the result.
>
> 2) What you get is not a variable (it's an alias to an expression instead=
)
>
>
> That=E2=80=99s still a name which evaluates to a reference or object. It=
=E2=80=99s not
> identically an object, no.
>
> When you define an object, you need to decide when it should be
> initialized. I don=E2=80=99t think unordered initialization is a very goo=
d
> solution, and neither on-demand (like local static objects) nor
> on-definition (like usual non-const namespace scope objects) are always
> appropriate either.
>
> I=E2=80=99d rather provide a means to access any object using a simple na=
me, than
> try to invent another universal solution to the static initialization ord=
er
> fiasco.
>
> What you're providing is *not* inline variables, it's expression aliases.
>
>
> Expression aliases that are declared and behave like variables, perhaps
> with definite type and value category.
>
> It=E2=80=99s as sane as a macro facility can get.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--bcaec52c5b977aa626050349bebe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">OK, I've re-read the proposal, and I'm no longer s=
ure what it is you're proposing. In particular, you say:<div><br></div>=
<div><div>"So that an inline constexpr variable may have backing stora=
ge and meaningful linkage,=C2=A0</div><div>its initializer must evaluate to=
the same value at every use, no diagnostic required."</div></div><div=
><br></div><div>... which breaks your use cases for 'errno' and =
9;stdout' (where the value can change during the execution of the progr=
am, or between threads). Your 'NULL' example doesn't work in mo=
dern C++. Your bit_index has no need to be inline. So none of the use cases=
in 2.1 are served by your proposal.</div><div><br></div><div>I have been u=
nable to comprehend what you're saying about when or how or how often t=
he initializer for inline variables is run, so I can't tell if your pro=
posal addresses the cases in 2.2. It would be helpful if you could clearly =
state some rules somewhere in the paper.</div><div><br></div><div>Ultimatel=
y, it looks like an 'expression alias' proposal and an 'inline =
variable' proposal got conflated in here, and we've ended up with a=
proposal that doesn't really do justice to either feature. (This is ev=
ident even in the name of the paper...)</div><div><br></div><div>Here are t=
wo proposals that I believe together cover all of your use cases for this f=
eature, and all of mine:</div><div><br></div><div>1) 'inline' is pe=
rmitted on variables. A variable marked 'inline' is an exact analog=
ue of a function marked 'inline': definitions are permitted in mult=
iple translation units, so long as they follow [basic.def.odr]p6, and the p=
rogram acts as if there is only one definition. The variable has unordered =
initialization.[1]</div><div><br></div><div>2) An expression alias declarat=
ion, 'static[opt] using <i>identifier</i> =3D <i>expression</i>;', =
is permitted. An id-expression that names an expression alias declaration h=
as the same type and value as the alias's expression, and can be used i=
n exactly the same contexts as that expression, and with the same meaning, =
except as otherwise indicated. Names within the expression are looked up, a=
ccess checked, and bound in the context where the alias declaration appears=
.. A non-static member expression alias declaration can contain references t=
o 'this', and can only be referenced via a member access expression=
; its references to 'this' refer to the address of the object on wh=
ich the alias is accessed.</div><div><br></div><div>[1] We can do better he=
re: we can say that the initialization of the variable is sequenced after t=
he initialization of all earlier-defined variables in some TU in which it i=
s defined, and sequenced before the initialization of all later-defined non=
-inline variables in every TU in which it is defined.</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Sep 15, 2014 at 6:5=
2 PM, David Krauss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com=
" target=3D"_blank">potswa@gmail.com</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><span class=
=3D""><div>On 2014=E2=80=9309=E2=80=9316, at 5:45 AM, Richard Smith <<a =
href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.=
uk</a>> wrote:</div><br><blockquote type=3D"cite"><div style=3D"font-fam=
ily:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-wei=
ght:normal;letter-spacing:normal;line-height:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Perhaps=
I'm misunderstanding your proposal, but I don't think that's t=
he case at all. In my proposed model,</div><div><br></div><div>// foo.h</di=
v><div>inline const char kStr[] =3D "blah";</div><div><br></div><=
div>... would guarantee to give the exact same object in all translation un=
its in which foo.h is included, just like an inline function, and yet leave=
the definition of 'kStr' visible to the optimizer, to the compiler=
frontend (to see the complete type of kStr), and so on. This is a much-nee=
ded feature that your proposal does not appear to provide.</div></div></div=
></div></div></blockquote><div><br></div></span><div>For that specific case=
of <font face=3D"Courier">inline const char kStr[]</font>, yes, the intent=
is that it should. The initializer of kStr has one value in every translat=
ion unit and the ODR guarantees the string literal to be the same object. E=
valuation yields a prvalue, but prvalues of ROMable objects ideally may ref=
er directly to ROM. This issue is mentioned in the last paragraph of =C2=A7=
2.2:</div><div><br></div><div><blockquote type=3D"cite">Observable object i=
dentity for constants may be useful, though, for global=C2=A0constexpr=C2=
=A0arrays and tables. If a weak linkage semantic is required, it=C2=A0might=
as well be accessible to the user. The questions of value category, storag=
e duration, and object identity for constant expressions and temporaries=C2=
=A0are interesting, but outside the scope of and orthogonal to this proposa=
l.<br></blockquote><div>=E2=80=93=E2=80=93=E2=80=93</div><br></div><span cl=
ass=3D""><blockquote type=3D"cite"><div style=3D"font-family:Helvetica;font=
-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-=
spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>I think the problem I hav=
e with using "inline variable" syntax for the semantics you'r=
e proposing is threefold:</div><div>1) What you get is not 'inline'=
in the way an inline function is (that is, there is exactly one entity, yo=
u define it in every translation unit that uses it, and those definitions g=
et odr-merged together)</div></div></div></div></div></blockquote><div><br>=
</div></span><div>The linkage is <i>exactly</i> like inline functions. The =
difference is evaluation, only in that there is no separation between the i=
nitializer object and the return value of the (imaginary) inline function.<=
/div><div><br></div><div>What=E2=80=99s linked is a description of the expr=
ession, not the object representation of the result.</div><span class=3D"">=
<br><blockquote type=3D"cite"><div style=3D"font-family:Helvetica;font-size=
:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spaci=
ng:normal;line-height:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><div>2) What you get is not a varia=
ble (it's an alias to an expression instead)</div></div></div></div></d=
iv></blockquote><div><br></div></span><div>That=E2=80=99s still a name whic=
h evaluates to a reference or object. It=E2=80=99s not identically an objec=
t, no.</div><div><br></div><div>When you define an object, you need to deci=
de when it should be initialized. I don=E2=80=99t think unordered initializ=
ation is a very good solution, and neither on-demand (like local <font face=
=3D"Courier">static</font> objects) nor on-definition (like usual non-<font=
face=3D"Courier">const</font> namespace scope objects) are always appropri=
ate either.</div><div><br></div><div>I=E2=80=99d rather provide a means to =
access any object using a simple name, than try to invent another universal=
solution to the static initialization order fiasco.</div><span class=3D"">=
<br><blockquote type=3D"cite"><div style=3D"font-family:Helvetica;font-size=
:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spaci=
ng:normal;line-height:normal;text-align:start;text-indent:0px;text-transfor=
m:none;white-space:normal;word-spacing:0px"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><div>What you're providing is *=
not* inline variables, it's expression aliases.</div></div></div></div>=
</div></blockquote><div><br></div></span><div>Expression aliases that are d=
eclared and behave like variables, perhaps with definite type and value cat=
egory.</div></div><br><div>It=E2=80=99s as sane as a macro facility can get=
..</div><div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec52c5b977aa626050349bebe--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 17 Sep 2014 14:44:24 -0700
Raw View
--001a1133375c79babe050349c5b4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Sep 17, 2014 at 2:42 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
> OK, I've re-read the proposal, and I'm no longer sure what it is you're
> proposing. In particular, you say:
>
> "So that an inline constexpr variable may have backing storage and
> meaningful linkage,
> its initializer must evaluate to the same value at every use, no
> diagnostic required."
>
> ... which breaks your use cases for 'errno' and 'stdout' (where the value
> can change during the execution of the program, or between threads).
>
Please ignore this bit. I somehow overlooked the 'constexpr' here.
> Your 'NULL' example doesn't work in modern C++. Your bit_index has no nee=
d
> to be inline. So none of the use cases in 2.1 are served by your proposal=
..
>
> I have been unable to comprehend what you're saying about when or how or
> how often the initializer for inline variables is run, so I can't tell if
> your proposal addresses the cases in 2.2. It would be helpful if you coul=
d
> clearly state some rules somewhere in the paper.
>
> Ultimately, it looks like an 'expression alias' proposal and an 'inline
> variable' proposal got conflated in here, and we've ended up with a
> proposal that doesn't really do justice to either feature. (This is evide=
nt
> even in the name of the paper...)
>
> Here are two proposals that I believe together cover all of your use case=
s
> for this feature, and all of mine:
>
> 1) 'inline' is permitted on variables. A variable marked 'inline' is an
> exact analogue of a function marked 'inline': definitions are permitted i=
n
> multiple translation units, so long as they follow [basic.def.odr]p6, and
> the program acts as if there is only one definition. The variable has
> unordered initialization.[1]
>
> 2) An expression alias declaration, 'static[opt] using *identifier* =3D
> *expression*;', is permitted. An id-expression that names an expression
> alias declaration has the same type and value as the alias's expression,
> and can be used in exactly the same contexts as that expression, and with
> the same meaning, except as otherwise indicated. Names within the
> expression are looked up, access checked, and bound in the context where
> the alias declaration appears. A non-static member expression alias
> declaration can contain references to 'this', and can only be referenced
> via a member access expression; its references to 'this' refer to the
> address of the object on which the alias is accessed.
>
> [1] We can do better here: we can say that the initialization of the
> variable is sequenced after the initialization of all earlier-defined
> variables in some TU in which it is defined, and sequenced before the
> initialization of all later-defined non-inline variables in every TU in
> which it is defined.
>
> On Mon, Sep 15, 2014 at 6:52 PM, David Krauss <potswa@gmail.com> wrote:
>
>>
>> On 2014=E2=80=9309=E2=80=9316, at 5:45 AM, Richard Smith <richard@metafo=
o.co.uk> wrote:
>>
>> Perhaps I'm misunderstanding your proposal, but I don't think that's the
>> case at all. In my proposed model,
>>
>> // foo.h
>> inline const char kStr[] =3D "blah";
>>
>> ... would guarantee to give the exact same object in all translation
>> units in which foo.h is included, just like an inline function, and yet
>> leave the definition of 'kStr' visible to the optimizer, to the compiler
>> frontend (to see the complete type of kStr), and so on. This is a
>> much-needed feature that your proposal does not appear to provide.
>>
>>
>> For that specific case of inline const char kStr[], yes, the intent is
>> that it should. The initializer of kStr has one value in every translati=
on
>> unit and the ODR guarantees the string literal to be the same object.
>> Evaluation yields a prvalue, but prvalues of ROMable objects ideally may
>> refer directly to ROM. This issue is mentioned in the last paragraph of
>> =C2=A72.2:
>>
>> Observable object identity for constants may be useful, though, for
>> global constexpr arrays and tables. If a weak linkage semantic is requir=
ed,
>> it might as well be accessible to the user. The questions of value
>> category, storage duration, and object identity for constant expressions
>> and temporaries are interesting, but outside the scope of and orthogonal=
to
>> this proposal.
>>
>> =E2=80=93=E2=80=93=E2=80=93
>>
>> I think the problem I have with using "inline variable" syntax for the
>> semantics you're proposing is threefold:
>> 1) What you get is not 'inline' in the way an inline function is (that
>> is, there is exactly one entity, you define it in every translation unit
>> that uses it, and those definitions get odr-merged together)
>>
>>
>> The linkage is *exactly* like inline functions. The difference is
>> evaluation, only in that there is no separation between the initializer
>> object and the return value of the (imaginary) inline function.
>>
>> What=E2=80=99s linked is a description of the expression, not the object
>> representation of the result.
>>
>> 2) What you get is not a variable (it's an alias to an expression instea=
d)
>>
>>
>> That=E2=80=99s still a name which evaluates to a reference or object. It=
=E2=80=99s not
>> identically an object, no.
>>
>> When you define an object, you need to decide when it should be
>> initialized. I don=E2=80=99t think unordered initialization is a very go=
od
>> solution, and neither on-demand (like local static objects) nor
>> on-definition (like usual non-const namespace scope objects) are always
>> appropriate either.
>>
>> I=E2=80=99d rather provide a means to access any object using a simple n=
ame, than
>> try to invent another universal solution to the static initialization or=
der
>> fiasco.
>>
>> What you're providing is *not* inline variables, it's expression aliases=
..
>>
>>
>> Expression aliases that are declared and behave like variables, perhaps
>> with definite type and value category.
>>
>> It=E2=80=99s as sane as a macro facility can get.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a1133375c79babe050349c5b4
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 W=
ed, Sep 17, 2014 at 2:42 PM, Richard Smith <span dir=3D"ltr"><<a href=3D=
"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</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">OK, I&=
#39;ve re-read the proposal, and I'm no longer sure what it is you'=
re proposing. In particular, you say:<div><br></div><div><div>"So that=
an inline constexpr variable may have backing storage and meaningful linka=
ge,=C2=A0</div><div>its initializer must evaluate to the same value at ever=
y use, no diagnostic required."</div></div><div><br></div><div>... whi=
ch breaks your use cases for 'errno' and 'stdout' (where th=
e value can change during the execution of the program, or between threads)=
..</div></div></blockquote><div><br></div><div>Please ignore this bit. I som=
ehow overlooked the 'constexpr' here.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>Your 'NULL' example d=
oesn't work in modern C++. Your bit_index has no need to be inline. So =
none of the use cases in 2.1 are served by your proposal.</div><div><br></d=
iv><div>I have been unable to comprehend what you're saying about when =
or how or how often the initializer for inline variables is run, so I can&#=
39;t tell if your proposal addresses the cases in 2.2. It would be helpful =
if you could clearly state some rules somewhere in the paper.</div><div><br=
></div><div>Ultimately, it looks like an 'expression alias' proposa=
l and an 'inline variable' proposal got conflated in here, and we&#=
39;ve ended up with a proposal that doesn't really do justice to either=
feature. (This is evident even in the name of the paper...)</div><div><br>=
</div><div>Here are two proposals that I believe together cover all of your=
use cases for this feature, and all of mine:</div><div><br></div><div>1) &=
#39;inline' is permitted on variables. A variable marked 'inline=
9; is an exact analogue of a function marked 'inline': definitions =
are permitted in multiple translation units, so long as they follow [basic.=
def.odr]p6, and the program acts as if there is only one definition. The va=
riable has unordered initialization.[1]</div><div><br></div><div>2) An expr=
ession alias declaration, 'static[opt] using <i>identifier</i> =3D <i>e=
xpression</i>;', is permitted. An id-expression that names an expressio=
n alias declaration has the same type and value as the alias's expressi=
on, and can be used in exactly the same contexts as that expression, and wi=
th the same meaning, except as otherwise indicated. Names within the expres=
sion are looked up, access checked, and bound in the context where the alia=
s declaration appears. A non-static member expression alias declaration can=
contain references to 'this', and can only be referenced via a mem=
ber access expression; its references to 'this' refer to the addres=
s of the object on which the alias is accessed.</div><div><br></div><div>[1=
] We can do better here: we can say that the initialization of the variable=
is sequenced after the initialization of all earlier-defined variables in =
some TU in which it is defined, and sequenced before the initialization of =
all later-defined non-inline variables in every TU in which it is defined.<=
/div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Mon, Sep 15, 2014 at 6:52 PM, David Kr=
auss <span dir=3D"ltr"><<a href=3D"mailto:potswa@gmail.com" target=3D"_b=
lank">potswa@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div style=3D"word-wrap:break-word"><br><div><span><div>On 2014=E2=80=
=9309=E2=80=9316, at 5:45 AM, Richard Smith <<a href=3D"mailto:richard@m=
etafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>> wrote:</div><=
br><blockquote type=3D"cite"><div style=3D"font-family:Helvetica;font-size:=
12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacin=
g:normal;line-height:normal;text-align:start;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px"><div dir=3D"ltr"><div class=3D"g=
mail_extra"><div class=3D"gmail_quote"><div>Perhaps I'm misunderstandin=
g your proposal, but I don't think that's the case at all. In my pr=
oposed model,</div><div><br></div><div>// foo.h</div><div>inline const char=
kStr[] =3D "blah";</div><div><br></div><div>... would guarantee =
to give the exact same object in all translation units in which foo.h is in=
cluded, just like an inline function, and yet leave the definition of '=
kStr' visible to the optimizer, to the compiler frontend (to see the co=
mplete type of kStr), and so on. This is a much-needed feature that your pr=
oposal does not appear to provide.</div></div></div></div></div></blockquot=
e><div><br></div></span><div>For that specific case of <font face=3D"Courie=
r">inline const char kStr[]</font>, yes, the intent is that it should. The =
initializer of kStr has one value in every translation unit and the ODR gua=
rantees the string literal to be the same object. Evaluation yields a prval=
ue, but prvalues of ROMable objects ideally may refer directly to ROM. This=
issue is mentioned in the last paragraph of =C2=A72.2:</div><div><br></div=
><div><blockquote type=3D"cite">Observable object identity for constants ma=
y be useful, though, for global=C2=A0constexpr=C2=A0arrays and tables. If a=
weak linkage semantic is required, it=C2=A0might as well be accessible to =
the user. The questions of value category, storage duration, and object ide=
ntity for constant expressions and temporaries=C2=A0are interesting, but ou=
tside the scope of and orthogonal to this proposal.<br></blockquote><div>=
=E2=80=93=E2=80=93=E2=80=93</div><br></div><span><blockquote type=3D"cite">=
<div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v=
ariant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;t=
ext-align:start;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div>I think the problem I have with using "inline variable&=
quot; syntax for the semantics you're proposing is threefold:</div><div=
>1) What you get is not 'inline' in the way an inline function is (=
that is, there is exactly one entity, you define it in every translation un=
it that uses it, and those definitions get odr-merged together)</div></div>=
</div></div></div></blockquote><div><br></div></span><div>The linkage is <i=
>exactly</i> like inline functions. The difference is evaluation, only in t=
hat there is no separation between the initializer object and the return va=
lue of the (imaginary) inline function.</div><div><br></div><div>What=E2=80=
=99s linked is a description of the expression, not the object representati=
on of the result.</div><span><br><blockquote type=3D"cite"><div style=3D"fo=
nt-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;fo=
nt-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;=
text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><d=
iv dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>2=
) What you get is not a variable (it's an alias to an expression instea=
d)</div></div></div></div></div></blockquote><div><br></div></span><div>Tha=
t=E2=80=99s still a name which evaluates to a reference or object. It=E2=80=
=99s not identically an object, no.</div><div><br></div><div>When you defin=
e an object, you need to decide when it should be initialized. I don=E2=80=
=99t think unordered initialization is a very good solution, and neither on=
-demand (like local <font face=3D"Courier">static</font> objects) nor on-de=
finition (like usual non-<font face=3D"Courier">const</font> namespace scop=
e objects) are always appropriate either.</div><div><br></div><div>I=E2=80=
=99d rather provide a means to access any object using a simple name, than =
try to invent another universal solution to the static initialization order=
fiasco.</div><span><br><blockquote type=3D"cite"><div style=3D"font-family=
:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight=
:normal;letter-spacing:normal;line-height:normal;text-align:start;text-inde=
nt:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir=3D=
"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>What you&#=
39;re providing is *not* inline variables, it's expression aliases.</di=
v></div></div></div></div></blockquote><div><br></div></span><div>Expressio=
n aliases that are declared and behave like variables, perhaps with definit=
e type and value category.</div></div><br><div>It=E2=80=99s as sane as a ma=
cro facility can get.</div><div><br></div></div><div><div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1133375c79babe050349c5b4--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 18 Sep 2014 07:40:45 +0800
Raw View
--Apple-Mail=_F7299E1A-EFFF-4E40-96A5-99106371A805
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-18, at 5:42 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> Your 'NULL' example doesn't work in modern C++.
NULL continues to do whatever it does, it just doesn't have to be a macro.
> Your bit_index has no need to be inline.
bit_index may be passed by reference from an inline function without causin=
g the function to violate the ODR, which currently happens because const in=
t globals are implicitly static, and hence different entities per TU.
> So none of the use cases in 2.1 are served by your proposal.
>=20
> I have been unable to comprehend what you're saying about when or how or =
how often the initializer for inline variables is run, so I can't tell if y=
our proposal addresses the cases in 2.2. It would be helpful if you could c=
learly state some rules somewhere in the paper.
It is run at every use of the name of the variable. I can clarify this in t=
he second paragraph of =A73.
A partial exception is made for constexpr variables, because "running" a co=
nstant expression should be done at compile time. In any case, evaluation o=
f the id-expression translates to evaluation of the initializer.
> Ultimately, it looks like an 'expression alias' proposal and an 'inline v=
ariable' proposal got conflated in here, and we've ended up with a proposal=
that doesn't really do justice to either feature. (This is evident even in=
the name of the paper...)
>=20
> Here are two proposals that I believe together cover all of your use case=
s for this feature, and all of mine:
>=20
> 1) 'inline' is permitted on variables. A variable marked 'inline' is an e=
xact analogue of a function marked 'inline': definitions are permitted in m=
ultiple translation units, so long as they follow [basic.def.odr]p6, and th=
e program acts as if there is only one definition. The variable has unorder=
ed initialization.[1]
But, unordered initialization is problematic, even with [1]. (Which, by the=
way, I've formally proposed, see below.) Often users want initialization u=
pon use instead, and that's also reasonable. Such a variable should be acce=
ssible without a function call, even in cases like that shown in =A72.3.
> 2) An expression alias declaration, 'static[opt] using identifier =3D exp=
ression;', is permitted. An id-expression that names an expression alias de=
claration has the same type and value as the alias's expression, and can be=
used in exactly the same contexts as that expression, and with the same me=
aning, except as otherwise indicated. Names within the expression are looke=
d up, access checked, and bound in the context where the alias declaration =
appears. A non-static member expression alias declaration can contain refer=
ences to 'this', and can only be referenced via a member access expression;=
its references to 'this' refer to the address of the object on which the a=
lias is accessed.
But, this carries many of the problems of macros. Aliases can't be defined =
with types, and if the user wants to guarantee that the result is read-only=
or lifetime-extendable, a cast is required. In the case of guaranteeing ex=
tendability, given the current lifetime extension rules, the necessary cast=
ing function is bizarre: it must return an xvalue given a prvalue, and a pr=
value given an xvalue. Anything else will cause unnecessary copies or dangl=
ing references.
Also, the ODR rule would need special extension to expression aliases. You =
have to either grant linkage to the aliases, which is unusual for a using-d=
eclaration, or check for token sequence equivalence at the point of instant=
iation, which makes them exactly like macros.
I've been tempted for a while to propose preprocessor macros that are scope=
d by (non-preprocessor) namespaces. Namespace declarations aren't too compl=
icated; a preprocessor can keep track of them. I plan to float the idea aro=
und at Urbana. Although I'm not too hopeful, there are things that only mac=
ros can do, and they're not going away in the foreseeable future.
> [1] We can do better here: we can say that the initialization of the vari=
able is sequenced after the initialization of all earlier-defined variables=
in some TU in which it is defined, and sequenced before the initialization=
of all later-defined non-inline variables in every TU in which it is defin=
ed.
This should be appearing in the next EWG issues edition:
> Two kinds of variables with static storage duration and non-static initia=
lization ([basic.start.init] =A73.6.2/2) may be defined in multiple TUs: st=
atic local variables in inline functions and class template static data mem=
bers. (Variable templates behave the same as the latter but this is not yet=
specified except perhaps by CWG DR.) The former are initialized upon execu=
tion of the declaration-statement, and the latter are "unordered." It is un=
safe to use a variable with unordered initialization before main() begins, =
or for an unordered initializer to use the value of anything with dynamic i=
nitialization. No diagnosis is required for such errors and implementations=
do not provide any, so this is a likely source of lurking bugs.
>=20
> It is currently UB to define one dynamically initialized variable templat=
e (or class template static member) in terms of another. More determinism w=
ould make unordered initializations much safer.
>=20
> Unordered initialization may be handled analogously to static locals: tre=
at the variable as if it were identical to a static local of an inline func=
tion, and treat the initializer as if it were a call to that function. The =
guard mutex required by this treatment is already likely to exist because t=
he current spec requires unordered initializations to happen exactly once u=
nder multithreading. There should be little if any ABI impact for conformin=
g implementations that may perform unordered initializations on separate th=
reads.
>=20
> In principle, unordered initializations would be dynamically sequenced by=
the mutexes, and ordered initializations would be ordered with the unorder=
ed initializations. So, it might be a good idea to change the term "unorder=
ed initialization."
>=20
> Suggested changes to [basic.start.init] =A73.6.2/2 (at the end of the par=
agraph):
>=20
> Variables with ordered initialization and uninitialized variables with un=
ordered initialization defined within a single translation unit shall be in=
itialized in the order of their definitions in the translation unit. If a p=
rogram starts a thread (30.3), the subsequent initialization of a variable =
is may be unsequenced with respect to the ordered initialization of a varia=
ble defined in a different translation unit. Otherwise, the initialization =
of a variable is may be indeterminately sequenced with respect to the initi=
alization of a different variable defined in a different translation unit. =
[Note: A variable with unordered initialization defined in the same transla=
tion unit may also be defined in a different translation unit.] If a progra=
m starts a thread, the subsequent unordered initialization of a variable is=
unsequenced with respect to every other dynamic initialization dynamic ini=
tializations that are not subsequent to the definition of that variable in =
any given translation unit. Otherwise, the unordered initialization of a va=
riable is indeterminately sequenced with respect to every other dynamic ini=
tialization.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_F7299E1A-EFFF-4E40-96A5-99106371A805
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–18, at 5:42 AM, Richard Smith <<a href=3D"mailto:richard@=
metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br><blockquote ty=
pe=3D"cite"><div dir=3D"ltr"><div>Your 'NULL' example doesn't work in moder=
n C++. </div></div></blockquote><div><br></div><div>NULL continues to do wh=
atever it does, it just doesn’t have to be a macro.</div><br><blockqu=
ote type=3D"cite"><div dir=3D"ltr"><div>Your bit_index has no need to be in=
line. </div></div></blockquote><div><br></div><div><font face=3D"Courier">b=
it_index</font> may be passed by reference from an inline function without =
causing the function to violate the ODR, which currently happens because <f=
ont face=3D"Courier">const int</font> globals are implicitly <font face=3D"=
Courier">static</font>, and hence different entities per TU.</div><br><bloc=
kquote type=3D"cite"><div dir=3D"ltr"><div>So none of the use cases in 2.1 =
are served by your proposal.</div><div><br></div><div>I have been unable to=
comprehend what you're saying about when or how or how often the initializ=
er for inline variables is run, so I can't tell if your proposal addresses =
the cases in 2.2. It would be helpful if you could clearly state some rules=
somewhere in the paper.</div></div></blockquote><div><br></div><div>It is =
run at every use of the name of the variable. I can clarify this in the sec=
ond paragraph of =A73.</div><div><br></div><div>A partial exception is made=
for constexpr variables, because “running” a constant expressi=
on should be done at compile time. In any case, evaluation of the id-expres=
sion translates to evaluation of the initializer.</div><br><blockquote type=
=3D"cite"><div dir=3D"ltr"><div>Ultimately, it looks like an 'expression al=
ias' proposal and an 'inline variable' proposal got conflated in here, and =
we've ended up with a proposal that doesn't really do justice to either fea=
ture. (This is evident even in the name of the paper...)</div><div><br></di=
v><div>Here are two proposals that I believe together cover all of your use=
cases for this feature, and all of mine:</div><div><br></div><div>1) 'inli=
ne' is permitted on variables. A variable marked 'inline' is an exact analo=
gue of a function marked 'inline': definitions are permitted in multiple tr=
anslation units, so long as they follow [basic.def.odr]p6, and the program =
acts as if there is only one definition. The variable has unordered initial=
ization.[1]</div></div></blockquote><div><br></div><div>But, unordered init=
ialization is problematic, even with [1]. (Which, by the way, I've formally=
proposed, see below.) Often users want initialization upon use instead, an=
d that’s also reasonable. Such a variable should be accessible withou=
t a function call, even in cases like that shown in =A72.3.</div><br><block=
quote type=3D"cite"><div dir=3D"ltr"><div>2) An expression alias declaratio=
n, 'static[opt] using <i>identifier</i> =3D <i>expression</i>;', is permitt=
ed. An id-expression that names an expression alias declaration has the sam=
e type and value as the alias's expression, and can be used in exactly the =
same contexts as that expression, and with the same meaning, except as othe=
rwise indicated. Names within the expression are looked up, access checked,=
and bound in the context where the alias declaration appears. A non-static=
member expression alias declaration can contain references to 'this', and =
can only be referenced via a member access expression; its references to 't=
his' refer to the address of the object on which the alias is accessed.</di=
v></div></blockquote><div><br></div><div>But, this carries many of the prob=
lems of macros. Aliases can’t be defined with types, and if the user =
wants to guarantee that the result is read-only or lifetime-extendable, a c=
ast is required. In the case of guaranteeing extendability, given the curre=
nt lifetime extension rules, the necessary casting function is bizarre: it =
must return an xvalue given a prvalue, and a prvalue given an xvalue. Anyth=
ing else will cause unnecessary copies or dangling references.</div><div><b=
r></div><div>Also, the ODR rule would need special extension to expression =
aliases. You have to either grant linkage to the aliases, which is unusual =
for a using-declaration, or check for token sequence equivalence at the poi=
nt of instantiation, which makes them exactly like macros.</div><div><br></=
div><div>I’ve been tempted for a while to propose preprocessor macros=
that are scoped by (non-preprocessor) namespaces. Namespace declarations a=
ren’t too complicated; a preprocessor can keep track of them. I plan =
to float the idea around at Urbana. Although I’m not too hopeful, the=
re are things that only macros can do, and they’re not going away in =
the foreseeable future.</div><div><br></div><br><blockquote type=3D"cite"><=
div dir=3D"ltr"><div>[1] We can do better here: we can say that the initial=
ization of the variable is sequenced after the initialization of all earlie=
r-defined variables in some TU in which it is defined, and sequenced before=
the initialization of all later-defined non-inline variables in every TU i=
n which it is defined.</div></div></blockquote><div><br></div><div>This sho=
uld be appearing in the next EWG issues edition:</div><div><br></div><div><=
blockquote type=3D"cite">Two kinds of variables with static storage duratio=
n and non-static initialization ([basic.start.init] =A73.6.2/2) may be defi=
ned in multiple TUs: static local variables in inline functions a=
nd class template static data members. (Variable templates behave the same =
as the latter but this is not yet specified except perhaps by CWG DR.) The =
former are initialized upon execution of the declaration-statement, and the=
latter are “unordered.” It is unsafe to use a variable with un=
ordered initialization before <font face=3D"Courier">main()</font>&nbs=
p;begins, or for an unordered initializer to use the value of anything with=
dynamic initialization. No diagnosis is required for such errors and imple=
mentations do not provide any, so this is a likely source of lurking bugs.<=
div><br></div><div>It is currently UB to define one dynamically initialized=
variable template (or class template static member) in terms of another. M=
ore determinism would make unordered initializations much safer.<div><br></=
div><div>Unordered initialization may be handled analogously to static loca=
ls: treat the variable as if it were identical to a static local of an inli=
ne function, and treat the initializer as if it were a call to that functio=
n. The guard mutex required by this treatment is already likely to exist be=
cause the current spec requires unordered initializations to happen exactly=
once under multithreading. There should be little if any ABI impact for co=
nforming implementations that may perform unordered initializations on sepa=
rate threads.</div><div><br></div><div>In principle, unordered initializati=
ons would be dynamically sequenced by the mutexes, and ordered initializati=
ons would be ordered with the unordered initializations. So, it might be a =
good idea to change the term “unordered initialization.”</div><=
div><br></div><div>Suggested changes to [basic.start.init] =A73.6.2/2 =
(at the end of the paragraph):</div><div><br></div><div>Variables with orde=
red initialization <b><font color=3D"#669c35">and uninitialized variab=
les with unordered initialization</font></b> defined within a single t=
ranslation unit shall be initialized in the order of their definitions=
in the translation unit. If a program starts a thread (30.3), the sub=
sequent initialization of a variable <font color=3D"#b51a00"><str=
ike>is</strike></font> <font color=3D"#669c35"><b>may be</b></font>&nb=
sp;unsequenced with respect to the <font color=3D"#669c35"><b>ordered<=
/b></font> initialization of a variable defined in a differe=
nt translation unit. Otherwise, the initialization of a variable =
<font color=3D"#b51a00"><strike>is</strike></font> <font color=3D"#669=
c35"><b>may be</b></font> indeterminately sequenced with respect to th=
e initialization of a <b style=3D"color: rgb(102, 156, 53);"=
>different</b> variable defined in a different translation unit. =
<font color=3D"#669c35"><b>[Note: A variable with unordered initialization =
defined in the same translation unit may also be defined in a different tra=
nslation unit.]</b></font> If a program starts a thread, the subsequen=
t unordered initialization of a variable is unsequenced with respect t=
o <font color=3D"#b51a00"><strike>every other dynamic initializat=
ion</strike></font> <font color=3D"#669c35"><b>dynamic initializations=
that are not subsequent to the definition of that variable in any giv=
en translation unit</b></font>. <font color=3D"#b51a00"><strike>O=
therwise, the unordered initialization of a variable is indeterminatel=
y sequenced with respect to every other dynamic initialization.</=
strike></font></div></div></blockquote><div><div><div><font color=3D"#b51a0=
0"><strike><br></strike></font></div></div></div></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_F7299E1A-EFFF-4E40-96A5-99106371A805--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 17 Sep 2014 20:31:23 -0700
Raw View
--001a11c257aa6c1fac05034e9e8b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Sep 17, 2014 at 4:40 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9309=E2=80=9318, at 5:42 AM, Richard Smith <richard@metafoo=
..co.uk> wrote:
>
> Your 'NULL' example doesn't work in modern C++.
>
>
> NULL continues to do whatever it does, it just doesn=E2=80=99t have to be=
a macro.
>
These days, NULL can't be a variable, it has to syntactically be an integer
literal. Unless you're proposing changing that, I don't see how you hope to
make this work.
> Your bit_index has no need to be inline.
>
>
> bit_index may be passed by reference from an inline function without
> causing the function to violate the ODR, which currently happens because =
const
> int globals are implicitly static, and hence different entities per TU.
>
> So none of the use cases in 2.1 are served by your proposal.
>
> I have been unable to comprehend what you're saying about when or how or
> how often the initializer for inline variables is run, so I can't tell if
> your proposal addresses the cases in 2.2. It would be helpful if you coul=
d
> clearly state some rules somewhere in the paper.
>
>
> It is run at every use of the name of the variable. I can clarify this in
> the second paragraph of =C2=A73.
>
> A partial exception is made for constexpr variables, because =E2=80=9Crun=
ning=E2=80=9D a
> constant expression should be done at compile time. In any case, evaluati=
on
> of the id-expression translates to evaluation of the initializer.
>
It would have certainly helped my comprehension to have had this stated
simply and directly somewhere. Having constexpr variables act differently
seems weird to me; why not just let implementors handle that under as-if?
This behavior is what I thought happened, and it reinforces for me the fact
that these things are not variables. For instance:
template<typename T> decltype(auto) foo(T &t) { return make_pair(t, t); }
auto a =3D make_pair(v, v);
auto b =3D foo(v);
If 'v' is a variable, 'a' and 'b' should have the same semantics (if both
compile). But this behavior makes perfect sense if 'v' is an expression
alias.
Also, if 'v' is a variable, then the id-expression 'v' is always an lvalue;
your "inline variables" are sometimes xvalues or prvalues. Again, they
don't behave like variables.
> Ultimately, it looks like an 'expression alias' proposal and an 'inline
> variable' proposal got conflated in here, and we've ended up with a
> proposal that doesn't really do justice to either feature. (This is evide=
nt
> even in the name of the paper...)
>
> Here are two proposals that I believe together cover all of your use case=
s
> for this feature, and all of mine:
>
> 1) 'inline' is permitted on variables. A variable marked 'inline' is an
> exact analogue of a function marked 'inline': definitions are permitted i=
n
> multiple translation units, so long as they follow [basic.def.odr]p6, and
> the program acts as if there is only one definition. The variable has
> unordered initialization.[1]
>
>
> But, unordered initialization is problematic, even with [1]. (Which, by
> the way, I've formally proposed, see below.) Often users want
> initialization upon use instead, and that=E2=80=99s also reasonable. Such=
a
> variable should be accessible without a function call, even in cases like
> that shown in =C2=A72.3.
>
I don't disagree, but I think you're going to end up with a very muddled
proposal if you try to fix all the problems all at once, and you're going
to end up with a proposal that is inconsistent with the existing language
if you only try to fix these problems for the new feature. I think it'd be
a much better idea to attack initialization order problems head-on and in
the general case rather than only dealing with it in this proposal.
That said, (1) would typically be used only in cases where the initializer
does not depend on the values of other globals (or at least, only depends
on prior ones in the same TU), as is common practice for successful use of
global initializers. That is, the cases that work, and that people use and
rely on today, continue to work fine. And if/when we improve the guarantees
via module dependency ordering, those improved guarantees would apply here
too.
> 2) An expression alias declaration, 'static[opt] using *identifier* =3D
> *expression*;', is permitted. An id-expression that names an expression
> alias declaration has the same type and value as the alias's expression,
> and can be used in exactly the same contexts as that expression, and with
> the same meaning, except as otherwise indicated. Names within the
> expression are looked up, access checked, and bound in the context where
> the alias declaration appears. A non-static member expression alias
> declaration can contain references to 'this', and can only be referenced
> via a member access expression; its references to 'this' refer to the
> address of the object on which the alias is accessed.
>
>
> But, this carries many of the problems of macros.
>
In what way is this different from what you're proposing?
Aliases can=E2=80=99t be defined with types, and if the user wants to guara=
ntee
> that the result is read-only or lifetime-extendable, a cast is required.
>
That's true, but what's the problem?
In the case of guaranteeing extendability, given the current lifetime
> extension rules, the necessary casting function is bizarre: it must retur=
n
> an xvalue given a prvalue, and a prvalue given an xvalue. Anything else
> will cause unnecessary copies or dangling references.
>
Can you demonstrate? Just casting to an rvalue reference should always
preserve extendability, per
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3918.html. Also,
if you created a prvalue, you typically know that you did so, so you don't
need a special mechanism to deal with this.
Also, the ODR rule would need special extension to expression aliases. You
> have to either grant linkage to the aliases, which is unusual for a
> using-declaration, or check for token sequence equivalence at the point o=
f
> instantiation, which makes them exactly like macros.
>
Sure, but they're safe, syntactically-valid, namespaced, hygienic macros --
exactly like in your proposal.
I=E2=80=99ve been tempted for a while to propose preprocessor macros that a=
re
> scoped by (non-preprocessor) namespaces. Namespace declarations aren=E2=
=80=99t too
> complicated; a preprocessor can keep track of them. I plan to float the
> idea around at Urbana. Although I=E2=80=99m not too hopeful, there are th=
ings that
> only macros can do, and they=E2=80=99re not going away in the foreseeable=
future.
>
Honestly, I don't imagine that any proposal to add new preprocessor
features will get much traction; especially not one that blurs the lines
between the phases of translation. If you think this is not too complicated
for the preprocessor, I think you underestimate just how dumb some
preprocessors are.
> [1] We can do better here: we can say that the initialization of the
> variable is sequenced after the initialization of all earlier-defined
> variables in some TU in which it is defined, and sequenced before the
> initialization of all later-defined non-inline variables in every TU in
> which it is defined.
>
>
> This should be appearing in the next EWG issues edition:
>
> Two kinds of variables with static storage duration and non-static
> initialization ([basic.start.init] =C2=A73.6.2/2) may be defined in multi=
ple
> TUs: static local variables in inline functions and class template static
> data members. (Variable templates behave the same as the latter but this =
is
> not yet specified except perhaps by CWG DR.) The former are initialized
> upon execution of the declaration-statement, and the latter are
> =E2=80=9Cunordered.=E2=80=9D It is unsafe to use a variable with unordere=
d initialization
> before main() begins, or for an unordered initializer to use the value of
> anything with dynamic initialization. No diagnosis is required for such
> errors and implementations do not provide any, so this is a likely source
> of lurking bugs.
>
> Clang has a sanitizer for this, see:
http://clang.llvm.org/docs/AddressSanitizer.html#initialization-order-check=
ing
> It is currently UB to define one dynamically initialized variable templat=
e
> (or class template static member) in terms of another. More determinism
> would make unordered initializations much safer.
>
> Unordered initialization may be handled analogously to static locals:
> treat the variable as if it were identical to a static local of an inline
> function, and treat the initializer as if it were a call to that function=
..
>
> What you just said is "the variable is initialized when its initializer
runs". You've not actually said when you want that to happen.
> The guard mutex required by this treatment is already likely to exist
> because the current spec requires unordered initializations to happen
> exactly once under multithreading. There should be little if any ABI impa=
ct
> for conforming implementations that may perform unordered initializations
> on separate threads.
>
> In principle, unordered initializations would be dynamically sequenced by
> the mutexes, and ordered initializations would be ordered with the
> unordered initializations. So, it might be a good idea to change the term
> =E2=80=9Cunordered initialization.=E2=80=9D
>
> OK, but *how* do you order the unordered initializations? Do you mean for
us to use the point of instantiation? Or the point of definition of the
template itself? Or initialize the variable on first use? Or something else=
?
> Suggested changes to [basic.start.init] =C2=A73.6.2/2 (at the end of the
> paragraph):
>
> Variables with ordered initialization *and uninitialized variables with
> unordered initialization* defined within a single translation unit shall
> be initialized in the order of their definitions in the translation unit.
>
> Uninitialized variables with unordered initialization have no dynamic
initialization anyway; they're handled in the zero-initialization phase,
and their lifetime begins at that point. Conversely, this puts impossible
restrictions on the destruction order for such variables (there may be
conflicting initialization orders in different TUs, and destruction
sequencing is defined as the reverse of initialization sequencing). Also,
see below wrt instantiation units.
> If a program starts a thread (30.3), the subsequent initialization of a
> variable is *may be* unsequenced with respect to the *ordered* initializa=
tion
> of a variable defined in a different translation unit. Otherwise, the
> initialization of a variable is *may be* indeterminately sequenced with
> respect to the initialization of a *different* variable defined in a
> different translation unit. *[Note: A variable with unordered
> initialization defined in the same translation unit may also be defined i=
n
> a different translation unit.]*
>
> I think you're trying to fix an unrelated wording issue(?), but I don't
think this is actually right: variables with unordered initialization are
template instantiations, and so are defined in instantiation units, not in
translation units; see phase 8 of translation.
> If a program starts a thread, the subsequent unordered initialization of =
a
> variable is unsequenced with respect to every other dynamic initializatio=
n
> *dynamic initializations that are not subsequent to the definition of
> that variable in any given translation unit*. Otherwise, the unordered
> initialization of a variable is indeterminately sequenced with respect
> to every other dynamic initialization.
>
> Per above comments, I think you need to say more than just "subsequent to
the definition of that variable" here.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c257aa6c1fac05034e9e8b
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 W=
ed, Sep 17, 2014 at 4:40 PM, David Krauss <span dir=3D"ltr"><<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div><sp=
an class=3D""><div>On 2014=E2=80=9309=E2=80=9318, at 5:42 AM, Richard Smith=
<<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@met=
afoo.co.uk</a>> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"lt=
r"><div>Your 'NULL' example doesn't work in modern C++. </div><=
/div></blockquote><div><br></div></span><div>NULL continues to do whatever =
it does, it just doesn=E2=80=99t have to be a macro.</div></div></div></blo=
ckquote><div><br></div><div>These days, NULL can't be a variable, it ha=
s to syntactically be an integer literal. Unless you're proposing chang=
ing that, I don't see how you hope to make this work.</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div style=3D"word-wrap:break-word"><div><span class=3D""><blockquote =
type=3D"cite"><div dir=3D"ltr"><div>Your bit_index has no need to be inline=
.. </div></div></blockquote><div><br></div></span><div><font face=3D"Courier=
">bit_index</font> may be passed by reference from an inline function witho=
ut causing the function to violate the ODR, which currently happens because=
<font face=3D"Courier">const int</font> globals are implicitly <font face=
=3D"Courier">static</font>, and hence different entities per TU.</div><span=
class=3D""><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>So none of =
the use cases in 2.1 are served by your proposal.</div><div><br></div><div>=
I have been unable to comprehend what you're saying about when or how o=
r how often the initializer for inline variables is run, so I can't tel=
l if your proposal addresses the cases in 2.2. It would be helpful if you c=
ould clearly state some rules somewhere in the paper.</div></div></blockquo=
te><div><br></div></span><div>It is run at every use of the name of the var=
iable. I can clarify this in the second paragraph of =C2=A73.</div><div><br=
></div><div>A partial exception is made for constexpr variables, because =
=E2=80=9Crunning=E2=80=9D a constant expression should be done at compile t=
ime. In any case, evaluation of the id-expression translates to evaluation =
of the initializer.</div></div></div></blockquote><div><br></div><div>It wo=
uld have certainly helped my comprehension to have had this stated simply a=
nd directly somewhere. Having constexpr variables act differently seems wei=
rd to me; why not just let implementors handle that under as-if?</div><div>=
<br></div><div>This behavior is what I thought happened, and it reinforces =
for me the fact that these things are not variables. For instance:</div><di=
v><br></div><div>=C2=A0 template<typename T> decltype(auto) foo(T &am=
p;t) { return make_pair(t, t); }</div><div>=C2=A0 auto a =3D make_pair(v, v=
);</div><div>=C2=A0 auto b =3D foo(v);</div><div><br></div><div>If 'v&#=
39; is a variable, 'a' and 'b' should have the same semanti=
cs (if both compile). But this behavior makes perfect sense if 'v' =
is an expression alias.</div><div><br></div><div>Also, if 'v' is a =
variable, then the id-expression 'v' is always an lvalue; your &quo=
t;inline variables" are sometimes xvalues or prvalues. Again, they don=
't behave like variables.</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wra=
p:break-word"><div><span class=3D""><blockquote type=3D"cite"><div dir=3D"l=
tr"><div>Ultimately, it looks like an 'expression alias' proposal a=
nd an 'inline variable' proposal got conflated in here, and we'=
ve ended up with a proposal that doesn't really do justice to either fe=
ature. (This is evident even in the name of the paper...)</div><div><br></d=
iv><div>Here are two proposals that I believe together cover all of your us=
e cases for this feature, and all of mine:</div><div><br></div><div>1) '=
;inline' is permitted on variables. A variable marked 'inline' =
is an exact analogue of a function marked 'inline': definitions are=
permitted in multiple translation units, so long as they follow [basic.def=
..odr]p6, and the program acts as if there is only one definition. The varia=
ble has unordered initialization.[1]</div></div></blockquote><div><br></div=
></span><div>But, unordered initialization is problematic, even with [1]. (=
Which, by the way, I've formally proposed, see below.) Often users want=
initialization upon use instead, and that=E2=80=99s also reasonable. Such =
a variable should be accessible without a function call, even in cases like=
that shown in =C2=A72.3.</div></div></div></blockquote><div><br></div><div=
>I don't disagree, but I think you're going to end up with a very m=
uddled proposal if you try to fix all the problems all at once, and you'=
;re going to end up with a proposal that is inconsistent with the existing =
language if you only try to fix these problems for the new feature. I think=
it'd be a much better idea to attack initialization order problems hea=
d-on and in the general case rather than only dealing with it in this propo=
sal.</div><div><br></div><div>That said, (1) would typically be used only i=
n cases where the initializer does not depend on the values of other global=
s (or at least, only depends on prior ones in the same TU), as is common pr=
actice for successful use of global initializers. That is, the cases that w=
ork, and that people use and rely on today, continue to work fine. And if/w=
hen we improve the guarantees via module dependency ordering, those improve=
d guarantees would apply here too.</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"word=
-wrap:break-word"><div><span class=3D""><blockquote type=3D"cite"><div dir=
=3D"ltr"><div>2) An expression alias declaration, 'static[opt] using <i=
>identifier</i> =3D <i>expression</i>;', is permitted. An id-expression=
that names an expression alias declaration has the same type and value as =
the alias's expression, and can be used in exactly the same contexts as=
that expression, and with the same meaning, except as otherwise indicated.=
Names within the expression are looked up, access checked, and bound in th=
e context where the alias declaration appears. A non-static member expressi=
on alias declaration can contain references to 'this', and can only=
be referenced via a member access expression; its references to 'this&=
#39; refer to the address of the object on which the alias is accessed.</di=
v></div></blockquote><div><br></div></span><div>But, this carries many of t=
he problems of macros.</div></div></div></blockquote><div><br></div><div>In=
what way is this different from what you're proposing?</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><div>Aliases=
can=E2=80=99t be defined with types, and if the user wants to guarantee th=
at the result is read-only or lifetime-extendable, a cast is required.</div=
></div></div></blockquote><div><br></div><div>That's true, but what'=
;s the problem?</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wra=
p:break-word"><div><div>In the case of guaranteeing extendability, given th=
e current lifetime extension rules, the necessary casting function is bizar=
re: it must return an xvalue given a prvalue, and a prvalue given an xvalue=
.. Anything else will cause unnecessary copies or dangling references.</div>=
</div></div></blockquote><div><br></div><div>Can you demonstrate? Just cast=
ing to an rvalue reference should always preserve extendability, per=C2=A0<=
a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3918.htm=
l">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3918.html</a>. =
Also, if you created a prvalue, you typically know that you did so, so you =
don't need a special mechanism to deal with this.</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div style=3D"word-wrap:break-word"><div><div>Also, the ODR=
rule would need special extension to expression aliases. You have to eithe=
r grant linkage to the aliases, which is unusual for a using-declaration, o=
r check for token sequence equivalence at the point of instantiation, which=
makes them exactly like macros.</div></div></div></blockquote><div><br></d=
iv><div>Sure, but they're safe, syntactically-valid, namespaced, hygien=
ic macros -- exactly like in your proposal.</div><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left=
:1ex"><div style=3D"word-wrap:break-word"><div><div>I=E2=80=99ve been tempt=
ed for a while to propose preprocessor macros that are scoped by (non-prepr=
ocessor) namespaces. Namespace declarations aren=E2=80=99t too complicated;=
a preprocessor can keep track of them. I plan to float the idea around at =
Urbana. Although I=E2=80=99m not too hopeful, there are things that only ma=
cros can do, and they=E2=80=99re not going away in the foreseeable future.<=
/div></div></div></blockquote><div><br></div><div>Honestly, I don't ima=
gine that any proposal to add new preprocessor features will get much tract=
ion; especially not one that blurs the lines between the phases of translat=
ion. If you think this is not too complicated for the preprocessor, I think=
you underestimate just how dumb some preprocessors are.<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div style=3D"word-wrap:break-word"><div><span class=3D""><blockquo=
te type=3D"cite"><div dir=3D"ltr"><div>[1] We can do better here: we can sa=
y that the initialization of the variable is sequenced after the initializa=
tion of all earlier-defined variables in some TU in which it is defined, an=
d sequenced before the initialization of all later-defined non-inline varia=
bles in every TU in which it is defined.</div></div></blockquote><div><br><=
/div></span><div>This should be appearing in the next EWG issues edition:</=
div><div><br></div><div><blockquote type=3D"cite">Two kinds of variables wi=
th static storage duration and non-static initialization ([basic.start.init=
] =C2=A73.6.2/2) may be defined in multiple TUs: static=C2=A0local=C2=A0var=
iables in inline functions and class template static data members. (Variabl=
e templates behave the same as the latter but this is not yet specified exc=
ept perhaps by CWG DR.) The former are initialized upon execution of the de=
claration-statement, and the latter are =E2=80=9Cunordered.=E2=80=9D It is =
unsafe to use a variable with unordered initialization before=C2=A0<font fa=
ce=3D"Courier">main()</font>=C2=A0begins, or for an unordered initializer t=
o use the value of anything with dynamic initialization. No diagnosis is re=
quired for such errors and implementations do not provide any, so this is a=
likely source of lurking bugs.</blockquote></div></div></div></blockquote>=
<div>Clang has a sanitizer for this, see:</div><div><br></div><div><a href=
=3D"http://clang.llvm.org/docs/AddressSanitizer.html#initialization-order-c=
hecking">http://clang.llvm.org/docs/AddressSanitizer.html#initialization-or=
der-checking</a></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word">=
<div><div><blockquote type=3D"cite"><div>It is currently UB to define one d=
ynamically initialized variable template (or class template static member) =
in terms of another. More determinism would make unordered initializations =
much safer.<div><br></div><div>Unordered initialization may be handled anal=
ogously to static locals: treat the variable as if it were identical to a s=
tatic local of an inline function, and treat the initializer as if it were =
a call to that function.</div></div></blockquote></div></div></div></blockq=
uote><div>What you just said is "the variable is initialized when its =
initializer runs". You've not actually said when you want that to =
happen.<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>=
<div><blockquote type=3D"cite"><div><div>The guard mutex required by this t=
reatment is already likely to exist because the current spec requires unord=
ered initializations to happen exactly once under multithreading. There sho=
uld be little if any ABI impact for conforming implementations that may per=
form unordered initializations on separate threads.</div><div><br></div><di=
v>In principle, unordered initializations would be dynamically sequenced by=
the mutexes, and ordered initializations would be ordered with the unorder=
ed initializations. So, it might be a good idea to change the term =E2=80=
=9Cunordered initialization.=E2=80=9D</div></div></blockquote></div></div><=
/div></blockquote><div>OK, but *how* do you order the unordered initializat=
ions? Do you mean for us to use the point of instantiation? Or the point of=
definition of the template itself? Or initialize the variable on first use=
? Or something else?</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><div><div><blockquote type=3D"cite"><div><div>Suggested changes to=C2=
=A0[basic.start.init] =C2=A73.6.2/2 (at the end of the paragraph):</div><di=
v><br></div><div>Variables with ordered initialization=C2=A0<b><font color=
=3D"#669c35">and uninitialized variables with unordered initialization</fon=
t></b>=C2=A0defined within a single translation unit shall be initialized i=
n the order=C2=A0of their definitions in the=C2=A0translation unit.</div></=
div></blockquote></div></div></div></blockquote><div>Uninitialized variable=
s with unordered initialization have no dynamic initialization anyway; they=
're handled in the zero-initialization phase, and their lifetime begins=
at that point. Conversely, this puts impossible restrictions on the destru=
ction order for such variables (there may be conflicting initialization ord=
ers in different TUs, and destruction sequencing is defined as the reverse =
of initialization sequencing). Also, see below wrt instantiation units.</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><div><blockquot=
e type=3D"cite"><div><div>If a program starts a thread (30.3), the subseque=
nt initialization=C2=A0of a variable=C2=A0<font color=3D"#b51a00"><strike>i=
s</strike></font>=C2=A0<font color=3D"#669c35"><b>may be</b></font>=C2=A0un=
sequenced with respect to the=C2=A0<font color=3D"#669c35"><b>ordered</b></=
font>=C2=A0initialization of a=C2=A0variable=C2=A0defined in a different tr=
anslation=C2=A0unit. Otherwise, the initialization of a variable=C2=A0<font=
color=3D"#b51a00"><strike>is</strike></font>=C2=A0<font color=3D"#669c35">=
<b>may be</b></font>=C2=A0indeterminately sequenced with respect to the=C2=
=A0initialization=C2=A0of a=C2=A0<b style=3D"color:rgb(102,156,53)">differe=
nt</b>=C2=A0variable defined in a different translation unit.=C2=A0<font co=
lor=3D"#669c35"><b>[Note: A variable with unordered initialization defined =
in the same translation unit may also be defined in a different translation=
unit.]</b></font></div></div></blockquote></div></div></div></blockquote><=
div>I think you're trying to fix an unrelated wording issue(?), but I d=
on't think this is actually right: variables with unordered initializat=
ion are template instantiations, and so are defined in instantiation units,=
not in translation units; see phase 8 of translation.</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
"><div style=3D"word-wrap:break-word"><div><div><blockquote type=3D"cite"><=
div><div>If a program starts a thread, the subsequent unordered=C2=A0initia=
lization of a variable is unsequenced with respect to=C2=A0<font color=3D"#=
b51a00"><strike>every other dynamic=C2=A0initialization</strike></font>=C2=
=A0<font color=3D"#669c35"><b>dynamic initializations=C2=A0that are not sub=
sequent to the definition of that variable in any given=C2=A0translation un=
it</b></font>.=C2=A0<font color=3D"#b51a00"><strike>Otherwise,=C2=A0the uno=
rdered initialization of a variable is indeterminately sequenced with respe=
ct to=C2=A0every other dynamic=C2=A0initialization.</strike></font></div></=
div></blockquote></div></div></div></blockquote><div>Per above comments, I =
think you need to say more than just "subsequent to the definition of =
that variable" here.</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c257aa6c1fac05034e9e8b--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 18 Sep 2014 14:12:09 +0800
Raw View
--Apple-Mail=_592C3BC9-2EC8-4194-A79C-AE42BBE5D1F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-18, at 11:31 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> These days, NULL can't be a variable, it has to syntactically be an integ=
er literal. Unless you're proposing changing that, I don't see how you hope=
to make this work.
Well, it will work for purposes aside from token pasting. NULL is allowed t=
o be parenthesized, so no conforming code can break. In any case, this isn'=
t exactly an essential part of the proposal's value proposition.
What I have specified is this:
> Copy-initialization of an inline variable object from a prvalue of the sa=
me type yields the initializer unadulterated
I would interpret this to preserve null pointer constants.
> A partial exception is made for constexpr variables, because "running" a =
constant expression should be done at compile time. In any case, evaluation=
of the id-expression translates to evaluation of the initializer.
>=20
> It would have certainly helped my comprehension to have had this stated s=
imply and directly somewhere. Having constexpr variables act differently se=
ems weird to me; why not just let implementors handle that under as-if?
inline constexpr variables may have concrete storage and weak linkage, like=
in your model. However, they still have the same evaluation semantics as o=
ther inline variables. The compiler does not need to allocate storage for e=
..g. std::piecewise_construct and generate a global variable address calcula=
tion when it's passed by reference. (But it may.)
For embedded MCU BSP headers, this is important because you don't want to a=
llocate storage for every #define SCC_ACK_BIT 5. However, for anything bigg=
er than a machine-word, the compiler should be free to make that decision.
I think, for constant values, user choice between inline constexpr with gua=
ranteed storage and an expression alias facility with guaranteed non-storag=
e would present a false dichotomy.
On the other hand, my proposal doesn't clearly provide for object identity =
in cases it might be needed. An inline constexpr reference initialized by a=
prvalue constant expression should do the trick nicely. I'll edit this in.
> This behavior is what I thought happened, and it reinforces for me the fa=
ct that these things are not variables. For instance:
>=20
> template<typename T> decltype(auto) foo(T &t) { return make_pair(t, t);=
}
> auto a =3D make_pair(v, v);
> auto b =3D foo(v);
>=20
> If 'v' is a variable, 'a' and 'b' should have the same semantics (if both=
compile). But this behavior makes perfect sense if 'v' is an expression al=
ias.
Yes, it's an expression alias, but with features that encourage it to be de=
clared and treated like a variable. The intent is that the user shouldn't a=
buse it for side effects (aside from on-demand initialization).
I do use the term "variable" a bit loosely, but I think it fits any name th=
at unsurprisingly resolves to a value (or lvalue).
> Also, if 'v' is a variable, then the id-expression 'v' is always an lvalu=
e; your "inline variables" are sometimes xvalues or prvalues. Again, they d=
on't behave like variables.
> But, unordered initialization is problematic, even with [1]. (Which, by t=
he way, I've formally proposed, see below.) Often users want initialization=
upon use instead, and that's also reasonable. Such a variable should be ac=
cessible without a function call, even in cases like that shown in =A72.3.
>=20
> I don't disagree, but I think you're going to end up with a very muddled =
proposal if you try to fix all the problems all at once, and you're going t=
o end up with a proposal that is inconsistent with the existing language if=
you only try to fix these problems for the new feature. I think it'd be a =
much better idea to attack initialization order problems head-on and in the=
general case rather than only dealing with it in this proposal.
>=20
> That said, (1) would typically be used only in cases where the initialize=
r does not depend on the values of other globals (or at least, only depends=
on prior ones in the same TU), as is common practice for successful use of=
global initializers. That is, the cases that work, and that people use and=
rely on today, continue to work fine. And if/when we improve the guarantee=
s via module dependency ordering, those improved guarantees would apply her=
e too.
[1] fails when the variable is used, e.g. by a member function of the class=
of which it's a static member, before its definition is processed.
It's nice that we're of one mind about mutex-ordered dynamic initialization=
, but it's hardly a sure thing at this point. Not only hasn't it been appro=
ved for suitability across implementations, but it's never been implemented=
and there's no real-world usage experience. The last thing I want is a new=
feature which handily exposes the existing unordered initialization semant=
ic.
Attacking the dynamic initialization issues is what I'm not doing. You're t=
he one who mentioned [1]; the question doesn't arise directly from my propo=
sal ;v) . I want to create something like expression aliases, except with t=
ype/category safety and the possibility of ROM storage. The user is redirec=
ted around unordered dynamic initialization and toward the existing static =
local boilerplate, because that's the known solution to the fiasco. This wa=
sn't my original intention, but it's what everything boiled down to, and I =
think it's the lowest-risk proposition.
And, nothing is on the table except the inline keyword in that particular c=
ontext. Once unordered initialization is fixed, a facility to easily expose=
it is only a bike-shed away.
>> 2) An expression alias declaration, 'static[opt] using identifier =3D ex=
pression;', is permitted. An id-expression that names an expression alias d=
eclaration has the same type and value as the alias's expression, and can b=
e used in exactly the same contexts as that expression, and with the same m=
eaning, except as otherwise indicated. Names within the expression are look=
ed up, access checked, and bound in the context where the alias declaration=
appears. A non-static member expression alias declaration can contain refe=
rences to 'this', and can only be referenced via a member access expression=
; its references to 'this' refer to the address of the object on which the =
alias is accessed.
>=20
> But, this carries many of the problems of macros.
>=20
> In what way is this different from what you're proposing?
Declared type, ability do declare that usage will behave as an l/rvalue, an=
d cooperation of the language to make that happen.
Object-like (well, value-like) macros are a source of bugs. Macro usage in =
C as OO accessors is seldom safer than direct member access. Accessors with=
declared type and category are more easily made read-only.
> Aliases can't be defined with types, and if the user wants to guarantee t=
hat the result is read-only or lifetime-extendable, a cast is required.
>=20
> That's true, but what's the problem?
>=20
> In the case of guaranteeing extendability, given the current lifetime ext=
ension rules, the necessary casting function is bizarre: it must return an =
xvalue given a prvalue, and a prvalue given an xvalue. Anything else will c=
ause unnecessary copies or dangling references.
>=20
> Can you demonstrate? Just casting to an rvalue reference should always pr=
eserve extendability, per http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2014/n3918.html.
static_cast< auto && >(...) might do the trick, but that's not allowed. Put=
ting the cast in a function voids the extension, unless it's defined as I d=
escribed, and even then it won't compose with itself. So the user is left n=
eeding to state the destination type, either by knowing it or by decltype r=
eduplication.
I think N3918 has some serious missteps, I don't think anything was gained =
by changing certain prvalues to xvalues, and so far as I've seen, only Clan=
g actually allows extension through such a cast. I'm starting to feel like =
I'll regret if I don't present a paper about this...
Can you give a realistic use case for lifetime extension through static_cas=
t to rvalue?
> Also, if you created a prvalue, you typically know that you did so, so yo=
u don't need a special mechanism to deal with this.
This simply isn't true. A function call may yield a prvalue or it may not. =
In general, the caller should be able to bind an auto && and assume the res=
ult stays alive. At the least, it should be possible to write interfaces ma=
intaining such a guarantee.
> Also, the ODR rule would need special extension to expression aliases. Yo=
u have to either grant linkage to the aliases, which is unusual for a using=
-declaration, or check for token sequence equivalence at the point of insta=
ntiation, which makes them exactly like macros.
>=20
> Sure, but they're safe, syntactically-valid, namespaced, hygienic macros =
-- exactly like in your proposal.
Almost. My proposal applies the ODR automatically, so a subroutine can be g=
enerated and linked without question. using declarations with linkage would=
be new.
> Honestly, I don't imagine that any proposal to add new preprocessor featu=
res will get much traction; especially not one that blurs the lines between=
the phases of translation. If you think this is not too complicated for th=
e preprocessor, I think you underestimate just how dumb some preprocessors =
are.
Quite likely so. But something's gotta give. It's worth a push.
---
>> Unordered initialization may be handled analogously to static locals: tr=
eat the variable as if it were identical to a static local of an inline fun=
ction, and treat the initializer as if it were a call to that function.
>=20
> What you just said is "the variable is initialized when its initializer r=
uns". You've not actually said when you want that to happen.
I meant, "execute the initializer as if it were a call to that function," i=
..e. in the __sinit function or equivalent for that TU, among the other init=
ializers being executed in lexical order.
>> The guard mutex required by this treatment is already likely to exist be=
cause the current spec requires unordered initializations to happen exactly=
once under multithreading. There should be little if any ABI impact for co=
nforming implementations that may perform unordered initializations on sepa=
rate threads.
>>=20
>> In principle, unordered initializations would be dynamically sequenced b=
y the mutexes, and ordered initializations would be ordered with the unorde=
red initializations. So, it might be a good idea to change the term "unorde=
red initialization."
>=20
> OK, but *how* do you order the unordered initializations? Do you mean for=
us to use the point of instantiation? Or the point of definition of the te=
mplate itself? Or initialize the variable on first use? Or something else?
>> Suggested changes to [basic.start.init] =A73.6.2/2 (at the end of the pa=
ragraph):
>>=20
>> Variables with ordered initialization and uninitialized variables with u=
nordered initialization defined within a single translation unit shall be i=
nitialized in the order of their definitions in the translation unit.
>=20
> Uninitialized variables with unordered initialization have no dynamic ini=
tialization anyway; they're handled in the zero-initialization phase, and t=
heir lifetime begins at that point.
Static initialization isn't part of this section. An object with no definit=
ion at all is an error.
Sorry it's unclear, what I meant is unordered variables that have not yet b=
een initialized, according to an associated mutex, are initialized along wi=
th other definitions in TU order. The existence of an initializer isn't in =
question, whether it has already executed is.
> Conversely, this puts impossible restrictions on the destruction order fo=
r such variables (there may be conflicting initialization orders in differe=
nt TUs, and destruction sequencing is defined as the reverse of initializat=
ion sequencing). Also, see below wrt instantiation units.
No harder than static locals. If a variable has been initialized, it's igno=
red by subsequent execution of its initializer in another TU.
TU order applies, unless the variable has already been initialized.
>> If a program starts a thread (30.3), the subsequent initialization of a =
variable is may be unsequenced with respect to the ordered initialization o=
f a variable defined in a different translation unit. Otherwise, the initia=
lization of a variable is may be indeterminately sequenced with respect to =
the initialization of a different variable defined in a different translati=
on unit. [Note: A variable with unordered initialization defined in the sam=
e translation unit may also be defined in a different translation unit.]
>=20
> I think you're trying to fix an unrelated wording issue(?), but I don't t=
hink this is actually right: variables with unordered initialization are te=
mplate instantiations, and so are defined in instantiation units, not in tr=
anslation units; see phase 8 of translation.
Nah, I'm just dancing around the fact that a variable initialization must b=
e sequenced with itself, without mentioning a mutex.
I didn't notice, but properly applying unordered initializations to variabl=
e templates does require at least s/translation unit/instantiation unit/, a=
nd instantiations of a given template are still unordered, leaving interdep=
endencies to still yield UB. Don't suppose that can be prevented. However, =
that's material for a CWG DR, not EWG. (I might have submitted such a DR, c=
an't recall.)
>> If a program starts a thread, the subsequent unordered initialization of=
a variable is unsequenced with respect to every other dynamic initializati=
on dynamic initializations that are not subsequent to the definition of tha=
t variable in any given translation unit. Otherwise, the unordered initiali=
zation of a variable is indeterminately sequenced with respect to every oth=
er dynamic initialization.
>=20
> Per above comments, I think you need to say more than just "subsequent to=
the definition of that variable" here.
Eh, for whatever reason, when I was writing the standardese I tried to be l=
azy and write the minimal textual changes. The result wasn't really optimal=
..
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_592C3BC9-2EC8-4194-A79C-AE42BBE5D1F9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–18, at 11:31 AM, Richard Smith <<a href=3D"mailto:richard=
@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite"><div style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font=
-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto=
; text-align: start; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><d=
iv dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>T=
hese days, NULL can't be a variable, it has to syntactically be an integer =
literal. Unless you're proposing changing that, I don't see how you hope to=
make this work.</div></div></div></div></div></blockquote><div><br></div><=
div>Well, it will work for purposes aside from token pasting. NULL is allow=
ed to be parenthesized, so no conforming code can break. In any case, this =
isn’t exactly an essential part of the proposal’s value proposi=
tion.</div><div><br></div><div>What I have specified is this:</div><div><bl=
ockquote type=3D"cite">Copy-initialization of an inline variable object fro=
m a prvalue of the same type yields the initializer unadulterated</blockquo=
te></div><div>I would interpret this to preserve null pointer constants.</d=
iv><div><br></div><blockquote type=3D"cite"><div style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-widt=
h: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; pa=
dding-left: 1ex; position: static; z-index: auto;"><div style=3D"word-wrap:=
break-word;"><span class=3D""><div>A partial exception is made for constex=
pr variables, because “running” a constant expression should be=
done at compile time. In any case, evaluation of the id-expression transla=
tes to evaluation of the initializer.</div></span></div></blockquote><div><=
br></div><div>It would have certainly helped my comprehension to have had t=
his stated simply and directly somewhere. Having constexpr variables act di=
fferently seems weird to me; why not just let implementors handle that unde=
r as-if?</div></div></div></div></div></blockquote><div><br></div><div>inli=
ne constexpr variables may have concrete storage and weak linkage, like in =
your model. However, they still have the same evaluation semantics as other=
inline variables. The compiler does not need to allocate storage for e.g.&=
nbsp;<font face=3D"Courier">std::piecewise_construct</font> and generate a =
global variable address calculation when it’s passed by reference. (B=
ut it may.)</div><div><br></div><div>For embedded MCU BSP headers, this is =
important because you don’t want to allocate storage for every <font =
face=3D"Courier">#define SCC_ACK_BIT 5</font>. However, for anything bigger=
than a machine-word, the compiler should be free to make that decision.</d=
iv><div><br></div><div>I think, for constant values, user choice between in=
line constexpr with guaranteed storage and an expression alias facility wit=
h guaranteed non-storage would present a false dichotomy.</div><div><br></d=
iv><div>On the other hand, my proposal doesn’t clearly provide for ob=
ject identity in cases it might be needed. An inline constexpr reference in=
itialized by a prvalue constant expression should do the trick nicely. I&rs=
quo;ll edit this in.</div><div><br></div><blockquote type=3D"cite"><div sty=
le=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; line-height: nor=
mal; orphans: auto; text-align: start; text-indent: 0px; text-transform: no=
ne; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stro=
ke-width: 0px;"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><div>This behavior is what I thought happened, and it reinforce=
s for me the fact that these things are not variables. For instance:</div><=
div><br></div><div> template<typename T> decltype(auto) foo(T &=
amp;t) { return make_pair(t, t); }</div><div> auto a =3D make_pair(v,=
v);</div><div> auto b =3D foo(v);</div><div><br></div><div>If 'v' is=
a variable, 'a' and 'b' should have the same semantics (if both compile). =
But this behavior makes perfect sense if 'v' is an expression alias.</div><=
/div></div></div></div></blockquote><div><br></div><div>Yes, it’s an =
expression alias, but with features that encourage it to be declared and tr=
eated like a variable. The intent is that the user shouldn’t abuse it=
for side effects (aside from on-demand initialization).</div><div><br></di=
v><div>I do use the term “variable” a bit loosely, but I think =
it fits any name that unsurprisingly resolves to a value (or lvalue).</div>=
<br><blockquote type=3D"cite"><div style=3D"font-family: Helvetica; font-si=
ze: 12px; font-style: normal; font-variant: normal; font-weight: normal; le=
tter-spacing: normal; line-height: normal; orphans: auto; text-align: start=
; text-indent: 0px; text-transform: none; white-space: normal; widows: auto=
; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div=
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Also, if 'v' is a va=
riable, then the id-expression 'v' is always an lvalue; your "inline variab=
les" are sometimes xvalues or prvalues. Again, they don't behave like varia=
bles.</div></div></div></div></div></blockquote><br><blockquote type=3D"cit=
e"><div style=3D"font-family: Helvetica; font-size: 12px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px;"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex; position: static; z-inde=
x: auto;"><div style=3D"word-wrap: break-word;"><div>But, unordered initial=
ization is problematic, even with [1]. (Which, by the way, I've formally pr=
oposed, see below.) Often users want initialization upon use instead, and t=
hat’s also reasonable. Such a variable should be accessible without a=
function call, even in cases like that shown in =A72.3.</div></div></block=
quote><div><br></div><div>I don't disagree, but I think you're going to end=
up with a very muddled proposal if you try to fix all the problems all at =
once, and you're going to end up with a proposal that is inconsistent with =
the existing language if you only try to fix these problems for the new fea=
ture. I think it'd be a much better idea to attack initialization order pro=
blems head-on and in the general case rather than only dealing with it in t=
his proposal.</div><div><br></div><div>That said, (1) would typically be us=
ed only in cases where the initializer does not depend on the values of oth=
er globals (or at least, only depends on prior ones in the same TU), as is =
common practice for successful use of global initializers. That is, the cas=
es that work, and that people use and rely on today, continue to work fine.=
And if/when we improve the guarantees via module dependency ordering, thos=
e improved guarantees would apply here too.</div></div></div></div></div></=
blockquote><div><br></div><div>[1] fails when the variable is used, e.g. by=
a member function of the class of which it’s a static member, before=
its definition is processed.</div><div><br></div><div>It’s nice that=
we’re of one mind about mutex-ordered dynamic initialization, but it=
’s hardly a sure thing at this point. Not only hasn’t it been a=
pproved for suitability across implementations, but it’s never been i=
mplemented and there’s no real-world usage experience. The last thing=
I want is a new feature which handily exposes the existing unordered initi=
alization semantic.</div><div><br></div><div>Attacking the dynamic initiali=
zation issues is what I’m <i>not</i> doing. You’re the one=
who mentioned [1]; the question doesn’t arise directly from my propo=
sal ;v) . I want to create something like expression aliases, except with t=
ype/category safety and the possibility of ROM storage. The user is redirec=
ted around unordered dynamic initialization and toward the existing static =
local boilerplate, because that’s the known solution to the fiasco. T=
his wasn’t my original intention, but it’s what everything boil=
ed down to, and I think it’s the lowest-risk proposition.</div><div><=
br></div><div>And, nothing is on the table except the <font face=3D"Courier=
">inline</font> keyword in that particular context. Once unordered initiali=
zation is fixed, a facility to easily expose it is only a bike-shed away.</=
div><br><blockquote type=3D"cite"><div style=3D"font-family: Helvetica; fon=
t-size: 12px; font-style: normal; font-variant: normal; font-weight: normal=
; letter-spacing: normal; line-height: normal; orphans: auto; text-align: s=
tart; text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bo=
rder-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left=
: 1ex;"><div style=3D"word-wrap: break-word;"><span class=3D""><blockquote =
type=3D"cite"><div dir=3D"ltr">2) An expression alias declaration, 'static[=
opt] using<span class=3D"Apple-converted-space"> </span><i>identifier<=
/i><span class=3D"Apple-converted-space"> </span>=3D<span class=3D"App=
le-converted-space"> </span><i>expression</i>;', is permitted. An id-e=
xpression that names an expression alias declaration has the same type and =
value as the alias's expression, and can be used in exactly the same contex=
ts as that expression, and with the same meaning, except as otherwise indic=
ated. Names within the expression are looked up, access checked, and bound =
in the context where the alias declaration appears. A non-static member exp=
ression alias declaration can contain references to 'this', and can only be=
referenced via a member access expression; its references to 'this' refer =
to the address of the object on which the alias is accessed.</div></blockqu=
ote><div><br></div></span><div>But, this carries many of the problems of ma=
cros.</div></div></blockquote><div><br></div><div>In what way is this diffe=
rent from what you're proposing?</div></div></div></div></div></blockquote>=
<div><br></div><div>Declared type, ability do declare that usage will behav=
e as an l/rvalue, and cooperation of the language to make that happen.</div=
><div><br></div><div>Object-like (well, value-like) macros are a source of =
bugs. Macro usage in C as OO accessors is seldom safer than direct member a=
ccess. Accessors with declared type and category are more easily made read-=
only.</div><br><blockquote type=3D"cite"><div style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width=
: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; pad=
ding-left: 1ex; position: static; z-index: auto;"><div style=3D"word-wrap: =
break-word;">Aliases can’t be defined with types, and if the user wan=
ts to guarantee that the result is read-only or lifetime-extendable, a cast=
is required.</div></blockquote><div><br></div><div>That's true, but what's=
the problem?</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: r=
gb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style=
=3D"word-wrap: break-word;">In the case of guaranteeing extendability, give=
n the current lifetime extension rules, the necessary casting function is b=
izarre: it must return an xvalue given a prvalue, and a prvalue given an xv=
alue. Anything else will cause unnecessary copies or dangling references.</=
div></blockquote><div><br></div><div>Can you demonstrate? Just casting to a=
n rvalue reference should always preserve extendability, per <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3918.html">htt=
p://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3918.html</a>. </div>=
</div></div></div></div></blockquote><div><br></div><div><font face=3D"Cour=
ier">static_cast< auto && >(…)</font> might do th=
e trick, but that’s not allowed. Putting the cast in a function voids=
the extension, unless it’s defined as I described, and even then it =
won’t compose with itself. So the user is left needing to state the d=
estination type, either by knowing it or by <font face=3D"Courier">decltype=
</font> reduplication.</div><div><br></div><div>I think N3918 has some seri=
ous missteps, I don’t think anything was gained by changing certain p=
rvalues to xvalues, and so far as I’ve seen, only Clang actually allo=
ws extension through such a cast. I’m starting to feel like I’l=
l regret if I don’t present a paper about this…</div><div><br>=
</div><div>Can you give a realistic use case for lifetime extension through=
<font face=3D"Courier">static_cast</font> to rvalue?</div><br><blockquote =
type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px; font-s=
tyle: normal; font-variant: normal; font-weight: normal; letter-spacing: no=
rmal; line-height: normal; orphans: auto; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><div>Also, if you created a prvalue, you =
typically know that you did so, so you don't need a special mechanism to de=
al with this.</div></div></div></div></div></blockquote><div><br></div><div=
>This simply isn’t true. A function call may yield a prvalue or it ma=
y not. In general, the caller should be able to bind an auto && and=
assume the result stays alive. At the least, it should be possible to writ=
e interfaces maintaining such a guarantee.</div><br><blockquote type=3D"cit=
e"><div style=3D"font-family: Helvetica; font-size: 12px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px;"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex; position: static; z-inde=
x: auto;"><div style=3D"word-wrap: break-word;">Also, the ODR rule would ne=
ed special extension to expression aliases. You have to either grant linkag=
e to the aliases, which is unusual for a using-declaration, or check for to=
ken sequence equivalence at the point of instantiation, which makes them ex=
actly like macros.</div></blockquote><div><br></div><div>Sure, but they're =
safe, syntactically-valid, namespaced, hygienic macros -- exactly like in y=
our proposal.</div></div></div></div></div></blockquote><div><br></div><div=
>Almost. My proposal applies the ODR automatically, so a subroutine can be =
generated and linked without question. <font face=3D"Courier">using</font> =
declarations with linkage would be new.</div><br><blockquote type=3D"cite">=
<div style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px;"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><div>Honestly, I don't imagine that any proposal to add=
new preprocessor features will get much traction; especially not one that =
blurs the lines between the phases of translation. If you think this is not=
too complicated for the preprocessor, I think you underestimate just how d=
umb some preprocessors are.<br></div></div></div></div></div></blockquote><=
div><br></div><div>Quite likely so. But something’s gotta give. It&rs=
quo;s worth a push.</div><div><br></div><div>–––</div><br=
><blockquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size:=
12px; font-style: normal; font-variant: normal; font-weight: normal; lette=
r-spacing: normal; line-height: normal; orphans: auto; text-align: start; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: auto; w=
ord-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-le=
ft-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; =
position: static; z-index: auto;"><div style=3D"word-wrap: break-word;"><sp=
an class=3D""><blockquote type=3D"cite"><div dir=3D"ltr">Unordered initiali=
zation may be handled analogously to static locals: treat the variable as i=
f it were identical to a static local of an inline function, and treat the =
initializer as if it were a call to that function.</div></blockquote></span=
></div></blockquote><div>What you just said is "the variable is initialized=
when its initializer runs". You've not actually said when you want that to=
happen.<br></div></div></div></div></div></blockquote><div><br></div><div>=
I meant, “execute the initializer as if it were a call to that functi=
on,” i.e. in the <font face=3D"Courier">__sinit</font> function or eq=
uivalent for that TU, among the other initializers being executed in lexica=
l order.</div><br><blockquote type=3D"cite"><div style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div di=
r=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-widt=
h: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; pa=
dding-left: 1ex; position: static; z-index: auto;"><div style=3D"word-wrap:=
break-word;"><blockquote type=3D"cite"><div>The guard mutex required by th=
is treatment is already likely to exist because the current spec requires u=
nordered initializations to happen exactly once under multithreading. There=
should be little if any ABI impact for conforming implementations that may=
perform unordered initializations on separate threads.</div><div><br></div=
><div>In principle, unordered initializations would be dynamically sequence=
d by the mutexes, and ordered initializations would be ordered with the uno=
rdered initializations. So, it might be a good idea to change the term &ldq=
uo;unordered initialization.”</div></blockquote></div></blockquote><d=
iv>OK, but *how* do you order the unordered initializations? Do you mean fo=
r us to use the point of instantiation? Or the point of definition of the t=
emplate itself? Or initialize the variable on first use? Or something else?=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left=
-style: solid; padding-left: 1ex;"><div style=3D"word-wrap: break-word;"><b=
lockquote type=3D"cite"><div>Suggested changes to [basic.start.init] =
=A73.6.2/2 (at the end of the paragraph):</div><div><br></div><div>Variable=
s with ordered initialization <b><font color=3D"#669c35">and uninitial=
ized variables with unordered initialization</font></b> defined within=
a single translation unit shall be initialized in the order of their =
definitions in the translation unit.</div></blockquote></div></blockqu=
ote><div>Uninitialized variables with unordered initialization have no dyna=
mic initialization anyway; they're handled in the zero-initialization phase=
, and their lifetime begins at that point. </div></div></div></div></div></=
blockquote><div><br></div><div>Static initialization isn’t part of th=
is section. An object with no definition at all is an error.</div><div><br>=
</div><div>Sorry it’s unclear, what I meant is unordered variables th=
at have not <i>yet</i> been initialized, according to an associated mutex, =
are initialized along with other definitions in TU order. The existence of =
an initializer isn’t in question, whether it has already executed is.=
</div><br><blockquote type=3D"cite"><div style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr=
"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Conversely, th=
is puts impossible restrictions on the destruction order for such variables=
(there may be conflicting initialization orders in different TUs, and dest=
ruction sequencing is defined as the reverse of initialization sequencing).=
Also, see below wrt instantiation units.</div></div></div></div></div></bl=
ockquote><div><br></div><div>No harder than static locals. If a variable ha=
s been initialized, it’s ignored by subsequent execution of its initi=
alizer in another TU.</div><div><br></div><div>TU order applies, unless the=
variable has already been initialized.</div><br><blockquote type=3D"cite">=
<div style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei=
ght: normal; orphans: auto; text-align: start; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-t=
ext-stroke-width: 0px;"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204=
); border-left-style: solid; padding-left: 1ex; position: static; z-index: =
auto;"><div style=3D"word-wrap: break-word;"><blockquote type=3D"cite">If a=
program starts a thread (30.3), the subsequent initialization of a va=
riable <font color=3D"#b51a00"><strike>is</strike></font> <font c=
olor=3D"#669c35"><b>may be</b></font> unsequenced with respect to the&=
nbsp;<font color=3D"#669c35"><b>ordered</b></font> initialization of a=
variable defined in a different translation unit. Otherwise=
, the initialization of a variable <font color=3D"#b51a00"><strike>is<=
/strike></font> <font color=3D"#669c35"><b>may be</b></font> inde=
terminately sequenced with respect to the initialization of a&nbs=
p;<b style=3D"color: rgb(102, 156, 53);">different</b> variable define=
d in a different translation unit. <font color=3D"#669c35"><b>[Note: A=
variable with unordered initialization defined in the same translation uni=
t may also be defined in a different translation unit.]</b></font></blockqu=
ote></div></blockquote><div>I think you're trying to fix an unrelated wordi=
ng issue(?), but I don't think this is actually right: variables with unord=
ered initialization are template instantiations, and so are defined in inst=
antiation units, not in translation units; see phase 8 of translation.</div=
></div></div></div></div></blockquote><div><br></div><div>Nah, I’m ju=
st dancing around the fact that a variable initialization must be sequenced=
with itself, without mentioning a mutex.</div><div><br></div><div>I didn&r=
squo;t notice, but properly applying unordered initializations to variable =
templates does require at least s/translation unit/instantiation unit/, and=
instantiations of a given template are still unordered, leaving interdepen=
dencies to still yield UB. Don’t suppose that can be prevented. Howev=
er, that’s material for a CWG DR, not EWG. (I might have submitted su=
ch a DR, can’t recall.)</div><br><blockquote type=3D"cite"><div style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-=
left-style: solid; padding-left: 1ex;"><div style=3D"word-wrap: break-word;=
"><blockquote type=3D"cite">If a program starts a thread, the subsequent un=
ordered initialization of a variable is unsequenced with respect to&nb=
sp;<font color=3D"#b51a00"><strike>every other dynamic initialization<=
/strike></font> <font color=3D"#669c35"><b>dynamic initializations&nbs=
p;that are not subsequent to the definition of that variable in any given&n=
bsp;translation unit</b></font>. <font color=3D"#b51a00"><strike>Other=
wise, the unordered initialization of a variable is indeterminately se=
quenced with respect to every other dynamic initialization.</stri=
ke></font></blockquote></div></blockquote><div>Per above comments, I think =
you need to say more than just "subsequent to the definition of that variab=
le" here.</div></div></div></div></div></blockquote><div><br></div><div>Eh,=
for whatever reason, when I was writing the standardese I tried to be lazy=
and write the minimal textual changes. The result wasn’t really opti=
mal.</div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_592C3BC9-2EC8-4194-A79C-AE42BBE5D1F9--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 18 Sep 2014 14:54:59 +0800
Raw View
--Apple-Mail=_1756FEBA-A27E-4B23-9283-DB93EBA9FABF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-18, at 2:12 PM, David Krauss <potswa@gmail.com> wrote:
> And, nothing is on the table except the inline keyword in that particular=
context. Once unordered initialization is fixed, a facility to easily expo=
se it is only a bike-shed away.
By the way, your proposal for inline object linkage might not require new s=
yntax at all. I can work within the space of programs that are ill-formed d=
ue to multiple, but identical, definitions.
Performing dynamic multiple initialization once requires a mutex, but that'=
s the only implementation difference from the current ODR semantics. If the=
ODR is relaxed to allow any object to have identical definitions per TU, t=
hen a naive compiler can simply add a mutex for each dynamic initialization=
(shouldn't be too much overhead), and a better compiler can strip any such=
locking which only appertains to one TU.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_1756FEBA-A27E-4B23-9283-DB93EBA9FABF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–18, at 2:12 PM, David Krauss <<a href=3D"mailto:potswa@gm=
ail.com">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><span style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;">And, nothing is on the table except the<span cl=
ass=3D"Apple-converted-space"> </span></span><font face=3D"Courier" st=
yle=3D"font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">inline<=
/font><span style=3D"font-family: Helvetica; font-size: 12px; font-style: n=
ormal; font-variant: normal; font-weight: normal; letter-spacing: normal; l=
ine-height: normal; orphans: auto; text-align: start; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -w=
ebkit-text-stroke-width: 0px; float: none; display: inline !important;"><sp=
an class=3D"Apple-converted-space"> </span>keyword in that particular =
context. Once unordered initialization is fixed, a facility to easily expos=
e it is only a bike-shed away.</span><br class=3D"Apple-interchange-newline=
"></blockquote></div><br><div>By the way, your proposal for inline object l=
inkage might not require new syntax at all. I can work within the space of =
programs that are ill-formed due to multiple, but identical, definitions.</=
div><div><br></div><div>Performing dynamic multiple initialization once req=
uires a mutex, but that’s the only implementation difference from the=
current ODR semantics. If the ODR is relaxed to allow any object to have i=
dentical definitions per TU, then a naive compiler can simply add a mutex f=
or each dynamic initialization (shouldn’t be too much overhead), and =
a better compiler can strip any such locking which only appertains to one T=
U.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_1756FEBA-A27E-4B23-9283-DB93EBA9FABF--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 24 Sep 2014 13:54:13 -0700 (PDT)
Raw View
------=_Part_879_1473068024.1411592053655
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It seems to me that a new form of "using" could be a more appropriate=20
keyword to use than inline in this case. The form could be:
class MyClass {
public:
using property =3D getter();
private:
int& getter();
};
I hope you are thinking along the lines (as exemplified above) that if the=
=20
aliased function returns an lvalue it can be assigned to. While this does=
=20
not allow detection of assignment (without using a proxy) it would be=20
logical and useful in some circumstances.
I recently came across a need to mimic the float3 "magical" struct that=20
Microsoft offers in GPU shaders in C++. While this struct has the usual=20
x,y,z members it also has pseudo members xy, yz and even xz. I just mention=
=20
this as food for thought as it would be an additional benefit if a pseudo=
=20
xz could be implemented that could be assigned from any float2.
A similar need which is very common in graphics and image processing is to=
=20
alias an array with discrete members so that you can both use point.x and=
=20
point[0] to reach the same value. This can be done today using a union but=
=20
this is quite a scary operation and can't be done if you want to inherit=20
like in:
struct Point : public std::array<int ,3> {
using x =3D operator[](0);
...
};
Of course the selection of keyword is not the big thing here, but rather to=
=20
show that aliasing between member names, not just between members and=20
methods has value. Also note in the second case that x is an alias name for=
=20
calling a method with a fixed parameter. For this particular case a=20
constexpr parameter works but I can imagine cases like "current" in some=20
data structure where access to members within the parameter expressions=20
would be beneficial.
Maybe using using is risky as it has so many interpretations already?
Den torsdagen den 18:e september 2014 kl. 08:58:11 UTC+2 skrev David Krauss=
:
>
>
> On 2014=E2=80=9309=E2=80=9318, at 2:12 PM, David Krauss <pot...@gmail.com=
<javascript:>>=20
> wrote:
>
> And, nothing is on the table except the inline keyword in that particular=
=20
> context. Once unordered initialization is fixed, a facility to easily=20
> expose it is only a bike-shed away.
>
>
> By the way, your proposal for inline object linkage might not require new=
=20
> syntax at all. I can work within the space of programs that are ill-forme=
d=20
> due to multiple, but identical, definitions.
>
> Performing dynamic multiple initialization once requires a mutex, but=20
> that=E2=80=99s the only implementation difference from the current ODR se=
mantics.=20
> If the ODR is relaxed to allow any object to have identical definitions p=
er=20
> TU, then a naive compiler can simply add a mutex for each dynamic=20
> initialization (shouldn=E2=80=99t be too much overhead), and a better com=
piler can=20
> strip any such locking which only appertains to one TU.
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_879_1473068024.1411592053655
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It seems to me that a new form of "using" could be a more =
appropriate keyword to use than inline in this case. The form could be:<div=
><br></div><div>class MyClass {</div><div>public:</div><div> u=
sing property =3D getter();</div><div><br></div><div>private:</div><div>&nb=
sp; int& getter();</div><div>};</div><div><br></div><div>I hope =
you are thinking along the lines (as exemplified above) that if the aliased=
function returns an lvalue it can be assigned to. While this does not allo=
w detection of assignment (without using a proxy) it would be logical and u=
seful in some circumstances.</div><div><br></div><div>I recently came acros=
s a need to mimic the float3 "magical" struct that Microsoft offers in GPU =
shaders in C++. While this struct has the usual x,y,z members it also has p=
seudo members xy, yz and even xz. I just mention this as food for thought a=
s it would be an additional benefit if a pseudo xz could be implemented tha=
t could be assigned from any float2.</div><div><br></div><div>A similar nee=
d which is very common in graphics and image processing is to alias an arra=
y with discrete members so that you can both use point.x and point[0] to re=
ach the same value. This can be done today using a union but this is quite =
a scary operation and can't be done if you want to inherit like in:</div><d=
iv><br></div><div>struct Point : public std::array<int ,3> {</div><di=
v> using x =3D operator[](0);</div><div> &n=
bsp;...</div><div>};</div><div><br></div><div>Of course the selection of ke=
yword is not the big thing here, but rather to show that aliasing between m=
ember names, not just between members and methods has value. Also note in t=
he second case that x is an alias name for calling a method with a fixed pa=
rameter. For this particular case a constexpr parameter works but I can ima=
gine cases like "current" in some data structure where access to members wi=
thin the parameter expressions would be beneficial.</div><div><br>Maybe usi=
ng using is risky as it has so many interpretations already?<br><br>Den tor=
sdagen den 18:e september 2014 kl. 08:58:11 UTC+2 skrev David Krauss:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word">=
<br><div><div>On 2014=E2=80=9309=E2=80=9318, at 2:12 PM, David Krauss <<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"rw5Rd9g6a=
CkJ" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">pot...@gmail.com</a>> wrote:</div><b=
r><blockquote type=3D"cite"><span style=3D"font-family:Helvetica;font-size:=
12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacin=
g:normal;line-height:normal;text-align:start;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px;float:none;display:inline!importa=
nt">And, nothing is on the table except the<span> </span></span><font =
face=3D"Courier" style=3D"font-size:12px;font-style:normal;font-variant:nor=
mal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:=
start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px">inline</font><span style=3D"font-family:Helvetica;font-size:12px;font-s=
tyle:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;li=
ne-height:normal;text-align:start;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px;float:none;display:inline!important"><span>&=
nbsp;</span>keyword in that particular context. Once unordered initializati=
on is fixed, a facility to easily expose it is only a bike-shed away.</span=
><br></blockquote></div><br><div>By the way, your proposal for inline objec=
t linkage might not require new syntax at all. I can work within the space =
of programs that are ill-formed due to multiple, but identical, definitions=
..</div><div><br></div><div>Performing dynamic multiple initialization once =
requires a mutex, but that=E2=80=99s the only implementation difference fro=
m the current ODR semantics. If the ODR is relaxed to allow any object to h=
ave identical definitions per TU, then a naive compiler can simply add a mu=
tex for each dynamic initialization (shouldn=E2=80=99t be too much overhead=
), and a better compiler can strip any such locking which only appertains t=
o one TU.</div><div><br></div></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_879_1473068024.1411592053655--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 25 Sep 2014 08:28:14 +0800
Raw View
--Apple-Mail=_FDA106C1-935D-44B6-8D8E-A92A0C7556CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-25, at 4:54 AM, Bengt Gustafsson <bengt.gustafsson@beamways.com>=
wrote:
> It seems to me that a new form of "using" could be a more appropriate key=
word to use than inline in this case.
I've updated the paper, now it has a section on this topic. (It's the final=
draft now.) The same link should work: http://bit.ly/1qTSBiP
> Of course the selection of keyword is not the big thing here, but rather =
to show that aliasing between member names, not just between members and me=
thods has value.
Nobody's yet proposed to allow that exactly, it would suggest aliasing memb=
er functions like
using getter2 =3D getter;
Function aliasing without forwarding or function reference type does get pr=
oposed occasionally...
> Also note in the second case that x is an alias name for calling a method=
with a fixed parameter. For this particular case a constexpr parameter wor=
ks but I can imagine cases like "current" in some data structure where acce=
ss to members within the parameter expressions would be beneficial.
> Maybe using using is risky as it has so many interpretations already?
There is an MVP issue. I didn't remember to mention so in the paper.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_FDA106C1-935D-44B6-8D8E-A92A0C7556CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–25, at 4:54 AM, Bengt Gustafsson <<a href=3D"mailto:bengt=
..gustafsson@beamways.com">bengt.gustafsson@beamways.com</a>> wrote:</div=
><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=
=3D"ltr">It seems to me that a new form of "using" could be a more appropri=
ate keyword to use than inline in this case.</div></blockquote><div><br></d=
iv><div>I’ve updated the paper, now it has a section on this topic. (=
It’s the final draft now.) The same link should work: <a href=3D=
"http://bit.ly/1qTSBiP" class=3D"bitmark-shortlink"><span class=3D"protocol=
">http://</span>bit.ly/1qTSBiP</a></div><div><br></div><blockquote type=3D"=
cite"><div dir=3D"ltr"><div>Of course the selection of keyword is not the b=
ig thing here, but rather to show that aliasing between member names, not j=
ust between members and methods has value. </div></div></blockquote><div><b=
r></div><div>Nobody’s yet proposed to allow that exactly, it would su=
ggest aliasing member functions like</div><div><br></div><div><font face=3D=
"Courier">using getter2 =3D getter;</font></div><div><br></div><div>Functio=
n aliasing without forwarding or function reference type does get proposed =
occasionally…</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><d=
iv>Also note in the second case that x is an alias name for calling a metho=
d with a fixed parameter. For this particular case a constexpr parameter wo=
rks but I can imagine cases like "current" in some data structure where acc=
ess to members within the parameter expressions would be beneficial.</div><=
/div></blockquote><blockquote type=3D"cite"><div dir=3D"ltr"><div>Maybe usi=
ng using is risky as it has so many interpretations already?<br></div></div=
></blockquote><div><br></div><div>There is an MVP issue. I didn’t rem=
ember to mention so in the paper.</div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_FDA106C1-935D-44B6-8D8E-A92A0C7556CA--
.