Topic: Allow constexpr static data members in a
Author: Avi Kivity <avi@scylladb.com>
Date: Sun, 26 Mar 2017 17:49:16 +0300
Raw View
This is a multi-part message in MIME format.
--------------A9BDFBD26DF6F56B77F8A6FF
Content-Type: text/plain; charset=UTF-8; format=flowed
On 03/26/2017 05:35 PM, Nicol Bolas wrote:
> On Sunday, March 26, 2017 at 10:30:29 AM UTC-4, Avi Kivity wrote:
>
> Consider this type-safe bool class:
>
>
> template <typename Tag>
>
> class bool_class {
>
> bool _value;
>
> public:
>
> explicit constexpr bool_class(bool v) noexcept : _value(v) {}
>
> // more emulation of bool
>
> static constexpr bool_class yes = bool_class{true};
>
> static constexpr bool_class no = bool_class{true};
>
> };
>
>
> Compilation fails, I believe rightly, on clang, because by the
> time yes
> and no are parsed, bool_class is an incomplete type, and therefore
> not a
> literal type. It could be worked around by making yes and no
> functions.
>
> Should we make this legal? It seems reasonable for types to offer
> constants scoped under their own name, and if they are literal types,
> that these constants can be constexpr.
>
>
> How does it seem reasonable to define variables of a type that has not
> yet been defined?
You can do that already, within an inline member function.
> What's wrong with defining them outside of the scope of the class?
>
You have to invent a scope for them.
Perhaps
template <typename Tag>
class bool_class {
bool _value;
public:
explicit constexpr bool_class(bool v) noexcept : _value(v) {}
// more emulation of bool
struct constants;
};
template <typenamer Tag>
struct bool_class<Tag>::constants {
static constexpr bool_class yes = bool_class{true};
static constexpr bool_class no = bool_class{true};
};
But using them is awkward and artificial.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b9d7e28d-325b-b760-e021-ef087d0b56f3%40scylladb.com.
--------------A9BDFBD26DF6F56B77F8A6FF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 03/26/2017 05:35 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote
cite=3D"mid:470f86cc-36b7-4244-82dd-b795af107996@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On Sunday, March 26, 2017 at 10:30:29 AM UTC-4, Avi
Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Consider
this type-safe bool class:
<br>
<br>
<br>
=C2=A0 =C2=A0template <typename Tag>
<br>
<br>
=C2=A0 =C2=A0class bool_class {
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0bool _value;
<br>
<br>
=C2=A0 =C2=A0public:
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0explicit constexpr bool_class(bool v) =
noexcept :
_value(v) {}
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0// more emulation of bool
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0static constexpr bool_class yes =3D bo=
ol_class{true};
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0static constexpr bool_class no =3D boo=
l_class{true};
<br>
<br>
=C2=A0 =C2=A0};
<br>
<br>
<br>
Compilation fails, I believe rightly, on clang, because by the
time yes <br>
and no are parsed, bool_class is an incomplete type, and
therefore not a <br>
literal type. =C2=A0It could be worked around by making yes and n=
o
functions.
<br>
<br>
Should we make this legal? =C2=A0It seems reasonable for types to
offer <br>
constants scoped under their own name, and if they are literal
types, <br>
that these constants can be constexpr.<br>
</blockquote>
<div><br>
How does it seem reasonable to define variables of a type that
has not yet been defined? </div>
</div>
</blockquote>
<br>
<br>
You can do that already, within an inline member function.<br>
<br>
<blockquote
cite=3D"mid:470f86cc-36b7-4244-82dd-b795af107996@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>What's wrong with defining them outside of the scope of the
class?<br>
</div>
</div>
<br>
</blockquote>
<br>
You have to invent a scope for them.<br>
<br>
Perhaps<br>
<br>
=C2=A0=C2=A0 template <typename Tag><br>
<br>
=C2=A0=C2=A0 class bool_class {<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bool _value;<br>
<br>
=C2=A0=C2=A0 public:<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 explicit constexpr bool_class(bool=
v) noexcept : _value(v) {}<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // more emulation of bool<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct constants;<br>
<br>
=C2=A0=C2=A0 }; <br>
<br>
<br>
=C2=A0=C2=A0 template <typenamer Tag><br>
=C2=A0=C2=A0 struct bool_class<Tag>::constants {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 static constexpr bool_class yes =
=3D bool_class{true};<br>
<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 static constexpr bool_class no =3D=
bool_class{true};<br>
=C2=A0=C2=A0 };<br>
<br>
But using them is awkward and artificial.<br>
<br>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b9d7e28d-325b-b760-e021-ef087d0b56f3%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/b9d7e28d-325b-b760-e021-ef087d0b56=
f3%40scylladb.com</a>.<br />
--------------A9BDFBD26DF6F56B77F8A6FF--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 26 Mar 2017 08:22:32 -0700 (PDT)
Raw View
------=_Part_4926_1196441680.1490541753038
Content-Type: multipart/alternative;
boundary="----=_Part_4927_582499589.1490541753038"
------=_Part_4927_582499589.1490541753038
Content-Type: text/plain; charset=UTF-8
On Sunday, March 26, 2017 at 10:49:22 AM UTC-4, Avi Kivity wrote:
>
>
>
> On 03/26/2017 05:35 PM, Nicol Bolas wrote:
>
> On Sunday, March 26, 2017 at 10:30:29 AM UTC-4, Avi Kivity wrote:
>>
>> Consider this type-safe bool class:
>>
>>
>> template <typename Tag>
>>
>> class bool_class {
>>
>> bool _value;
>>
>> public:
>>
>> explicit constexpr bool_class(bool v) noexcept : _value(v) {}
>>
>> // more emulation of bool
>>
>> static constexpr bool_class yes = bool_class{true};
>>
>> static constexpr bool_class no = bool_class{true};
>>
>> };
>>
>>
>> Compilation fails, I believe rightly, on clang, because by the time yes
>> and no are parsed, bool_class is an incomplete type, and therefore not a
>> literal type. It could be worked around by making yes and no functions.
>>
>> Should we make this legal? It seems reasonable for types to offer
>> constants scoped under their own name, and if they are literal types,
>> that these constants can be constexpr.
>>
>
> How does it seem reasonable to define variables of a type that has not yet
> been defined?
>
> You can do that already, within an inline member function.
>
That's not defining a variable. That's defining a function that returns a
value of a certain 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/078635c1-3de8-458b-9df3-34f4c62db1fd%40isocpp.org.
------=_Part_4927_582499589.1490541753038
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, March 26, 2017 at 10:49:22 AM UTC-4, Av=
i Kivity wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div>On 03/26/2017 05:35 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Sunday, March 26, 2017 at 10:30:29 AM UTC-4, Avi
Kivity wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">Consider
this type-safe bool class:
<br>
<br>
<br>
=C2=A0 =C2=A0template <typename Tag>
<br>
<br>
=C2=A0 =C2=A0class bool_class {
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0bool _value;
<br>
<br>
=C2=A0 =C2=A0public:
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0explicit constexpr bool_class(bool v) =
noexcept :
_value(v) {}
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0// more emulation of bool
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0static constexpr bool_class yes =3D bo=
ol_class{true};
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0static constexpr bool_class no =3D boo=
l_class{true};
<br>
<br>
=C2=A0 =C2=A0};
<br>
<br>
<br>
Compilation fails, I believe rightly, on clang, because by the
time yes <br>
and no are parsed, bool_class is an incomplete type, and
therefore not a <br>
literal type. =C2=A0It could be worked around by making yes and n=
o
functions.
<br>
<br>
Should we make this legal? =C2=A0It seems reasonable for types to
offer <br>
constants scoped under their own name, and if they are literal
types, <br>
that these constants can be constexpr.<br>
</blockquote>
<div><br>
How does it seem reasonable to define variables of a type that
has not yet been defined? </div>
</div>
</blockquote>
=20
You can do that already, within an inline member function.<br></div></b=
lockquote><div><br>That's not defining a variable. That's defining =
a function that returns a value of a certain type.</div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/078635c1-3de8-458b-9df3-34f4c62db1fd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/078635c1-3de8-458b-9df3-34f4c62db1fd=
%40isocpp.org</a>.<br />
------=_Part_4927_582499589.1490541753038--
------=_Part_4926_1196441680.1490541753038--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Mon, 27 Mar 2017 11:08:26 +0300
Raw View
This is a multi-part message in MIME format.
--------------5ED60F1BA3F55F0115E9DFBE
Content-Type: text/plain; charset=UTF-8; format=flowed
On 03/26/2017 06:22 PM, Nicol Bolas wrote:
>
>
> On Sunday, March 26, 2017 at 10:49:22 AM UTC-4, Avi Kivity wrote:
>
>
>
> On 03/26/2017 05:35 PM, Nicol Bolas wrote:
>> On Sunday, March 26, 2017 at 10:30:29 AM UTC-4, Avi Kivity wrote:
>>
>> Consider this type-safe bool class:
>>
>>
>> template <typename Tag>
>>
>> class bool_class {
>>
>> bool _value;
>>
>> public:
>>
>> explicit constexpr bool_class(bool v) noexcept :
>> _value(v) {}
>>
>> // more emulation of bool
>>
>> static constexpr bool_class yes = bool_class{true};
>>
>> static constexpr bool_class no = bool_class{true};
>>
>> };
>>
>>
>> Compilation fails, I believe rightly, on clang, because by
>> the time yes
>> and no are parsed, bool_class is an incomplete type, and
>> therefore not a
>> literal type. It could be worked around by making yes and no
>> functions.
>>
>> Should we make this legal? It seems reasonable for types to
>> offer
>> constants scoped under their own name, and if they are
>> literal types,
>> that these constants can be constexpr.
>>
>>
>> How does it seem reasonable to define variables of a type that
>> has not yet been defined?
> You can do that already, within an inline member function.
>
>
> That's not defining a variable. That's defining a function that
> returns a value of a certain type.
>
>
The function body may define a variable of a certain type.
struct a {
static constexpr a x{}; // bad
void f() {
static constexpr a x{}; // good
}
};
Technically of course you are correct, but that's because there's a rule
that says that functions are fully parsed only after the type is
completed, to allow this kind of behavior. I'm asking that this rule be
extended to the determination of whether a type is a literal type for
the purpose of deciding whether to allow it as a constexpr member.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/93bf3851-3d56-68e8-bf15-9a27208cf748%40scylladb.com.
--------------5ED60F1BA3F55F0115E9DFBE
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 03/26/2017 06:22 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote
cite=3D"mid:078635c1-3de8-458b-9df3-34f4c62db1fd@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Sunday, March 26, 2017 at 10:49:22 AM UTC-4, Avi Kivity
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p><br>
</p>
<br>
<div>On 03/26/2017 05:35 PM, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On Sunday, March 26, 2017 at 10:30:29 AM
UTC-4, Avi Kivity wrote:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">Consider this type-safe bool
class: <br>
<br>
<br>
=C2=A0 =C2=A0template <typename Tag> <br>
<br>
=C2=A0 =C2=A0class bool_class { <br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0bool _value; <br>
<br>
=C2=A0 =C2=A0public: <br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0explicit constexpr bool_class(=
bool v) noexcept
: _value(v) {} <br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0// more emulation of bool <br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0static constexpr bool_class ye=
s =3D
bool_class{true}; <br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0static constexpr bool_class no=
=3D
bool_class{true}; <br>
<br>
=C2=A0 =C2=A0}; <br>
<br>
<br>
Compilation fails, I believe rightly, on clang,
because by the time yes <br>
and no are parsed, bool_class is an incomplete type,
and therefore not a <br>
literal type. =C2=A0It could be worked around by making y=
es
and no functions. <br>
<br>
Should we make this legal? =C2=A0It seems reasonable for
types to offer <br>
constants scoped under their own name, and if they are
literal types, <br>
that these constants can be constexpr.<br>
</blockquote>
<div><br>
How does it seem reasonable to define variables of a
type that has not yet been defined? </div>
</div>
</blockquote>
You can do that already, within an inline member function.<br>
</div>
</blockquote>
<div><br>
That's not defining a variable. That's defining a function
that returns a value of a certain type.</div>
<br>
</div>
<br>
</blockquote>
<br>
The function body may define a variable of a certain type.<br>
<br>
<br>
struct a {<br>
=C2=A0=C2=A0=C2=A0 static constexpr a x{}; // bad<br>
=C2=A0=C2=A0=C2=A0 void f() {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 static constexpr a x{}=
; // good<br>
=C2=A0=C2=A0=C2=A0 }<br>
};<br>
<br>
<br>
Technically of course you are correct, but that's because there's a
rule that says that functions are fully parsed only after the type
is completed, to allow this kind of behavior. I'm asking that this
rule be extended to the determination of whether a type is a literal
type for the purpose of deciding whether to allow it as a constexpr
member.<br>
<br>
<br>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/93bf3851-3d56-68e8-bf15-9a27208cf748%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/93bf3851-3d56-68e8-bf15-9a27208cf7=
48%40scylladb.com</a>.<br />
--------------5ED60F1BA3F55F0115E9DFBE--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 2 May 2017 13:43:13 -0700
Raw View
--001a114901d8db1927054e909779
Content-Type: text/plain; charset=UTF-8
On 29 April 2017 at 14:51, Jakob Riedle <jakob.riedle@gmail.com> wrote:
> Am Mittwoch, 19. April 2017 18:45:15 UTC+2 schrieb HarD Gamer:
>>
>> https://groups.google.com/a/isocpp.org/forum/#!topic/std-pro
>> posals/pSHhUp0-7so
>>
>
> This basically represents *a work-around* but I hardly consider
> inline variable definitions outside of the class in which they are
> declared as intuitive.
>
>
> To my knowledge, there are only *historical reasons* that
> static variables of a class should not be defined inside
> that class but instead declared inside and defined
> outside of the class and in only one source file.
>
> In order to fish or cut bait w.r.t. a proposal, I'd be interested in three
> things:
> 1. Are there any reasons against allowing the definition of *constexpr
> static class members *of the containing class type within this class
> itself?
>
Yes. The class is not yet completely defined at that point.
> 2. Are there any reasons against allowing the definition of *(non-constexpr)
> static class* *members *of the containing class type within this class as
> well?
> 3. From question 1 and 2 stems the question: Can we just allow *static
> class members* to be defined inside the class itself, *as if they'd been
> defined outside of the class as inline variable*?
>
> Am I mistaken at some point?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/285f811f-044a-4121-
> a107-c463bd0693e1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/285f811f-044a-4121-a107-c463bd0693e1%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmTeRnDL9mTSyo49f%2BzjgwiY4C%2BhUKp%3DHD715K1i7S3fw%40mail.gmail.com.
--001a114901d8db1927054e909779
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 2=
9 April 2017 at 14:51, Jakob Riedle <span dir=3D"ltr"><<a href=3D"mailto=
:jakob.riedle@gmail.com" target=3D"_blank">jakob.riedle@gmail.com</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Am Mittwoch=
, 19. April 2017 18:45:15 UTC+2 schrieb HarD Gamer:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><a href=3D"https://groups.google.com/a/iso=
cpp.org/forum/#!topic/std-proposals/pSHhUp0-7so" rel=3D"nofollow" target=3D=
"_blank">https://groups.google.com/a/is<wbr>ocpp.org/forum/#!topic/std-pro<=
wbr>posals/pSHhUp0-7so</a></div></blockquote><div><br></div><div>This basic=
ally represents <b>a work-around</b> but I hardly consider</div><div>inline=
variable definitions outside of the class in which they are declared as in=
tuitive.</div><div><br></div><div><br></div><div>To my knowledge, there are=
only <i>historical reasons</i> that</div><div>static variables of a class =
should not be defined inside</div><div>that class but instead declared insi=
de and defined</div><div>outside of the class and in only one source file.<=
/div><div><br></div><div>In order to fish or cut bait w.r.t. a proposal, I&=
#39;d be interested in three things:</div><div>1. Are there any reasons aga=
inst allowing the definition of <b>constexpr static class members </b>of th=
e containing class type within this class itself?</div></div></blockquote><=
div><br></div><div>Yes. The class is not yet completely defined at that poi=
nt.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div>2. Are there any reasons against allowing the definition of <b>(non-con=
stexpr) static class</b> <b>members </b>of the containing class type=C2=A0w=
ithin this class as well?</div><div>3. From question 1 and 2 stems the ques=
tion: Can we just allow <b>static class members</b> to be defined inside th=
e class itself, <b>as if they'd been defined outside of the class as in=
line variable</b>?</div><div><br></div><div>Am I mistaken at some point?</d=
iv><div><br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/285f811f-044a-4121-a107-c463bd0693e1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/285f=
811f-044a-4121-<wbr>a107-c463bd0693e1%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmTeRnDL9mTSyo49f%2BzjgwiY4C%2B=
hUKp%3DHD715K1i7S3fw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmTeR=
nDL9mTSyo49f%2BzjgwiY4C%2BhUKp%3DHD715K1i7S3fw%40mail.gmail.com</a>.<br />
--001a114901d8db1927054e909779--
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 3 May 2017 00:33:01 +0300
Raw View
This is a multi-part message in MIME format.
--------------10BFBD1EF111DCE7D04D8691
Content-Type: text/plain; charset=UTF-8; format=flowed
On 05/02/2017 11:43 PM, Richard Smith wrote:
> On 29 April 2017 at 14:51, Jakob Riedle <jakob.riedle@gmail.com
> <mailto:jakob.riedle@gmail.com>> wrote:
>
> Am Mittwoch, 19. April 2017 18:45:15 UTC+2 schrieb HarD Gamer:
>
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/pSHhUp0-7so
> <https://groups.google.com/a/isocpp.org/forum/#%21topic/std-proposals/pSHhUp0-7so>
>
>
> This basically represents *a work-around* but I hardly consider
> inline variable definitions outside of the class in which they are
> declared as intuitive.
>
>
> To my knowledge, there are only /historical reasons/ that
> static variables of a class should not be defined inside
> that class but instead declared inside and defined
> outside of the class and in only one source file.
>
> In order to fish or cut bait w.r.t. a proposal, I'd be interested
> in three things:
> 1. Are there any reasons against allowing the definition of
> *constexpr static class members *of the containing class type
> within this class itself?
>
>
> Yes. The class is not yet completely defined at that point.
Yet, we allow defining functions at that point, and constexpr static
variables of the same type within the function (perhaps the distinction
is the "historical reasons" you mentioned above).
> 2. Are there any reasons against allowing the definition of
> *(non-constexpr) static class* *members *of the containing class
> type within this class as well?
> 3. From question 1 and 2 stems the question: Can we just allow
> *static class members* to be defined inside the class itself, *as
> if they'd been defined outside of the class as inline variable*?
>
> Am I mistaken at some point?
>
> --
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/285f811f-044a-4121-a107-c463bd0693e1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/285f811f-044a-4121-a107-c463bd0693e1%40isocpp.org?utm_medium=email&utm_source=footer>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmTeRnDL9mTSyo49f%2BzjgwiY4C%2BhUKp%3DHD715K1i7S3fw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmTeRnDL9mTSyo49f%2BzjgwiY4C%2BhUKp%3DHD715K1i7S3fw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/656c7e88-fcc7-7c8b-dd18-57ff30bee982%40scylladb.com.
--------------10BFBD1EF111DCE7D04D8691
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<p><br>
</p>
<br>
<div class=3D"moz-cite-prefix">On 05/02/2017 11:43 PM, Richard Smith
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:CAOfiQqmTeRnDL9mTSyo49f+zjgwiY4C+hUKp=3DHD715K1i7S3fw@mail.gmai=
l.com">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On 29 April 2017 at 14:51, Jakob
Riedle <span dir=3D"ltr"><<a
href=3D"mailto:jakob.riedle@gmail.com" target=3D"_blank"
moz-do-not-send=3D"true">jakob.riedle@gmail.com</a>></sp=
an>
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">Am Mittwoch, 19. April 2017 18:45:15 UTC+2
schrieb HarD Gamer:
<blockquote class=3D"gmail_quote"
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir=3D"ltr"><a
href=3D"https://groups.google.com/a/isocpp.org/forum/#%21topic/std-proposal=
s/pSHhUp0-7so"
rel=3D"nofollow" target=3D"_blank"
moz-do-not-send=3D"true">https://groups.google.com/a/=
is<wbr>ocpp.org/forum/#!topic/std-pro<wbr>posals/pSHhUp0-7so</a></div>
</blockquote>
<div><br>
</div>
<div>This basically represents <b>a work-around</b> but
I hardly consider</div>
<div>inline variable definitions outside of the class in
which they are declared as intuitive.</div>
<div><br>
</div>
<div><br>
</div>
<div>To my knowledge, there are only <i>historical
reasons</i> that</div>
<div>static variables of a class should not be defined
inside</div>
<div>that class but instead declared inside and defined</di=
v>
<div>outside of the class and in only one source file.</div=
>
<div><br>
</div>
<div>In order to fish or cut bait w.r.t. a proposal, I'd
be interested in three things:</div>
<div>1. Are there any reasons against allowing the
definition of <b>constexpr static class members </b>of
the containing class type within this class itself?</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes. The class is not yet completely defined at that
point.</div>
</div>
</div>
</div>
</blockquote>
<br>
Yet, we allow defining functions at that point, and constexpr static
variables of the same type within the function (perhaps the
distinction is the "historical reasons" you mentioned above).<br>
<br>
<blockquote type=3D"cite"
cite=3D"mid:CAOfiQqmTeRnDL9mTSyo49f+zjgwiY4C+hUKp=3DHD715K1i7S3fw@mail.gmai=
l.com">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>2. Are there any reasons against allowing the
definition of <b>(non-constexpr) static class</b> <b>memb=
ers
</b>of the containing class type=C2=A0within this class a=
s
well?</div>
<div>3. From question 1 and 2 stems the question: Can we
just allow <b>static class members</b> to be defined
inside the class itself, <b>as if they'd been defined
outside of the class as inline variable</b>?</div>
<div><br>
</div>
<div>Am I mistaken at some point?</div>
<div><br>
</div>
</div>
<span class=3D"">
-- <br>
You received this message because you are subscribed to
the Google 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+unsubscribe@isocpp.org"
target=3D"_blank" moz-do-not-send=3D"true">std-proposals+=
unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank=
"
moz-do-not-send=3D"true">std-proposals@isocpp.org</a>.<br=
>
</span>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/285f81=
1f-044a-4121-a107-c463bd0693e1%40isocpp.org?utm_medium=3Demail&utm_sour=
ce=3Dfooter"
target=3D"_blank" moz-do-not-send=3D"true">https://groups.g=
oogle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/285f811f-044a-4121-<=
wbr>a107-c463bd0693e1%40isocpp.org</a><wbr>.<br>
</blockquote>
</div>
<br>
</div>
</div>
-- <br>
You received this message because you are subscribed to the Google
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+unsubscribe@isocpp.org"
moz-do-not-send=3D"true">std-proposals+unsubscribe@isocpp.org</a>.<=
br>
To post to this group, send email to <a
href=3D"mailto:std-proposals@isocpp.org" moz-do-not-send=3D"true">s=
td-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a
href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQ=
qmTeRnDL9mTSyo49f%2BzjgwiY4C%2BhUKp%3DHD715K1i7S3fw%40mail.gmail.com?utm_me=
dium=3Demail&utm_source=3Dfooter"
moz-do-not-send=3D"true">https://groups.google.com/a/isocpp.org/d/m=
sgid/std-proposals/CAOfiQqmTeRnDL9mTSyo49f%2BzjgwiY4C%2BhUKp%3DHD715K1i7S3f=
w%40mail.gmail.com</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/656c7e88-fcc7-7c8b-dd18-57ff30bee982%=
40scylladb.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.googl=
e.com/a/isocpp.org/d/msgid/std-proposals/656c7e88-fcc7-7c8b-dd18-57ff30bee9=
82%40scylladb.com</a>.<br />
--------------10BFBD1EF111DCE7D04D8691--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Wed, 03 May 2017 00:10:33 +0200
Raw View
On 05/02/2017 11:33 PM, Avi Kivity wrote:
>
>
> On 05/02/2017 11:43 PM, Richard Smith wrote:
>> On 29 April 2017 at 14:51, Jakob Riedle <jakob.riedle@gmail.com <mailto:jakob.riedle@gmail.com>> wrote:
>> In order to fish or cut bait w.r.t. a proposal, I'd be interested in three things:
>> 1. Are there any reasons against allowing the definition of *constexpr static class members *of the containing class type within this class itself?
>>
>>
>> Yes. The class is not yet completely defined at that point.
>
> Yet, we allow defining functions at that point, and constexpr static variables of the same type within the function (perhaps the distinction is the "historical reasons" you mentioned above).
Consider:
struct X {
static constexpr int n = 5;
int a[n]; // currently ok; useful
};
struct Y {
Y(int n) : n(n) { }
static constexpr Y y = 5;
int n;
int a[y.n]; // does this work?
};
struct Z {
Y(int n) : n(n) { }
static constexpr Z z = sizeof(Z);
int n;
int a[z.n]; // does this work?
};
Jens
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/590903D9.2020007%40gmx.net.
.
Author: Avi Kivity <avi@scylladb.com>
Date: Wed, 3 May 2017 01:37:25 +0300
Raw View
On 05/03/2017 01:10 AM, Jens Maurer wrote:
> On 05/02/2017 11:33 PM, Avi Kivity wrote:
>>
>> On 05/02/2017 11:43 PM, Richard Smith wrote:
>>> On 29 April 2017 at 14:51, Jakob Riedle <jakob.riedle@gmail.com <mailto:jakob.riedle@gmail.com>> wrote:
>>> In order to fish or cut bait w.r.t. a proposal, I'd be interested in three things:
>>> 1. Are there any reasons against allowing the definition of *constexpr static class members *of the containing class type within this class itself?
>>>
>>>
>>> Yes. The class is not yet completely defined at that point.
>> Yet, we allow defining functions at that point, and constexpr static variables of the same type within the function (perhaps the distinction is the "historical reasons" you mentioned above).
> Consider:
>
> struct X {
> static constexpr int n = 5;
> int a[n]; // currently ok; useful
> };
>
> struct Y {
> Y(int n) : n(n) { }
> static constexpr Y y = 5;
> int n;
> int a[y.n]; // does this work?
> };
Most likely, not.
But there are already such limitations:
constexpr int n0() { return 3; }
struct W {
static constexpr int n1() { return 5; }
int a0[n0()]; // works
int a1[n1()]; // error: fields must have a constant size?!
};
So we're already suffering from this when the definition of a function
is deferred.
> struct Z {
> Y(int n) : n(n) { }
> static constexpr Z z = sizeof(Z);
> int n;
> int a[z.n]; // does this work?
> };
>
> Jens
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8cd60a95-decd-4b28-92f3-083bf2771625%40scylladb.com.
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Thu, 04 May 2017 22:42:58 +0200
Raw View
On 05/03/2017 12:37 AM, Avi Kivity wrote:
> On 05/03/2017 01:10 AM, Jens Maurer wrote:
>> struct Y {
>> Y(int n) : n(n) { }
>> static constexpr Y y = 5;
>> int n;
>> int a[y.n]; // does this work?
>> };
>
> Most likely, not.
>
>
> But there are already such limitations:
>
>
> constexpr int n0() { return 3; }
>
>
> struct W {
> static constexpr int n1() { return 5; }
> int a0[n0()]; // works
> int a1[n1()]; // error: fields must have a constant size?!
> };
Nobody has invested the time and energy to come up with
a revised set of rules how delayed-parsing of items showing
up in a class definition should be enhanced to allow some of
your/my examples, and expressly making ill-formed the others.
Papers welcome.
Jens
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/590B9252.3020004%40gmx.net.
.