Hi,

It's not allowed to declare a non-static constexpr data member,
and it doesn't make sense to do so.  Can we just make such
a declaration default to be static?

struct A {
  constexpr int v = 10;
  // as same as `static constexpr int v = 10;`
};

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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



.

2013/6/19 Zhihao Yuan <lichray@gmail.com>:
> Hi,
>
> It's not allowed to declare a non-static constexpr data member,
> and it doesn't make sense to do so.  Can we just make such
> a declaration default to be static?
>
> struct A {
>   constexpr int v = 10;
>   // as same as `static constexpr int v = 10;`
> };

Bitten my the history of previous implied const of non-static
constexpr member functions I'm now *very* defensive in favor for such
a proposal. The current impression "doesn't make sense" might turn out
to prevent a reasonable future extension (No, I haven't thought very
much about that and maybe there is no reasonable application, but I
think it's much too early to consider this change).

- Daniel

--

---
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_11_30655975.1371654812048
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, June 18, 2013 11:16:07 PM UTC-7, Zhihao Yuan wrote:
>
> Hi,
>
> It's not allowed to declare a non-static constexpr data member,
> and it doesn't make sense to do so.  Can we just make such
> a declaration default to be static?
>
> struct A {
>   constexpr int v = 10;
>   // as same as `static constexpr int v = 10;`
> };
>

Just because syntax doesn't make sense doesn't mean it's free to have
arbitrary rules applied to it. If something's going to be static, I want to
see `static` there. It's much more readable as-is.

--

---
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_11_30655975.1371654812048
Content-Type: text/html; charset=ISO-8859-1

On Tuesday, June 18, 2013 11:16:07 PM UTC-7, Zhihao Yuan wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,
<br>
<br>It's not allowed to declare a non-static constexpr data member,
<br>and it doesn't make sense to do so. &nbsp;Can we just make such
<br>a declaration default to be static?
<br>
<br>struct A {
<br>&nbsp; constexpr int v = 10;
<br>&nbsp; // as same as `static constexpr int v = 10;`
<br>};
<br></blockquote><div><br>Just because syntax doesn't make sense doesn't mean it's free to have arbitrary rules applied to it. If something's going to be static, I want to see `static` there. It's much more readable as-is.<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_11_30655975.1371654812048--

.

On Wed, Jun 19, 2013 at 11:13 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Just because syntax doesn't make sense doesn't mean it's free to have
> arbitrary rules applied to it. If something's going to be static, I want to
> see `static` there. It's much more readable as-is.

To me the one without `static` is more straight forward; it's
more like the `const` in namespace scope has internal
linkage.  I bet you hate to write `static const` in C and start
to use macro instead.  Similarly, a `constexpr` data member
should just work as-is, IMHO.

Its different application?  Maybe we can allow it to appear in
a local class :) LOL

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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



.

2013/6/19 Zhihao Yuan <lichray@gmail.com>:
> Its different application?  Maybe we can allow it to appear in
> a local class :) LOL

And this extension becomes a potential problem when we should consider
to allow static members for local classes.

- Daniel

--

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



.

On Wed, Jun 19, 2013 at 11:29 AM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
>> Maybe we can allow it to appear in
>> a local class :) LOL
>
> And this extension becomes a potential problem when we should consider
> to allow static members for local classes.

If there is a plan to allow static member in a local class,
there is still no difference between `constexpr` data members
which are declared as static or not, right?  What's the
problem?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=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_3436_8026110.1371658363624
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On Wednesday, June 19, 2013 4:46:32 PM UTC+1, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 11:29 AM, Daniel Kr=FCgler=20
> <daniel....@gmail.com <javascript:>> wrote:=20
> >> Maybe we can allow it to appear in=20
> >> a local class :) LOL=20
> >=20
> > And this extension becomes a potential problem when we should consider=
=20
> > to allow static members for local classes.=20
>
> If there is a plan to allow static member in a local class,=20
> there is still no difference between `constexpr` data members=20
> which are declared as static or not, right?  What's the=20
> problem?=20
>
> =20
 Programming language design should be more rational than just "I don't=20
like this, can we change it?"


=20

--=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_3436_8026110.1371658363624
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 19, 2013 4:46:32 PM UTC+1, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 11:29 AM,=
 Daniel Kr=FCgler
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
ddLlBEHYF0UJ">daniel....@gmail.com</a>&gt; wrote:
<br>&gt;&gt; Maybe we can allow it to appear in
<br>&gt;&gt; a local class :) LOL
<br>&gt;
<br>&gt; And this extension becomes a potential problem when we should cons=
ider
<br>&gt; to allow static members for local classes.
<br>
<br>If there is a plan to allow static member in a local class,
<br>there is still no difference between `constexpr` data members
<br>which are declared as static or not, right? &nbsp;What's the
<br>problem?
<br><br></blockquote><div>&nbsp;</div><div>&nbsp;Programming language desig=
n should be more rational than just "I don't like this, can we change it?"<=
br><br><br></div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_3436_8026110.1371658363624--

.

------=_Part_4208_11793735.1371659105154
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, June 19, 2013 8:24:43 AM UTC-7, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 11:13 AM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > Just because syntax doesn't make sense doesn't mean it's free to have
> > arbitrary rules applied to it. If something's going to be static, I want
> to
> > see `static` there. It's much more readable as-is.
>
> To me the one without `static` is more straight forward; it's
> more like the `const` in namespace scope has internal
> linkage.  I bet you hate to write `static const` in C and start
> to use macro instead.  Similarly, a `constexpr` data member
> should just work as-is, IMHO.
>

And you've just made a convincing argument *not* to do this.

`static` when used on a global variable means something *completely
different* than when it's used on a member of a class. In a global,
`static` is about linkage; as a member, it determines whether it's a
per-instance member or a per-object member. It really should have been a
separate keyword, but that can't be changed now.

Furthermore, `const` members of a class are not implicitly static data
members, yet `const` globals implicitly have internal linkage, like
`static` globals. Why should `constexpr` behave differently in this regard?

--

---
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_4208_11793735.1371659105154
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, June 19, 2013 8:24:43 AM UTC-7, Zhihao Yuan wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 11:13 AM, Nicol B=
olas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"rRdWFEI23SYJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; Just because syntax doesn't make sense doesn't mean it's free to h=
ave
<br>&gt; arbitrary rules applied to it. If something's going to be static, =
I want to
<br>&gt; see `static` there. It's much more readable as-is.
<br>
<br>To me the one without `static` is more straight forward; it's
<br>more like the `const` in namespace scope has internal
<br>linkage. &nbsp;I bet you hate to write `static const` in C and start
<br>to use macro instead. &nbsp;Similarly, a `constexpr` data member
<br>should just work as-is, IMHO.<br></blockquote><div><br>And you've just =
made a convincing argument <i>not</i> to do this.<br><br>`static` when used=
 on a global variable means something <i>completely different</i> than when=
 it's used on a member of a class. In a global, `static` is about linkage; =
as a member, it determines whether it's a per-instance member or a per-obje=
ct member. It really should have been a separate keyword, but that can't be=
 changed now.<br><br>Furthermore, `const` members of a class are not implic=
itly static data members, yet `const` globals implicitly have internal link=
age, like `static` globals. Why should `constexpr` behave differently in th=
is regard?<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_4208_11793735.1371659105154--

.

On Wed, Jun 19, 2013 at 12:25 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> And you've just made a convincing argument not to do this.

"it's more like" does not mean "they are the same".  The two problems are
completely different, but the rationale which makes intuitive things work is
similar.

> Furthermore, `const` members of a class are not implicitly static data
> members, yet `const` globals implicitly have internal linkage, like `static`
> globals. Why should `constexpr` behave differently in this regard?

Just because it's intuitive.  An object is of states, the states can contain
read-only parts, but not non-states, i.e., constants.  A constant defined
in a class scope is just some name can be looked up by the member
functions, you don't need a static keyword here to understand it.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_3695_1868215.1371661599764
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 19, 2013 5:57:47 PM UTC+1, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 12:25 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > And you've just made a convincing argument not to do this.
>
> "it's more like" does not mean "they are the same".  The two problems are
> completely different, but the rationale which makes intuitive things work
> is
> similar.
>
> > Furthermore, `const` members of a class are not implicitly static data
> > members, yet `const` globals implicitly have internal linkage, like
> `static`
> > globals. Why should `constexpr` behave differently in this regard?
>
> Just because it's intuitive.  An object is of states, the states can
> contain
> read-only parts, but not non-states, i.e., constants.  A constant defined
> in a class scope is just some name can be looked up by the member
> functions, you don't need a static keyword here to understand it.
>

But constexpr member functions aren't implicitly static member functions.

Does it enable new features not currently available?  No it would just save
some typing.

Does your proposal make the language more regular?  I would argue no,
because a constexpr member variable would be implicitly static, but a
constexpr member function would not.  const at namespace scope implies
static linkage, constexpr at namespace scope implies static linkage. const
on a member variable does not imply anything about linkage, and does not
make the member static. Your proposal to change the meaning of constexpr on
a member variable does not imply anything about linkage, but makes the
member static. That's inconsistent with *everything* else.

Does it make the langue easier to teach?  No, due to the same inconsistency
between member variables and member functions.

What are you hoping to achieve except saving a bit of typing?




--

---
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_3695_1868215.1371661599764
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 19, 2013 5:57:47 PM UTC+1, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 12:25 PM,=
 Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"rrTi3plACHoJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; And you've just made a convincing argument not to do this.
<br>
<br>"it's more like" does not mean "they are the same". &nbsp;The two probl=
ems are
<br>completely different, but the rationale which makes intuitive things wo=
rk is
<br>similar.
<br>
<br>&gt; Furthermore, `const` members of a class are not implicitly static =
data
<br>&gt; members, yet `const` globals implicitly have internal linkage, lik=
e `static`
<br>&gt; globals. Why should `constexpr` behave differently in this regard?
<br>
<br>Just because it's intuitive. &nbsp;An object is of states, the states c=
an contain
<br>read-only parts, but not non-states, i.e., constants. &nbsp;A constant =
defined
<br>in a class scope is just some name can be looked up by the member
<br>functions, you don't need a static keyword here to understand it.
<br></blockquote><div>&nbsp;</div><div>But constexpr member functions aren'=
t implicitly static member functions.<br><br>Does it enable new features no=
t currently available?&nbsp; No it would just save some typing.<br><br>Does=
 your proposal make the language more regular?&nbsp; I would argue no, beca=
use a constexpr member variable would be implicitly static, but a constexpr=
 member function would not.&nbsp; const at namespace scope implies static l=
inkage, constexpr at namespace scope implies static linkage. const on a mem=
ber variable does not imply anything about linkage, and does not make the m=
ember static. Your proposal to change the meaning of constexpr on a member =
variable does not imply anything about linkage, but makes the member static=
.. That's inconsistent with *everything* else.<br><br>Does it make the langu=
e easier to teach?&nbsp; No, due to the same inconsistency between member v=
ariables and member functions.<br><br>What are you hoping to achieve except=
 saving a bit of typing?<br><br><br>&nbsp;<br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_3695_1868215.1371661599764--

.

On Wed, Jun 19, 2013 at 1:06 PM, Jonathan Wakely <cxx@kayari.org> wrote:
> But constexpr member functions aren't implicitly static member functions.

But a variable defined in namespace scope default to have external
linkage, then why a `const` qualifier can change its linkage?  This is
why I say the rationales of these "defaults" are the same, but their
behaviors do not have to be the same.

> Does it enable new features not currently available?  No it would just save
> some typing.

I mentioned we can allow it in local class.  But yea, the major
physical difference is all about saving typing.

> because a constexpr member variable would be implicitly static, but a
> constexpr member function would not.  const at namespace scope implies
> static linkage, constexpr at namespace scope implies static linkage. const
> on a member variable does not imply anything about linkage, and does not
> make the member static.

Please do not use the behavior of `const` to prove the behavior of
`constexpr`.  They are different, and there is no need for them to
be "consistent".

> Your proposal to change the meaning of constexpr on
> a member variable does not imply anything about linkage, but makes the
> member static. That's inconsistent with *everything* else.

I prefer not to be limited by the specific behaviors, but think
it like a designer.  The design purpose of `constexpr` is to
define *real* constant, which has no storage.  Practically,
we allow compiler choose how they implement it.  But from
a user's point of view, a user should not care about where
`constexpr` variables are, what kind of linkage they have.
And my suggestion strength such a will by make them
work out-of-box with a class scope.

> Does it make the langue easier to teach?

Yes!  So that we can teach "constexpr variables are just constant,
don't spent your time on figuring out *what* exactly they are".

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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



.

On Wed, Jun 19, 2013 at 11:43 AM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Wed, Jun 19, 2013 at 1:06 PM, Jonathan Wakely <cxx@kayari.org> wrote:
>> Does it enable new features not currently available?  No it would just save
>> some typing.
>
> I mentioned we can allow it in local class.  But yea, the major
> physical difference is all about saving typing.

C++ has a history of making one keyword imply another in various
contexts. In my experience, it makes the language more complex, and
harder to read and reason about. (For an example of that, try to
summarize the rules on when a variable has external linkage.)

>> Your proposal to change the meaning of constexpr on
>> a member variable does not imply anything about linkage, but makes the
>> member static. That's inconsistent with *everything* else.
>
> I prefer not to be limited by the specific behaviors, but think
> it like a designer.  The design purpose of `constexpr` is to
> define *real* constant, which has no storage.

constexpr is not limited to that purpose. It is also used to require
static initialization for a constant variable, for instance, and it
certainly doesn't prohibit taking the address of the variable, or
binding a reference to it, or calling a member function on it, all of
which require storage.

>> Does it make the langue easier to teach?
>
> Yes!  So that we can teach "constexpr variables are just constant,
> don't spent your time on figuring out *what* exactly they are".

If you need to say "don't try to understand this", that does not
suggest it is easy to teach. Right now, we have a simple rule that
class members are instance-specific if they are not 'static', and are
not instance-specific if they are 'static'. Adding a 'constexpr'
special case seems to make that rule more complex.

--

---
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_4293_12225316.1371669553117
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, June 19, 2013 7:43:37 PM UTC+1, Zhihao Yuan wrote:

> On Wed, Jun 19, 2013 at 1:06 PM, Jonathan Wakely <c...@kayari.org<javascript:>>
> wrote:
> > But constexpr member functions aren't implicitly static member
> functions.
>
> But a variable defined in namespace scope default to have external
> linkage, then why a `const` qualifier can change its linkage?


So that simple named constants in separate translation units don't
interfere and you don't have to be careful about avoiding name clashes.




>  This is
> why I say the rationales of these "defaults" are the same, but their
> behaviors do not have to be the same.
>
> > Does it enable new features not currently available?  No it would just
> save
> > some typing.
>
> I mentioned we can allow it in local class.  But yea, the major
> physical difference is all about saving typing.
>
> > because a constexpr member variable would be implicitly static, but a
> > constexpr member function would not.  const at namespace scope implies
> > static linkage, constexpr at namespace scope implies static linkage.
> const
> > on a member variable does not imply anything about linkage, and does not
> > make the member static.
>
> Please do not use the behavior of `const` to prove the behavior of
> `constexpr`.  They are different, and there is no need for them to
> be "consistent".
>
> OK, but what about the consistency of constexpr data members and consexpr
member functions?




> > Your proposal to change the meaning of constexpr on
> > a member variable does not imply anything about linkage, but makes the
> > member static. That's inconsistent with *everything* else.
>
> I prefer not to be limited by the specific behaviors, but think
> it like a designer.  The design purpose of `constexpr` is to
> define *real* constant, which has no storage.


Oh, what if I take a constexpr variable's address?



>  Practically,
> we allow compiler choose how they implement it.  But from
> a user's point of view, a user should not care about where
> `constexpr` variables are, what kind of linkage they have.
> And my suggestion strength such a will by make them
> work out-of-box with a class scope.
>
> > Does it make the langue easier to teach?
>
> Yes!  So that we can teach "constexpr variables are just constant,
> don't spent your time on figuring out *what* exactly they are".


I don't think your proposal helps that.


>
>

--

---
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_4293_12225316.1371669553117
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, June 19, 2013 7:43:37 PM UTC+1, Zhihao Yuan wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 1:06 PM, Jona=
than Wakely &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"JOLbeG1siCEJ">c...@kayari.org</a>&gt; wrote:
<br>&gt; But constexpr member functions aren't implicitly static member fun=
ctions.
<br>
<br>But a variable defined in namespace scope default to have external
<br>linkage, then why a `const` qualifier can change its linkage?</blockquo=
te><div><br></div><div>So that simple named constants in separate translati=
on units don't interfere and you don't have to be careful about avoiding na=
me clashes.</div><div><br></div><div><br></div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"> &nbsp;This is
<br>why I say the rationales of these "defaults" are the same, but their
<br>behaviors do not have to be the same.
<br>
<br>&gt; Does it enable new features not currently available? &nbsp;No it w=
ould just save
<br>&gt; some typing.
<br>
<br>I mentioned we can allow it in local class. &nbsp;But yea, the major
<br>physical difference is all about saving typing.
<br>
<br>&gt; because a constexpr member variable would be implicitly static, bu=
t a
<br>&gt; constexpr member function would not. &nbsp;const at namespace scop=
e implies
<br>&gt; static linkage, constexpr at namespace scope implies static linkag=
e. const
<br>&gt; on a member variable does not imply anything about linkage, and do=
es not
<br>&gt; make the member static.
<br>
<br>Please do not use the behavior of `const` to prove the behavior of
<br>`constexpr`. &nbsp;They are different, and there is no need for them to
<br>be "consistent".
<br>
<br></blockquote><div>OK, but what about the consistency of constexpr data =
members and consexpr member functions?</div><div><br></div><div><br></div><=
div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Your prop=
osal to change the meaning of constexpr on
<br>&gt; a member variable does not imply anything about linkage, but makes=
 the
<br>&gt; member static. That's inconsistent with *everything* else.
<br>
<br>I prefer not to be limited by the specific behaviors, but think
<br>it like a designer. &nbsp;The design purpose of `constexpr` is to
<br>define *real* constant, which has no storage.</blockquote><div><br></di=
v><div>Oh, what if I take a constexpr variable's address?</div><div><br></d=
iv><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> &nbsp;Pra=
ctically,
<br>we allow compiler choose how they implement it. &nbsp;But from
<br>a user's point of view, a user should not care about where
<br>`constexpr` variables are, what kind of linkage they have.
<br>And my suggestion strength such a will by make them
<br>work out-of-box with a class scope.
<br>
<br>&gt; Does it make the langue easier to teach?
<br>
<br>Yes! &nbsp;So that we can teach "constexpr variables are just constant,
<br>don't spent your time on figuring out *what* exactly they are".
</blockquote><div><br></div><div>I don't think your proposal helps that.</d=
iv><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&nbsp;<br>=
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_4293_12225316.1371669553117--

.

--nextPart2142221.T5s3WZm64d
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On quarta-feira, 19 de junho de 2013 12.18.15, Richard Smith wrote:
> constexpr is not limited to that purpose. It is also used to require
> static initialization for a constant variable, for instance, and it
> certainly doesn't prohibit taking the address of the variable, or
> binding a reference to it, or calling a member function on it, all of
> which require storage.

Are we missing the ability to require static-initialisation of a non-const
object?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart2142221.T5s3WZm64d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBRwgtEM/XwBW70U1gRAs7jAJ9qY6YoMY/DJ29hXj18fS/SArVZbwCdGsF/
Z1BuX8B4GroxcqWn5u7Dguw=
=dcGO
-----END PGP SIGNATURE-----

--nextPart2142221.T5s3WZm64d--


.

On Wed, Jun 19, 2013 at 3:18 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> C++ has a history of making one keyword imply another in various
> contexts. In my experience, it makes the language more complex, and
> harder to read and reason about. (For an example of that, try to
> summarize the rules on when a variable has external linkage.)

I hope some day in the future, people can use C++ without knowing
anything about linkage and translation unit, because those are
actually implementation details.  Currently they are not, just because
we don't have a good-enough abstraction on modulation.

Anyway, my point is, ideally, from a user's point of view, those
implicit rules should have all the positive effects, like `constexpr`
functions implies inline.

> constexpr is not limited to that purpose. It is also used to require
> static initialization for a constant variable, for instance, and it
> certainly doesn't prohibit taking the address of the variable, or
> binding a reference to it, or calling a member function on it, all of
> which require storage.

There are always differences between one thing is designed to
do and the things it can do.  And my suggestion fixes a tiny
hole on what it designed to do.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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



.

On Wed, Jun 19, 2013 at 3:19 PM, Jonathan Wakely <cxx@kayari.org> wrote:
>> But a variable defined in namespace scope default to have external
>> linkage, then why a `const` qualifier can change its linkage?
>
> So that simple named constants in separate translation units don't interfere
> and you don't have to be careful about avoiding name clashes.

So that simple named constants in class scope are not duplicated
for each object (not allowed, forever) and you don't have to care
about what the constants actually are.

> OK, but what about the consistency of constexpr data members and consexpr
> member functions?

Re-read your comment, consistency of a data member and a
member function -- for what?  They don't have to be!  Just
like the `const` qualifier on a data member and a member function,
why asking for consistency on two different things?  You happen
to see that the effects of `static` which works on a data member
and a member function are similar, and you call it "consistency",
but at least I don't think it has to apply to constexpr.

>> Yes!  So that we can teach "constexpr variables are just constant,
>> don't spent your time on figuring out *what* exactly they are".
>
> I don't think your proposal helps that.

Well, for example, so that in any place, you can just define
variables with `constexpr` without any storage specifier and
it just works like a constant.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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



.

On Wed, Jun 19, 2013 at 12:49 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On quarta-feira, 19 de junho de 2013 12.18.15, Richard Smith wrote:
>> constexpr is not limited to that purpose. It is also used to require
>> static initialization for a constant variable, for instance, and it
>> certainly doesn't prohibit taking the address of the variable, or
>> binding a reference to it, or calling a member function on it, all of
>> which require storage.
>
> Are we missing the ability to require static-initialisation of a non-const
> object?

Yes, we are. On the clang side, there's been some discussion of an
attribute for this ([[clang::const_init]] or similar). That said, some
people have suggested that they would prefer a compiler diagnostic for
any non-constant initialization or destruction (perhaps with an
attribute to suppress the warning for certain variables or for certain
classes). I think implementation experience in this area would be
particularly useful before we propose anything for standardization.

--

---
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_2660_28040039.1371677176331
Content-Type: text/plain; charset=ISO-8859-1



On Wednesday, June 19, 2013 9:48:50 PM UTC+1, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 3:19 PM, Jonathan Wakely <c...@kayari.org<javascript:>>
> wrote:
> >> But a variable defined in namespace scope default to have external
> >> linkage, then why a `const` qualifier can change its linkage?
> >
> > So that simple named constants in separate translation units don't
> interfere
> > and you don't have to be careful about avoiding name clashes.
>
> So that simple named constants in class scope are not duplicated
> for each object (not allowed, forever) and you don't have to care
> about what the constants actually are.
>

That's an argument in favour of static data members existing, not an
argument in favour of constexpr implying static.

We already have them, they work fine, making constexpr imply static adds no
new ability to the language and doesn't make it easier to express your
designs.


> > OK, but what about the consistency of constexpr data members and
> consexpr
> > member functions?
>
> Re-read your comment, consistency of a data member and a
> member function -- for what?


For whether they are static or not, obviously.

struct A {
  static constexpr int one = 1;
  static constexpr int two() { return 2; }
};

If I want A::one() and A::two() to be constexpr, I say so. If I want them
to be static, I say so.

You're proposing:

struct A {
  constexpr int one = 1;
  static constexpr int two() { return 2; }
};

If I glance at this code I do not immediately see that A::one is static. It
looks like an instance variable.

That's what I mean by consistency.

Now consider:

struct A {
  const int zero = 0;
  constexpr int one = 1;
  static constexpr int two()  { return 2; }
  constexpr int three()  { return 3; }
};

Are you really suggesting that it makes the language easier to teach that
A::zero is non-static and A::one is static?

How does your mental model of "constexpr means it's just a constant, you
don't need to care about storage.linkage etc." help here? Why does it imply
static on A::one but not A::three?  It's inconsistent.


--

---
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_2660_28040039.1371677176331
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Wednesday, June 19, 2013 9:48:50 PM UTC+1, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 3:19 PM, =
Jonathan Wakely &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"hPnXCBwa4BIJ">c...@kayari.org</a>&gt; wrote:
<br>&gt;&gt; But a variable defined in namespace scope default to have exte=
rnal
<br>&gt;&gt; linkage, then why a `const` qualifier can change its linkage?
<br>&gt;
<br>&gt; So that simple named constants in separate translation units don't=
 interfere
<br>&gt; and you don't have to be careful about avoiding name clashes.
<br>
<br>So that simple named constants in class scope are not duplicated
<br>for each object (not allowed, forever) and you don't have to care
<br>about what the constants actually are.
<br></blockquote><div><br></div><div>That's an argument in favour of static=
 data members existing, not an argument in favour of constexpr implying sta=
tic.</div><div><br></div><div>We already have them, they work fine, making =
constexpr imply static adds no new ability to the language and doesn't make=
 it easier to express your designs.</div><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">&gt; OK, but what about the consistency of cons=
texpr data members and consexpr
<br>&gt; member functions?
<br>
<br>Re-read your comment, consistency of a data member and a
<br>member function -- for what?</blockquote><div><br></div><div>For whethe=
r they are static or not, obviously.</div><div><br></div><div>struct A {</d=
iv><div>&nbsp; static constexpr int one =3D 1;</div><div>&nbsp; static cons=
texpr int two() { return 2; }</div><div>};</div><div><br></div><div>If I wa=
nt A::one() and A::two() to be constexpr, I say so. If I want them to be st=
atic, I say so.</div><div><br></div><div>You're proposing:</div><div><br></=
div><div><div>struct A {</div><div>&nbsp; constexpr int one =3D 1;</div><di=
v>&nbsp; static constexpr int two() { return 2; }</div><div>};</div></div><=
div><br></div><div>If I glance at this code I do not immediately see that A=
::one is static. It looks like an instance variable.</div><div><br></div><d=
iv>That's what I mean by consistency.</div><div><br></div><div>Now consider=
:</div><div><br></div><div><div><div>struct A {</div><div>&nbsp; const int =
zero =3D 0;</div><div>&nbsp; constexpr int one =3D 1;</div><div>&nbsp; stat=
ic constexpr int two() &nbsp;{ return 2; }</div><div>&nbsp; constexpr int t=
hree() &nbsp;{ return 3; }</div><div>};</div></div></div><div><br></div><di=
v>Are you really suggesting that it makes the language easier to teach that=
 A::zero is non-static and A::one is static?</div><div><br></div><div>How d=
oes your mental model of "constexpr means it's just a constant, you don't n=
eed to care about storage.linkage etc." help here? Why does it imply static=
 on A::one but not A::three? &nbsp;It's inconsistent.</div><div><br></div><=
div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_2660_28040039.1371677176331--

.

On Wed, Jun 19, 2013 at 5:26 PM, Jonathan Wakely <cxx@kayari.org> wrote:
> You're proposing:
>
> struct A {
>   constexpr int one = 1;
>   static constexpr int two() { return 2; }
> };
>
> If I glance at this code I do not immediately see that A::one is static. It
> looks like an instance variable.

It looks like a variable defined in a class scope, and it is. -- The purpose
is let you forget about `static` here.

> Now consider:
>
> struct A {
>   const int zero = 0;
>   constexpr int one = 1;
>   static constexpr int two()  { return 2; }
>   constexpr int three()  { return 3; }
> };
>
> Are you really suggesting that it makes the language easier to teach that
> A::zero is non-static and A::one is static?

It's not `constexpr`'s fault that `const` is a very bad name to express
`read-only`.

> How does your mental model of "constexpr means it's just a constant, you
> don't need to care about storage.linkage etc." help here? Why does it imply
> static on A::one but not A::three?  It's inconsistent.

Let me say it again: forget about static.  It's implemented as static,
but think it like a named defined in the class scope.  That's it.
constexpr data member and constexpr member function?  They don't
have to be the same.  There is no non-static constexpr data member.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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



.

On Wed, Jun 19, 2013 at 2:52 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Wed, Jun 19, 2013 at 5:26 PM, Jonathan Wakely <cxx@kayari.org> wrote:
>> You're proposing:
>>
>> struct A {
>>   constexpr int one = 1;
>>   static constexpr int two() { return 2; }
>> };
>>
>> If I glance at this code I do not immediately see that A::one is static. It
>> looks like an instance variable.
>
> It looks like a variable defined in a class scope, and it is. -- The purpose
> is let you forget about `static` here.
>
>> Now consider:
>>
>> struct A {
>>   const int zero = 0;
>>   constexpr int one = 1;
>>   static constexpr int two()  { return 2; }
>>   constexpr int three()  { return 3; }
>> };
>>
>> Are you really suggesting that it makes the language easier to teach that
>> A::zero is non-static and A::one is static?
>
> It's not `constexpr`'s fault that `const` is a very bad name to express
> `read-only`.
>
>> How does your mental model of "constexpr means it's just a constant, you
>> don't need to care about storage.linkage etc." help here? Why does it imply
>> static on A::one but not A::three?  It's inconsistent.
>
> Let me say it again: forget about static.  It's implemented as static,
> but think it like a named defined in the class scope.  That's it.
> constexpr data member and constexpr member function?  They don't
> have to be the same.  There is no non-static constexpr data member.

There is no such thing today, but that's not some fundamental
immutable property. We could, in principle, support non-static
constexpr members for classes:

struct A {
  constexpr int a = 123;
};
A a1, a2;
static_assert(a1.a == 123, "");
static_assert(&a1.a != &a2.a, "");

Note that I'm not proposing the above, or even saying that it's a good
idea, only that your proposal is not future-proof.

--

---
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_2345_20698650.1371680622022
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, June 19, 2013 2:52:38 PM UTC-7, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 5:26 PM, Jonathan Wakely <c...@kayari.org<javascript:>>
> wrote:
> > You're proposing:
> >
> > struct A {
> >   constexpr int one = 1;
> >   static constexpr int two() { return 2; }
> > };
> >
> > If I glance at this code I do not immediately see that A::one is static.
> It
> > looks like an instance variable.
>
> It looks like a variable defined in a class scope, and it is. -- The
> purpose
> is let you forget about `static` here.
>

You still haven't explained why omitting important keywords and
complicating the relationship between keywords is a *good* thing. Except
that it saves 7 keystrokes. How is that worth the confusion?

> How does your mental model of "constexpr means it's just a constant, you
> > don't need to care about storage.linkage etc." help here? Why does it
> imply
> > static on A::one but not A::three?  It's inconsistent.
>
> Let me say it again: forget about static.  It's implemented as static,
> but think it like a named defined in the class scope.  That's it.


You want it to work like a static data member. You what to access it like a
static data member. You want it to be treated like a static data member.

Therefore, it should be *declared* like a static data member too.

And if we had it to do over again, I would say that `const` globals should
also have had to use `static` to get internal linkage.

Also, what you want would require tortured spec language. Either you'd have
to replace every instance of the already overlong phrase "non-static data
members" with "non-static, non-constexpr data members", or you have to say
that `constexpr` data members are implicitly static.

C++ has enough implicit nonsense without adding more.

constexpr data member and constexpr member function?  They don't
> have to be the same.


Yes, they don't have to be the same. That doesn't *justify* making them
different.

--

---
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_2345_20698650.1371680622022
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, June 19, 2013 2:52:38 PM UTC-7, Zhihao Yuan wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 5:26 PM, Jonathan=
 Wakely &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"Piviw-5Lf4kJ">c...@kayari.org</a>&gt; wrote:
<br>&gt; You're proposing:
<br>&gt;
<br>&gt; struct A {
<br>&gt; &nbsp; constexpr int one =3D 1;
<br>&gt; &nbsp; static constexpr int two() { return 2; }
<br>&gt; };
<br>&gt;
<br>&gt; If I glance at this code I do not immediately see that A::one is s=
tatic. It
<br>&gt; looks like an instance variable.
<br>
<br>It looks like a variable defined in a class scope, and it is. -- The pu=
rpose
<br>is let you forget about `static` here.<br></blockquote><div><br>You sti=
ll haven't explained why omitting important keywords and complicating the r=
elationship between keywords is a <i>good</i> thing. Except that it saves 7=
 keystrokes. How is that worth the confusion?<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">
&gt; How does your mental model of "constexpr means it's just a constant, y=
ou
<br>&gt; don't need to care about storage.linkage etc." help here? Why does=
 it imply
<br>&gt; static on A::one but not A::three? &nbsp;It's inconsistent.
<br>
<br>Let me say it again: forget about static. &nbsp;It's implemented as sta=
tic,
<br>but think it like a named defined in the class scope.&nbsp;  That's it.=
</blockquote><div><br>You want it to work like a static data member. You wh=
at to access it like a static data member. You want it to be treated like a=
 static data member.<br><br>Therefore, it should be <i>declared</i> like a =
static data member too.<br><br>And if we had it to do over again, I would s=
ay that `const` globals should also have had to use `static` to get interna=
l linkage.<br><br>Also, what you want would require tortured spec language.=
 Either you'd have to replace every instance of the already overlong phrase=
 "non-static data members" with "non-static, non-constexpr data members", o=
r you have to say that `constexpr` data members are implicitly static.<br><=
br>C++ has enough implicit nonsense without adding more.<br><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">constexpr data member and constexpr=
 member function? &nbsp;They don't
<br>have to be the same.</blockquote><div><br>Yes, they don't have to be th=
e same. That doesn't <i>justify</i> making them different.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_2345_20698650.1371680622022--

.

On Wed, Jun 19, 2013 at 6:08 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> struct A {
>   constexpr int a = 123;
> };
> A a1, a2;
> static_assert(a1.a == 123, "");
> static_assert(&a1.a != &a2.a, "");
>
> Note that I'm not proposing the above, or even saying that it's a good
> idea, only that your proposal is not future-proof.

If we change it to

  static_assert(&a1.a == &a2.a, "");

I have a feeling it's more close to what I want -- a constant
has nothing to do with static keyword.  If the syntax object.name
can be overloaded to access a variable which is not per-
object, I think it's OK.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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



.

On Wed, Jun 19, 2013 at 6:23 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> You still haven't explained why omitting important keywords and complicating
> the relationship between keywords is a good thing. Except that it saves 7
> keystrokes. How is that worth the confusion?

Because `static` causes the confusion -- it's not needed else where
constexpr being used to define a variable.

> You want it to work like a static data member. You what to access it like a
> static data member. You want it to be treated like a static data member.
>
> Therefore, it should be declared like a static data member too.

Richard gives me a new thought: If we can use the per-object syntax
`object.name` to access it, then it's no longer a static data member
(but I want they are actually per-class).

Anyway, not matter whether the thought is valid or not, please, call it
'constexpr' data member.  Look at the title of this thread.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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



.

On Wed, Jun 19, 2013 at 6:31 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> Richard gives me a new thought: If we can use the per-object syntax
> `object.name` to access it, then it's no longer a static data member
> (but I want they are actually per-class).

Or, there is another option: constexpr data members are
only accessible within the class scope (including the member
function definition outside the syntactical area of the class
definition).  Thus, they are per-class, implemented as static
data member, but NOT accessible with the syntax

  Class::name

This should be what I initially want (namely, some constant
definition within the class scope).  I have to use private +
static + constexpr to achieve that.  But it LGTM if the
Class::name syntax is completely disabled.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_3981_16328247.1371684391690
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, June 20, 2013 12:00:51 AM UTC+1, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 6:31 PM, Zhihao Yuan <lic...@gmail.com<javascript:>>
> wrote:
> > Richard gives me a new thought: If we can use the per-object syntax
> > `object.name` to access it, then it's no longer a static data member
> > (but I want they are actually per-class).
>
> Or, there is another option: constexpr data members are
> only accessible within the class scope (including the member
> function definition outside the syntactical area of the class
> definition).  Thus, they are per-class, implemented as static
> data member, but NOT accessible with the syntax
>
>   Class::name
>
> This should be what I initially want (namely, some constant
> definition within the class scope).  I have to use private +
> static + constexpr to achieve that.  But it LGTM if the
> Class::name syntax is completely disabled.
>
>
Now it seems like you're just trying to invent a use for your idea, and it
still doesn't strike me as something that improves the language.  Just use
a private static member.

Why should they not be accessible as a qualified name? What purpose does
disabling that serve?  It makes the language even more inconsistent: now
you have a name which is private to a class scope but can't be qualified by
the class name ... why?




--

---
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_3981_16328247.1371684391690
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, June 20, 2013 12:00:51 AM UTC+1, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 6:31 PM, =
Zhihao Yuan &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"wgRpy2-FTo4J">lic...@gmail.com</a>&gt; wrote:
<br>&gt; Richard gives me a new thought: If we can use the per-object synta=
x
<br>&gt; `<a href=3D"http://object.name" target=3D"_blank">object.name</a>`=
 to access it, then it's no longer a static data member
<br>&gt; (but I want they are actually per-class).
<br>
<br>Or, there is another option: constexpr data members are
<br>only accessible within the class scope (including the member
<br>function definition outside the syntactical area of the class
<br>definition). &nbsp;Thus, they are per-class, implemented as static
<br>data member, but NOT accessible with the syntax
<br>
<br>&nbsp; Class::name
<br>
<br>This should be what I initially want (namely, some constant
<br>definition within the class scope). &nbsp;I have to use private +
<br>static + constexpr to achieve that. &nbsp;But it LGTM if the
<br>Class::name syntax is completely disabled.
<br><br></blockquote><div><br></div><div>Now it seems like you're just tryi=
ng to invent a use for your idea, and it still doesn't strike me as somethi=
ng that improves the language. &nbsp;Just use a private static member.</div=
><div><br></div><div>Why should they not be accessible as a qualified name?=
 What purpose does disabling that serve? &nbsp;It makes the language even m=
ore inconsistent: now you have a name which is private to a class scope but=
 can't be qualified by the class name ... why?</div><div><br></div><div><br=
></div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_3981_16328247.1371684391690--

.

------=_Part_1310_9839097.1371684652063
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, June 20, 2013 12:26:31 AM UTC+1, Jonathan Wakely wrote:
>
>
>
> On Thursday, June 20, 2013 12:00:51 AM UTC+1, Zhihao Yuan wrote:
>>
>> On Wed, Jun 19, 2013 at 6:31 PM, Zhihao Yuan <lic...@gmail.com> wrote:
>> > Richard gives me a new thought: If we can use the per-object syntax
>> > `object.name` to access it, then it's no longer a static data member
>> > (but I want they are actually per-class).
>>
>> Or, there is another option: constexpr data members are
>> only accessible within the class scope (including the member
>> function definition outside the syntactical area of the class
>> definition).  Thus, they are per-class, implemented as static
>> data member, but NOT accessible with the syntax
>>
>>   Class::name
>>
>> This should be what I initially want (namely, some constant
>> definition within the class scope).  I have to use private +
>> static + constexpr to achieve that.  But it LGTM if the
>> Class::name syntax is completely disabled.
>>
>>
> Now it seems like you're just trying to invent a use for your idea, and it
> still doesn't strike me as something that improves the language.  Just use
> a private static member.
>
> Why should they not be accessible as a qualified name? What purpose does
> disabling that serve?  It makes the language even more inconsistent: now
> you have a name which is private to a class scope but can't be qualified by
> the class name ... why?
>
>
Anyway, if you think the idea has merit write a full proposal.  It's been
fairly universally dismissed here, but if you write a paper explaining its
benefits maybe you'll convince the committee.

--

---
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_1310_9839097.1371684652063
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, June 20, 2013 12:26:31 AM UTC+1, Jonathan Wakely wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Thursday, June 20,=
 2013 12:00:51 AM UTC+1, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Wed, Jun 19, 2013 at 6:31 PM, Zhihao Yuan &lt;<a>lic...@gmail.co=
m</a>&gt; wrote:
<br>&gt; Richard gives me a new thought: If we can use the per-object synta=
x
<br>&gt; `<a href=3D"http://object.name" target=3D"_blank">object.name</a>`=
 to access it, then it's no longer a static data member
<br>&gt; (but I want they are actually per-class).
<br>
<br>Or, there is another option: constexpr data members are
<br>only accessible within the class scope (including the member
<br>function definition outside the syntactical area of the class
<br>definition). &nbsp;Thus, they are per-class, implemented as static
<br>data member, but NOT accessible with the syntax
<br>
<br>&nbsp; Class::name
<br>
<br>This should be what I initially want (namely, some constant
<br>definition within the class scope). &nbsp;I have to use private +
<br>static + constexpr to achieve that. &nbsp;But it LGTM if the
<br>Class::name syntax is completely disabled.
<br><br></blockquote><div><br></div><div>Now it seems like you're just tryi=
ng to invent a use for your idea, and it still doesn't strike me as somethi=
ng that improves the language. &nbsp;Just use a private static member.</div=
><div><br></div><div>Why should they not be accessible as a qualified name?=
 What purpose does disabling that serve? &nbsp;It makes the language even m=
ore inconsistent: now you have a name which is private to a class scope but=
 can't be qualified by the class name ... why?</div><div><br></div></blockq=
uote><div><br></div><div>Anyway, if you think the idea has merit write a fu=
ll proposal. &nbsp;It's been fairly universally dismissed here, but if you =
write a paper explaining its benefits maybe you'll convince the committee.<=
/div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_1310_9839097.1371684652063--

.

On Wed, Jun 19, 2013 at 7:26 PM, Jonathan Wakely <cxx@kayari.org> wrote:
> Why should they not be accessible as a qualified name? What purpose does
> disabling that serve?  It makes the language even more inconsistent: now you
> have a name which is private to a class scope but can't be qualified by the
> class name ... why?

Yea, it is something not exist in C++, since anything declared in
class scope subscribe to access control.  When I got the idea,
I was viewing a class scope as a function scope -- just give me
some constant definitions...

Anyway, I don't like to see the static keyword here.  You think it's
consistent with data member and member function within a class,
while I don't think so... To me, it's more like a `typedef` within the
class scope -- you don't need to use `static` to say it's per-class,
it's just per-class.  And if I view the class scope like other scopes,
then you don't need to use `static` to specify its linkage, that
doesn't matter!

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_2517_9723361.1371687570772
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, June 19, 2013 4:39:21 PM UTC-7, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 7:26 PM, Jonathan Wakely <c...@kayari.org<javascript:>>
> wrote:
> > Why should they not be accessible as a qualified name? What purpose does
> > disabling that serve?  It makes the language even more inconsistent: now
> you
> > have a name which is private to a class scope but can't be qualified by
> the
> > class name ... why?
>
> Yea, it is something not exist in C++, since anything declared in
> class scope subscribe to access control.  When I got the idea,
> I was viewing a class scope as a function scope -- just give me
> some constant definitions...
>
> Anyway, I don't like to see the static keyword here.  You think it's
> consistent with data member and member function within a class,
> while I don't think so... To me, it's more like a `typedef` within the
> class scope -- you don't need to use `static` to say it's per-class,
> it's just per-class.


But it's a variable. A typedef is a type name, just like an inner type. A
variable is a variable. You can take the address of a variable; you can't
take the address of a typename.

The fact that the variable happens to be a constant doesn't change the fact
that it's still a variable. It represents an object; just an immutable one.

Why should we change how object definitions work in this one case?

Furthermore, your logic is even weirder. If you view constexpr member
variables like a `typedef`, then you should want to access them the exact
same way as you would a typedef: Typename::variableName.

Your view of this idea seems very... confused. You seem to latch onto a
concept when it sounds useful to you, then abandon it if someone shows you
how it doesn't work for you. For example, it was you who first brought up
`const` in relation to your idea, claiming, "it's more like the `const` in
namespace scope has internal linkage." But once someone showed you how that
argument actually worked against the idea, then it became, "Please do not
use the behavior of `const` to prove the behavior of `constexpr`.  They are
different, and there is no need for them to be 'consistent'."

I have no idea what the conceptual foundation of this idea is, besides the
mistaken confusion of "internal linkage" with "member-static" (see below).

You have spent more time and keystrokes arguing for this idea than you will
*ever* spend writing or *reading* the `static` in front of `constexpr`
members.

And if I view the class scope like other scopes,
> then you don't need to use `static` to specify its linkage, that
> doesn't matter!
>

And that's your problem: class scopes are *not* like other scopes. `static`
members of a class do not have internal linkage (necessarily). `static`
when applied to members does something altogether different than it does
when applied to variables and functions declared at namespace scope.
Linkage has nothing to do with what `static` means for members of classes.
`static` is an overloaded keyword that means different things in different
contexts.

You can try to view class scopes however you like, but the standard
strongly disagrees.

--

---
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_2517_9723361.1371687570772
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, June 19, 2013 4:39:21 PM UTC-7, Zhihao Yuan wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 7:26 PM, Jonathan=
 Wakely &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"NXXZOLiw23MJ">c...@kayari.org</a>&gt; wrote:
<br>&gt; Why should they not be accessible as a qualified name? What purpos=
e does
<br>&gt; disabling that serve? &nbsp;It makes the language even more incons=
istent: now you
<br>&gt; have a name which is private to a class scope but can't be qualifi=
ed by the
<br>&gt; class name ... why?
<br>
<br>Yea, it is something not exist in C++, since anything declared in
<br>class scope subscribe to access control. &nbsp;When I got the idea,
<br>I was viewing a class scope as a function scope -- just give me
<br>some constant definitions...
<br>
<br>Anyway, I don't like to see the static keyword here. &nbsp;You think it=
's
<br>consistent with data member and member function within a class,
<br>while I don't think so... To me, it's more like a `typedef` within the
<br>class scope -- you don't need to use `static` to say it's per-class,
<br>it's just per-class.</blockquote><div><br>But it's a variable. A typede=
f is a type name, just like an inner type. A variable is a variable. You ca=
n take the address of a variable; you can't take the address of a typename.=
<br><br>The fact that the variable happens to be a constant doesn't change =
the fact that it's still a variable. It represents an object; just an immut=
able one.<br><br>Why should we change how object definitions work in this o=
ne case?<br><br>Furthermore, your logic is even weirder. If you view conste=
xpr member variables like a `typedef`, then you should want to access them =
the exact same way as you would a typedef: Typename::variableName.<br><br>Y=
our view of this idea seems very... confused. You seem to latch onto a conc=
ept when it sounds useful to you, then abandon it if someone shows you how =
it doesn't work for you. For example, it was you who first brought up `cons=
t` in relation to your idea, claiming, "it's
more like the `const` in namespace scope has internal
linkage." But once someone showed you how that argument actually worked aga=
inst the idea, then it became, "Please do not use the behavior of `const` t=
o prove the behavior of
`constexpr`. &nbsp;They are different, and there is no need for them to
be 'consistent'."<br><br>I have no idea what the conceptual foundation of t=
his idea is, besides the mistaken confusion of "internal linkage" with "mem=
ber-static" (see below).<br><br>You have spent more time and keystrokes arg=
uing for this idea than you will <i>ever</i> spend writing or <i>reading</i=
> the `static` in front of `constexpr` members.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">And if I view the class scope like other sco=
pes,
<br>then you don't need to use `static` to specify its linkage, that
<br>doesn't matter!<br></blockquote><div><br>And that's your problem: class=
 scopes are <i>not</i> like other scopes. `static` members of a class do no=
t have internal linkage (necessarily). `static` when applied to members doe=
s something altogether different than it does when applied to variables and=
 functions declared at namespace scope. Linkage has nothing to do with what=
 `static` means for members of classes. `static` is an overloaded keyword t=
hat means different things in different contexts.<br><br>You can try to vie=
w class scopes however you like, but the standard strongly disagrees.<br></=
div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_2517_9723361.1371687570772--

.

On Wed, Jun 19, 2013 at 8:19 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> The fact that the variable happens to be a constant doesn't change the fact
> that it's still a variable. It represents an object; just an immutable one.

No, that's const, not constexpr.  constexpr has the interfaces of an
object, like, can be taken address, but they can be regarded and
used as real constant.

> Furthermore, your logic is even weirder. If you view constexpr member
> variables like a `typedef`, then you should want to access them the exact
> same way as you would a typedef: Typename::variableName.

There were two different ideas here, and in the first model, it's allowed.

> Your view of this idea seems very... confused. You seem to latch onto a
> concept when it sounds useful to you, then abandon it if someone shows you
> how it doesn't work for you.

Of course, if there is one thing 100% working for me, then why I
post here?

> For example, it was you who first brought up
> `const` in relation to your idea, claiming, "it's more like the `const` in
> namespace scope has internal linkage." But once someone showed you how that
> argument actually worked against the idea, then it became, "Please do not
> use the behavior of `const` to prove the behavior of `constexpr`.  They are
> different, and there is no need for them to be 'consistent'."

The rationales behind them are similar, but they behavior differently,
so I buy the rationale to build a new behavior, what's problem?

> I have no idea what the conceptual foundation of this idea is, besides the
> mistaken confusion of "internal linkage" with "member-static" (see below).

I'm pretty sure made no mistaken here, you have the feeling because
I tried two different models.

> You have spent more time and keystrokes arguing for this idea than you will
> ever spend writing or reading the `static` in front of `constexpr` members.

You are surly right :)

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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



.

On Wed, Jun 19, 2013 at 5:39 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Wed, Jun 19, 2013 at 8:19 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> The fact that the variable happens to be a constant doesn't change the fact
>> that it's still a variable. It represents an object; just an immutable one.
>
> No, that's const, not constexpr.  constexpr has the interfaces of an
> object, like, can be taken address, but they can be regarded and
> used as real constant.

constexpr objects can have mutable members. After the initialization
completes, there really isn't a lot of difference between a const
object and a constexpr object. The latter can be used in constant
expressions in more cases, simply because the initialization itself
can be evaluated during translation.

--

---
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_4726_23067070.1371691441158
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, June 19, 2013 5:39:20 PM UTC-7, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 8:19 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > The fact that the variable happens to be a constant doesn't change the
> fact
> > that it's still a variable. It represents an object; just an immutable
> one.
>
> No, that's const, not constexpr.  constexpr has the interfaces of an
> object, like, can be taken address, but they can be regarded and
> used as real constant.


You can think of it as whatever you like; as far as the Standard for
Programming Language C++ is concerned, it's a variable. It looks like a
variable. It acts like a variable. It reacts in every way like a regular
old variable as far as C++ is concerned. It has *storage* with a particular
size, alignment, and memory location. They can be of pointer and reference
types. And so forth.

It is not a literal or macro or other kind of thing that just disappears
into the aether after compilation.

Yes, there are differences, but there are differences between a mutable
variable and a `const` variable too. Yet they're both still *variables*.
Just like `constexpr` variables are.

We shouldn't make changes to the standard based on what someone wants to
think of something as. We should make them based on what something is. And
if you want to make a variable member-static, whether mutable, `const`, or
`constexpr`, we already have syntax for that.

--

---
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_4726_23067070.1371691441158
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, June 19, 2013 5:39:20 PM UTC-7, Zhihao Yuan wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 8:19 PM, Nicol Bo=
las &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
3VTJTHT6TiwJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; The fact that the variable happens to be a constant doesn't change=
 the fact
<br>&gt; that it's still a variable. It represents an object; just an immut=
able one.
<br>
<br>No, that's const, not constexpr. &nbsp;constexpr has the interfaces of =
an
<br>object, like, can be taken address, but they can be regarded and
<br>used as real constant.</blockquote><div><br></div>You can think of it a=
s whatever you like; as far as the Standard for Programming Language C++ is=
 concerned, it's a variable. It looks like a variable. It acts like a varia=
ble. It reacts in every=20
way like a regular old variable as far as C++ is concerned. It has <i>stora=
ge</i> with a particular size, alignment, and memory location. They can be =
of pointer and reference types. And so forth.<br><br>It is not a literal or=
 macro or other kind of thing that just disappears into the aether after co=
mpilation.<br><br>Yes, there are differences, but there are differences bet=
ween a mutable variable and a `const` variable too. Yet they're both still =
<i>variables</i>. Just like `constexpr` variables are.<br><br>We shouldn't =
make changes to the standard based on what someone wants to think of someth=
ing as. We should make them based on what something is. And if you want to =
make a variable member-static, whether mutable, `const`, or `constexpr`, we=
 already have syntax for that.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_4726_23067070.1371691441158--

.

On Wed, Jun 19, 2013 at 9:24 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> It is not a literal or macro or other kind of thing that just disappears
> into the aether after compilation.

Quoted from N2235:

As for other `const` variables, storage need not be allocated for
a constant-expression datum, unless its address is taken.
For example:

  constexpr double x = 9484.748;
  const double* p = &x; // the &x forces x into memory

That's why I say it has all the interfaces of a variable,
but it's not necessarily to *be* a variable.  constexpr
is designed to visualize the constant expression
(as its name shows), and we should strength it
in this direction instead of to be limited by the extra
supplementary features which made it feasibly
consumable by the standard.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_2681_15941705.1371716444175
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, June 20, 2013 2:54:03 AM UTC+1, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 9:24 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > It is not a literal or macro or other kind of thing that just disappears
> > into the aether after compilation.
>
> Quoted from N2235:
>
> As for other `const` variables, storage need not be allocated for
> a constant-expression datum, unless its address is taken.
> For example:
>
>   constexpr double x = 9484.748;
>   const double* p = &x; // the &x forces x into memory
>
> That's why I say it has all the interfaces of a variable,
> but it's not necessarily to *be* a variable.  constexpr
> is designed to visualize the constant expression
> (as its name shows), and we should strength it
> in this direction instead of to be limited by the extra
> supplementary features which made it feasibly
> consumable by the standard.
>
>
No we should not, not like this anyway.

I think you have a solution in search of a problem.  Give it up.






--

---
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_2681_15941705.1371716444175
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, June 20, 2013 2:54:03 AM UTC+1, Zhihao Yuan wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 9:24 PM, N=
icol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"nFTzBjwsFlcJ">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; It is not a literal or macro or other kind of thing that just disa=
ppears
<br>&gt; into the aether after compilation.
<br>
<br>Quoted from N2235:
<br>
<br>As for other `const` variables, storage need not be allocated for
<br>a constant-expression datum, unless its address is taken.
<br>For example:
<br>
<br>&nbsp; constexpr double x =3D 9484.748;
<br>&nbsp; const double* p =3D &amp;x; // the &amp;x forces x into memory
<br>
<br>That's why I say it has all the interfaces of a variable,
<br>but it's not necessarily to *be* a variable. &nbsp;constexpr
<br>is designed to visualize the constant expression
<br>(as its name shows), and we should strength it
<br>in this direction instead of to be limited by the extra
<br>supplementary features which made it feasibly
<br>consumable by the standard.
<br>
<br></blockquote><div><br></div><div>No we should not, not like this anyway=
..</div><div><br></div><div>I think you have a solution in search of a probl=
em. &nbsp;Give it up.</div><div><br></div><div><br></div><div><br></div><di=
v><br></div><div>&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_2681_15941705.1371716444175--

.