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.

--
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/dfb9f65c-ea1d-e92b-85e0-333efed1aec5%40scylladb.com.

.

------=_Part_4619_1018717613.1490538944376
Content-Type: multipart/alternative;
 boundary="----=_Part_4620_1380570845.1490538944376"

------=_Part_4620_1380570845.1490538944376
Content-Type: text/plain; charset=UTF-8

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? What's wrong with defining them outside of the scope of the
class?

--
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/470f86cc-36b7-4244-82dd-b795af107996%40isocpp.org.

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

<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 &lt;typename Tag&gt;
<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) noexce=
pt : _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 bool_cla=
ss{true};
<br>
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0static constexpr bool_class no =3D bool_clas=
s{true};
<br>
<br>=C2=A0 =C2=A0};
<br>
<br>
<br>Compilation fails, I believe rightly, on clang, because by the time yes=
=20
<br>and no are parsed, bool_class is an incomplete type, and therefore not =
a=20
<br>literal type. =C2=A0It could be worked around by making yes and no func=
tions.
<br>
<br>Should we make this legal? =C2=A0It seems reasonable for types to offer=
=20
<br>constants scoped under their own name, and if they are literal types,=
=20
<br>that these constants can be constexpr.<br></blockquote><div><br>How doe=
s it seem reasonable to define variables of a type that has not yet been de=
fined? What&#39;s wrong with defining them outside of the scope of the clas=
s?<br></div></div>

<p></p>

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

------=_Part_4620_1380570845.1490538944376--

------=_Part_4619_1018717613.1490538944376--

.

On 26 March 2017 at 17:30, Avi Kivity <avi@scylladb.com> 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.


This is US 24 in
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0488r0.pdf. The
comment was rejected
for C++17 due to lack of a proper proposal and the timing.

--
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/CAFk2RUa1uC%2BtvkBBYevwNFo%3Dh-oW7UXyBFXbnfoqmCAWFTEfOw%40mail.gmail.com.

.

On 03/26/2017 05:35 PM, Ville Voutilainen wrote:
> On 26 March 2017 at 17:30, Avi Kivity <avi@scylladb.com> 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.
>
> This is US 24 in
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0488r0.pdf. The
> comment was rejected
> for C++17 due to lack of a proper proposal and the timing.
>

Thanks.  I hope to see this corrected in the future.

--
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/f8590f49-fb6f-ee08-7fd6-a4b160066143%40scylladb.com.

.

Le 26/03/2017 =C3=A0 16:30, Avi Kivity a =C3=A9crit :
> 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 =3D bool_class{true};
>
>       static constexpr bool_class no =3D bool_class{true};
>
>   };
>
>
> Compilation fails, I believe rightly, on clang, because by the time=20
> yes and no are parsed, bool_class is an incomplete type, and therefore=20
> not a literal type.  It could be worked around by making yes and no=20
> functions.
>
> Should we make this legal?  It seems reasonable for types to offer=20
> constants scoped under their own name, and if they are literal types,=20
> that these constants can be constexpr.
>
It seems that you can do

   template <typename Tag>

   class bool_class {

       bool _value;

   public:

       explicit constexpr bool_class(bool v) noexcept : _value(v) {}

       // more emulation of bool

       static const bool_class yes;

       static const bool_class no;

   };

    constexpr bool_class bool_class::yes =3D bool_class{true};

    constexpr bool_class bool_class::no =3D bool_class{true};


Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5262b75e-8281-411d-2248-6be37fd52b85%40wanadoo.f=
r.

.

On 03/26/2017 07:50 PM, Vicente J. Botet Escriba wrote:
> Le 26/03/2017 =C3=A0 16:30, Avi Kivity a =C3=A9crit :
>> 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 =3D bool_class{true};
>>
>>       static constexpr bool_class no =3D bool_class{true};
>>
>>   };
>>
>>
>> Compilation fails, I believe rightly, on clang, because by the time=20
>> yes and no are parsed, bool_class is an incomplete type, and=20
>> therefore not a literal type.  It could be worked around by making=20
>> yes and no functions.
>>
>> Should we make this legal?  It seems reasonable for types to offer=20
>> constants scoped under their own name, and if they are literal types,=20
>> that these constants can be constexpr.
>>
> It seems that you can do
>
>   template <typename Tag>
>
>   class bool_class {
>
>       bool _value;
>
>   public:
>
>       explicit constexpr bool_class(bool v) noexcept : _value(v) {}
>
>       // more emulation of bool
>
>       static const bool_class yes;
>
>       static const bool_class no;
>
>   };
>
>    constexpr bool_class bool_class::yes =3D bool_class{true};
>
>    constexpr bool_class bool_class::no =3D bool_class{true};
>
>

The compiler (clang) won't recognize yes and no as constexpr variables:


template <typename Tag>
class bool_class {
     bool _value;
public:
     explicit constexpr bool_class(bool v) noexcept : _value(v) {}

     // more emulation of bool
     constexpr bool operator=3D=3D(bool_class other) const {
     return _value =3D=3D other._value;
     }

     static const bool_class yes;
     static const bool_class no;
};

template <typename Tag>
constexpr bool_class<Tag> bool_class<Tag>::yes =3D bool_class{true};

template <typename Tag>
constexpr bool_class<Tag> bool_class<Tag>::no =3D bool_class{true};

static_assert(bool_class<int>::yes =3D=3D bool_class<int>::no);


bool_class2.cc:23:15: error: static_assert expression is not an integral=20
constant expression
static_assert(bool_class<int>::yes =3D=3D bool_class<int>::no);
               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bool_class2.cc:23:39: note: read of non-constexpr variable 'no' is not=20
allowed in a constant expression
static_assert(bool_class<int>::yes =3D=3D bool_class<int>::no);
                                       ^



--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/afbe68ce-4606-06f0-e270-3dc4ff911bc4%40scylladb.=
com.

.

------=_Part_7264_1583466568.1492606734756
Content-Type: multipart/alternative;
 boundary="----=_Part_7265_463703066.1492606734756"

------=_Part_7265_463703066.1492606734756
Content-Type: text/plain; charset=UTF-8


>
> 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.
>

I really like the idea of being able to do that and I had that scenario
quite often,
e.g. with a Color-Class that defines several constants, such as WHITE,
BLACK ...
The problem with defining the attributes outside the class,
is that you cannot declare this stuff in a header file and include it
multiple times.

However, this problem is solved by Inline Variables
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4424.pdf>.
Still, having to define *constexpr static *class variables outside of the
class is *neither pretty nor intuitive*.

*Note*: *Java supports this feature for a long time already.*
*M(atlab) also supports this. (Using a section named "enumeration" within
the "classdef" itself).*

Given these reasons, I'm greatly convinced, this is a good thing and should
be written a paper for.

--
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/a163f3bd-906e-4dc4-894b-0aae6d2b2e89%40isocpp.org.

------=_Part_7265_463703066.1492606734756
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;">Should we mak=
e this legal? =C2=A0It seems reasonable for types to offer=C2=A0<br>constan=
ts scoped under their own name, and if they are literal types,=C2=A0<br>tha=
t these constants can be constexpr.=C2=A0<br></blockquote><div><br></div><d=
iv>I really like the idea of being able to do that and I had that scenario =
quite often,</div><div>e.g. with a Color-Class that defines several constan=
ts, such as WHITE, BLACK ...</div><div>The problem with defining the attrib=
utes outside the class,</div><div>is that you cannot declare this stuff in =
a header file and include it multiple times.</div><div><br></div><div>Howev=
er, this problem is solved by=C2=A0<a href=3D"http://www.open-std.org/jtc1/=
sc22/wg21/docs/papers/2015/n4424.pdf">Inline Variables</a>.</div><div>Still=
, having to define <i>constexpr static=C2=A0</i>class variables outside of =
the class is <b>neither pretty nor intuitive</b>.</div><div><br></div><div>=
<b>Note</b>: <i>Java supports this feature for a long time already.</i></di=
v><div><i>M(atlab) also supports this. (Using a section named &quot;enumera=
tion&quot; within the &quot;classdef&quot; itself).</i></div><div><br></div=
><div>Given these reasons, I&#39;m greatly convinced, this is a good thing =
and should be written a paper for.</div></div>

<p></p>

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

------=_Part_7265_463703066.1492606734756--

------=_Part_7264_1583466568.1492606734756--

.

------=_Part_2727_308742628.1492620315571
Content-Type: multipart/alternative;
 boundary="----=_Part_2728_1204495269.1492620315571"

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

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/pSHhUp0-=
7so

Em domingo, 26 de mar=C3=A7o de 2017 11:30:29 UTC-3, Avi Kivity escreveu:
>
> Consider this type-safe bool class:=20
>
>
>    template <typename Tag>=20
>
>    class bool_class {=20
>
>        bool _value;=20
>
>    public:=20
>
>        explicit constexpr bool_class(bool v) noexcept : _value(v) {}=20
>
>        // more emulation of bool=20
>
>        static constexpr bool_class yes =3D bool_class{true};=20
>
>        static constexpr bool_class no =3D bool_class{true};=20
>
>    };=20
>
>
> Compilation fails, I believe rightly, on clang, because by the time yes=
=20
> and no are parsed, bool_class is an incomplete type, and therefore not a=
=20
> literal type.  It could be worked around by making yes and no functions.=
=20
>
> Should we make this legal?  It seems reasonable for types to offer=20
> constants scoped under their own name, and if they are literal types,=20
> that these constants can be constexpr.=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/61acd2a4-d2f8-41ef-849a-0c47cee485d1%40isocpp.or=
g.

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

<div dir=3D"ltr">https://groups.google.com/a/isocpp.org/forum/#!topic/std-p=
roposals/pSHhUp0-7so<br><br>Em domingo, 26 de mar=C3=A7o de 2017 11:30:29 U=
TC-3, Avi Kivity  escreveu:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Con=
sider this type-safe bool class:
<br>
<br>
<br>=C2=A0 =C2=A0template &lt;typename Tag&gt;
<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) noexce=
pt : _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 bool_cla=
ss{true};
<br>
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0static constexpr bool_class no =3D bool_clas=
s{true};
<br>
<br>=C2=A0 =C2=A0};
<br>
<br>
<br>Compilation fails, I believe rightly, on clang, because by the time yes=
=20
<br>and no are parsed, bool_class is an incomplete type, and therefore not =
a=20
<br>literal type. =C2=A0It could be worked around by making yes and no func=
tions.
<br>
<br>Should we make this legal? =C2=A0It seems reasonable for types to offer=
=20
<br>constants scoped under their own name, and if they are literal types,=
=20
<br>that these constants can be constexpr.
<br></blockquote></div>

<p></p>

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

------=_Part_2728_1204495269.1492620315571--

------=_Part_2727_308742628.1492620315571--

.

------=_Part_1560_1303958533.1493502712158
Content-Type: multipart/alternative;
 boundary="----=_Part_1561_1319635756.1493502712159"

------=_Part_1561_1319635756.1493502712159
Content-Type: text/plain; charset=UTF-8

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
>

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?
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.

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

<div dir=3D"ltr">Am Mittwoch, 19. April 2017 18:45:15 UTC+2 schrieb HarD Ga=
mer:<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/#!topic/std-proposals/pSHh=
Up0-7so" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/pSHhUp0=
-7so&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/forum/#!topic/std-proposals/pSHhUp0-7so&#39;;return true;">=
https://groups.google.com/a/<wbr>isocpp.org/forum/#!topic/std-<wbr>proposal=
s/pSHhUp0-7so</a></div></blockquote><div><br></div><div>This basically repr=
esents <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 no=
t be defined inside</div><div>that class but instead declared inside and de=
fined</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 against allo=
wing the definition of <b>constexpr static class members </b>of the contain=
ing class type within this class itself?</div><div>2. Are there any reasons=
 against allowing the definition of <b>(non-constexpr) static class</b> <b>=
members </b>of the containing class type=C2=A0within this class as well?</d=
iv><div>3. From question 1 and 2 stems the question: Can we just allow <b>s=
tatic class members</b> to be defined inside the class itself, <b>as if the=
y&#39;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>

<p></p>

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

------=_Part_1561_1319635756.1493502712159--

------=_Part_1560_1303958533.1493502712158--

.