------=_Part_2205_1697016241.1432472971159
Content-Type: multipart/alternative;
 boundary="----=_Part_2206_1021646680.1432472971160"

------=_Part_2206_1021646680.1432472971160
Content-Type: text/plain; charset=UTF-8

Hi all!


I am thinking on extending constexpr expressions with compile time code
generation. As Yuriy Smirnov proposed in the 'Yet another compile-time
reflection' topic we can introduce a new type of scope in constexpr
functions which is parsed as a normal block but the content will be merged
to the invocation context instead of compiling it.

Here is an example:

  constexpr void generateVariables(const ast_class& myClass) {
    for (const auto& member : myClass.members()) {
      #<emit> (const auto& member) // this part is parsed here as
        int #<(member.name())>;    // a normal block { ... } but the
      #</emit>                     // content not compiled to here
    }
  }


A syntax alternative can be an inline lambda syntax:

  constexpr void generateVariables(const ast_class& myClass) {
    for (const auto& member : myClass.members()) {
      inline class [] (const auto& member) {
        int #<(member.name())>;
      }
    }
  }

This void constexpr function or method would be invoked with a special
syntax: #!

  template<typename T>
  class Test
  {
    #!generateVariables(typeid<T>); // emit block merged to here
  };



Note, this code snippet contains some other proposed feature: the
constexpr-id #<(member.name())> and typeid<T>.
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/constexpr_id_proposal.md


What do you think?


Peter

--

---
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_2206_1021646680.1432472971160
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all!<br><br><br>I am thinking on extending constexpr ex=
pressions with compile time code generation. As Yuriy Smirnov proposed in t=
he 'Yet another compile-time reflection' topic we can introduce a new type =
of scope in constexpr functions which is parsed as a normal block but the c=
ontent will be merged to the invocation context instead of compiling it.<br=
><br>Here is an example:<br><br><pre>  <span class=3D"pl-k">constexpr</span=
> <span class=3D"pl-k">void</span> <span class=3D"pl-en">generateVariables<=
/span>(<span class=3D"pl-k">const</span> ast_class&amp; myClass) {
    <span class=3D"pl-k">for</span> (<span class=3D"pl-k">const</span> <spa=
n class=3D"pl-k">auto</span>&amp; member : myClass.<span class=3D"pl-c1">me=
mbers</span>()) {
      #&lt;emit&gt; (<span class=3D"pl-k">const</span> <span class=3D"pl-k"=
>auto</span>&amp; member) // this part is parsed here as
        <span class=3D"pl-k">int</span> #&lt;(member.<span class=3D"pl-c1">=
name</span>())&gt;;    // a normal block { ... } but the <br>     &nbsp;#&l=
t;/emit&gt;                     // content not compiled to here
    }
  }</pre><br><pre><span style=3D"font-family: arial,sans-serif;">A syntax a=
lternative can be an inline lambda syntax:<br></span><br>  <span class=3D"p=
l-k">constexpr</span> <span class=3D"pl-k">void</span> <span class=3D"pl-en=
">generateVariables</span>(<span class=3D"pl-k">const</span> ast_class&amp;=
 myClass) {
    <span class=3D"pl-k">for</span> (<span class=3D"pl-k">const</span> <spa=
n class=3D"pl-k">auto</span>&amp; member : myClass.<span class=3D"pl-c1">me=
mbers</span>()) {
      inline class [] (<span class=3D"pl-k">const</span> <span class=3D"pl-=
k">auto</span>&amp; member) {
        <span class=3D"pl-k">int</span> #&lt;(member.<span class=3D"pl-c1">=
name</span>())&gt;;<br>      }
    }
  }<br><br></pre>This void constexpr function or method would be invoked wi=
th a special syntax: #!<br><br><pre>  <span class=3D"pl-k">template</span>&=
lt;<span class=3D"pl-k">typename</span> T&gt;
  <span class=3D"pl-k">class</span> <span class=3D"pl-en">Test</span>
  {
    #!generateVariables(<span class=3D"pl-k">typeid</span>&lt;T&gt;); // em=
it block merged to here
  };</pre><br><br>Note, this code snippet contains some other proposed feat=
ure: the constexpr-id #&lt;(member.<span class=3D"pl-c1">name</span>())&gt;=
 and typeid&lt;T&gt;.<br><a href=3D"https://github.com/hun-nemethpeter/cpp-=
reflector-mini/blob/master/constexpr-ast/constexpr_id_proposal.md">https://=
github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/con=
stexpr_id_proposal.md<br></a><br><br>What do you think?<br><br><br>Peter<br=
></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2206_1021646680.1432472971160--
------=_Part_2205_1697016241.1432472971159--

.

On 24 May 2015 at 16:09,  <hun.nemethpeter@gmail.com> wrote:
> Hi all!
>
>
> I am thinking on extending constexpr expressions with compile time code
> generation. As Yuriy Smirnov proposed in the 'Yet another compile-time
> reflection' topic we can introduce a new type of scope in constexpr
> functions which is parsed as a normal block but the content will be merged
> to the invocation context instead of compiling it.
>
> Here is an example:
>
>   constexpr void generateVariables(const ast_class& myClass) {
>     for (const auto& member : myClass.members()) {
>       #<emit> (const auto& member) // this part is parsed here as
>         int #<(member.name())>;    // a normal block { ... } but the
>       #</emit>                     // content not compiled to here
>     }
>   }
>
>
> A syntax alternative can be an inline lambda syntax:
>
>   constexpr void generateVariables(const ast_class& myClass) {
>     for (const auto& member : myClass.members()) {
>       inline class [] (const auto& member) {
>         int #<(member.name())>;
>       }
>     }
>   }
>
> This void constexpr function or method would be invoked with a special
> syntax: #!
>
>   template<typename T>
>   class Test
>   {
>     #!generateVariables(typeid<T>); // emit block merged to here
>   };
>
>
>
> Note, this code snippet contains some other proposed feature: the
> constexpr-id #<(member.name())> and typeid<T>.
> https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/constexpr_id_proposal.md
>
>
> What do you think?


I think it would be most useful to be able to express things like
"reflect all data members of X as members of Y, with potential
transformations like
turning all of them into references that then get initialized with the
corresponding member
of an X object" or "generate data members of X from other, perhaps
much more general
data, processing it any which way", but I doubt there should
necessarily be a for-loop
involved in it. I would generalize the idea with a term "computed
declaration", perhaps.

--

---
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_204_2086428779.1432482916332
Content-Type: multipart/alternative;
 boundary="----=_Part_205_1703566084.1432482916336"

------=_Part_205_1703566084.1432482916336
Content-Type: text/plain; charset=UTF-8

On Sunday, May 24, 2015 at 9:09:31 AM UTC-4, hun.nem...@gmail.com wrote:

> What do you think?
>

I think it's a terrible idea, based on a serious confusion of
responsibilities.

I get the basic point: you want to be able to execute some code that will
generate a list of types for a class based on some compile-time reflected
data passed in.

My problem with this is that you're using a *function* to do this.
Functions don't generate lists of types; functions *can't* generate lists
of types. And to give them such power, even just in `constexpr` cases,
represents a very bizarre and confusing construct.

You're basically saying that calling this function at function scope will
spontaneously result in the generation of a bunch of variable definitions.
There's nothing in the function signature that even suggests that this kind
of chaos can be created. I for one don't like the idea that a mere function
call can have such wide-ranging, compile-time side-effects.

Functions return values; they cannot define variables outside of their
scope.

Not only that, you're violating the whole notion of being able to call
`constexpr` functions at runtime. What happens when I call this function
with a runtime "ast_class" or whatever?

This is a good example of the "when all you have is a hammer, every problem
starts looking like a nail" issue. `constexpr` should not be considered a
way to do arbitrary things at compile time. It's a construct for declaring
that a function may be able to be executed at compile-time, and therefore
`constexpr` functions are limited to what *functions* can do. Even the
whole "let's do concepts through contexpr" stuff did not fundamentally
change what a `constexpr` function was.

This functionality would make far more sense if it was its own separate
construct, with its own separate definitions and syntax. This way, a user
knows that this is not a function, that it does not play by the rules of
functions, and the user will not confuse it for a function call. It can be
given exactly and only the syntax we need it to have, and you don't have to
deal with a question likes, "so what does it return?" or "how do you call a
function at class scope?"

Or you can just do it up through template metaprogramming. And if there's a
problem with understanding that, then maybe there should be some targeted
syntax/library improvements applied there to smooth the user process out
(say, Boost.Fusion).

--

---
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_205_1703566084.1432482916336
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, May 24, 2015 at 9:09:31 AM UTC-4, hun.nem...@gm=
ail.com wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">What do you think?<br></div></blockquote><div><br>I think it's a terri=
ble idea, based on a serious confusion of responsibilities.<br><br>I get th=
e basic point: you want to be able to execute some code that will generate =
a list of types for a class based on some compile-time reflected data passe=
d in.<br><br>My problem with this is that you're using a <i>function</i> to=
 do this. Functions don't generate lists of types; functions <i>can't</i> g=
enerate lists of types. And to give them such power, even just in `constexp=
r` cases, represents a very bizarre and confusing construct.<br><br>You're =
basically saying that calling this function at function scope will spontane=
ously result in the generation of a bunch of variable definitions. There's =
nothing in the function signature that even suggests that this kind of chao=
s can be created. I for one don't like the idea that a mere function call c=
an have such wide-ranging, compile-time side-effects.<br><br>Functions retu=
rn values; they cannot define variables outside of their scope.<br><br>Not =
only that, you're violating the whole notion of being able to call `constex=
pr` functions at runtime. What happens when I call this function with a run=
time "ast_class" or whatever?<br></div><br>This is a good example of the "w=
hen all you have is a hammer, every problem starts looking like a nail" iss=
ue. `constexpr` should not be considered a way to do arbitrary things at co=
mpile time. It's a construct for declaring that a function may be able to b=
e executed at compile-time, and therefore `constexpr` functions are limited=
 to what <i>functions</i> can do. Even the whole "let's do concepts through=
 contexpr" stuff did not fundamentally change what a `constexpr` function w=
as.<br><br>This functionality would make far more sense if it was its own s=
eparate construct, with its own separate definitions and syntax. This way, =
a user knows that this is not a function, that it does not play by the rule=
s of functions, and the user will not confuse it for a function call. It ca=
n be given exactly and only the syntax we need it to have, and you don't ha=
ve to deal with a question likes, "so what does it return?" or "how do you =
call a function at class scope?"<br><br>Or you can just do it up through te=
mplate metaprogramming. And if there's a problem with understanding that, t=
hen maybe there should be some targeted syntax/library improvements applied=
 there to smooth the user process out (say, Boost.Fusion).<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_205_1703566084.1432482916336--
------=_Part_204_2086428779.1432482916332--

.

--089e0158bf10962b0c0516d81fe4
Content-Type: text/plain; charset=UTF-8

2015-05-24 17:55 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:

> On Sunday, May 24, 2015 at 9:09:31 AM UTC-4, hun.nem...@gmail.com wrote:
>
>> What do you think?
>>
>
> I think it's a terrible idea, based on a serious confusion of
> responsibilities.
>
> I get the basic point: you want to be able to execute some code that will
> generate a list of types for a class based on some compile-time reflected
> data passed in.
>
> My problem with this is that you're using a *function* to do this.
> Functions don't generate lists of types; functions *can't* generate lists
> of types. And to give them such power, even just in `constexpr` cases,
> represents a very bizarre and confusing construct.
>
I used a constexpr void function which is basically a procedure. And a
procedure just execute commands. In this case this procedure emit
declarations.


>
> You're basically saying that calling this function at function scope will
> spontaneously result in the generation of a bunch of variable definitions.
> There's nothing in the function signature that even suggests that this kind
> of chaos can be created. I for one don't like the idea that a mere function
> call can have such wide-ranging, compile-time side-effects.
>
Not really spontaneously. You have to use the #! syntax for calling such a
constexpr  Without that syntax that emit block does nothing. It's a good
question to mark or not mark the signature of this new kind of constexpr.
For example using an exclamation mark can be a solution here. It would be
consistent with the #! calling syntax.

constexpr! void generateVariables(const ast_class& myClass) {




>
> Functions return values; they cannot define variables outside of their
> scope.
>
A void function doesn't return value. But yeah, this code
emitting/generating thing is a new feature.



>
> Not only that, you're violating the whole notion of being able to call
> `constexpr` functions at runtime. What happens when I call this function
> with a runtime "ast_class" or whatever?
>
You can use it runtime. The rule is that emit block is just a no-op in
runtime. Emit block is only used when the consexpr is called with the #!
syntax.


>
> This is a good example of the "when all you have is a hammer, every
> problem starts looking like a nail" issue. `constexpr` should not be
> considered a way to do arbitrary things at compile time. It's a construct
> for declaring that a function may be able to be executed at compile-time,
> and therefore `constexpr` functions are limited to what *functions* can
> do. Even the whole "let's do concepts through contexpr" stuff did not
> fundamentally change what a `constexpr` function was.
>
I know the limitations of constexpr that is why I want to extend it. I just
use the constexpr as a compile time script.


>
> This functionality would make far more sense if it was its own separate
> construct, with its own separate definitions and syntax. This way, a user
> knows that this is not a function, that it does not play by the rules of
> functions, and the user will not confuse it for a function call. It can be
> given exactly and only the syntax we need it to have, and you don't have to
> deal with a question likes, "so what does it return?" or "how do you call a
> function at class scope?"
>
Ok. This is a good reason to mark these constexpr. But it will be just a
syntax sugar. So

constexpr!

will be just a notation.


>
> Or you can just do it up through template metaprogramming. And if there's
> a problem with understanding that, then maybe there should be some targeted
> syntax/library improvements applied there to smooth the user process out
> (say, Boost.Fusion).
>
You can't create code with TMP.

--

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

--089e0158bf10962b0c0516d81fe4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2015-05-24 17:55 GMT+02:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><span class=3D"">On Sunday, May 24, 2015 at 9:09:31 AM UTC-4, <a href=3D=
"mailto:hun.nem...@gmail.com" target=3D"_blank">hun.nem...@gmail.com</a> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
What do you think?<br></div></blockquote></span><div><br>I think it&#39;s a=
 terrible idea, based on a serious confusion of responsibilities.<br><br>I =
get the basic point: you want to be able to execute some code that will gen=
erate a list of types for a class based on some compile-time reflected data=
 passed in.<br><br>My problem with this is that you&#39;re using a <i>funct=
ion</i> to do this. Functions don&#39;t generate lists of types; functions =
<i>can&#39;t</i> generate lists of types. And to give them such power, even=
 just in `constexpr` cases, represents a very bizarre and confusing constru=
ct.<br></div></div></blockquote><div>I used a constexpr void function which=
 is basically a procedure. And a procedure just execute commands. In this c=
ase this procedure emit declarations.<br></div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br>You&#39;re=
 basically saying that calling this function at function scope will spontan=
eously result in the generation of a bunch of variable definitions. There&#=
39;s nothing in the function signature that even suggests that this kind of=
 chaos can be created. I for one don&#39;t like the idea that a mere functi=
on call can have such wide-ranging, compile-time side-effects.<br></div></d=
iv></blockquote><div>Not really spontaneously. You have to use the #! synta=
x for calling such a constexpr=C2=A0 Without that syntax that emit block do=
es nothing. It&#39;s a good question to mark or not mark the signature of t=
his new kind of constexpr. For example using an exclamation mark can be a s=
olution here. It would be consistent with the #! calling syntax. <br></div>=
<div><pre><span>constexpr</span>! <span>void</span> <span>generateVariables=
</span>(<span>const</span> ast_class&amp; myClass) {</pre><br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br>=
Functions return values; they cannot define variables outside of their scop=
e.<br></div></div></blockquote><div>A void function doesn&#39;t return valu=
e. But yeah, this code emitting/generating thing is a new feature.<br></div=
><div><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div><br>Not only that, you&#39;re violating the whole notion=
 of being able to call `constexpr` functions at runtime. What happens when =
I call this function with a runtime &quot;ast_class&quot; or whatever?<br><=
/div></div></blockquote><div>You can use it runtime. The rule is that emit =
block is just a no-op in runtime. Emit block is only used when the consexpr=
 is called with the #! syntax.<br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><br>This is a =
good example of the &quot;when all you have is a hammer, every problem star=
ts looking like a nail&quot; issue. `constexpr` should not be considered a =
way to do arbitrary things at compile time. It&#39;s a construct for declar=
ing that a function may be able to be executed at compile-time, and therefo=
re `constexpr` functions are limited to what <i>functions</i> can do. Even =
the whole &quot;let&#39;s do concepts through contexpr&quot; stuff did not =
fundamentally change what a `constexpr` function was.<br></div></blockquote=
><div>I know the limitations of constexpr that is why I want to extend it. =
I just use the constexpr as a compile time script.<br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br>Th=
is functionality would make far more sense if it was its own separate const=
ruct, with its own separate definitions and syntax. This way, a user knows =
that this is not a function, that it does not play by the rules of function=
s, and the user will not confuse it for a function call. It can be given ex=
actly and only the syntax we need it to have, and you don&#39;t have to dea=
l with a question likes, &quot;so what does it return?&quot; or &quot;how d=
o you call a function at class scope?&quot;<br></div></blockquote><div>Ok. =
This is a good reason to mark these constexpr. But it will be just a syntax=
 sugar. So <br><pre><span>constexpr</span>!</pre></div><div>will be just a =
notation.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><br>Or you can just do it up through template m=
etaprogramming. And if there&#39;s a problem with understanding that, then =
maybe there should be some targeted syntax/library improvements applied the=
re to smooth the user process out (say, Boost.Fusion).<br></div></blockquot=
e></div></div>You can&#39;t create code with TMP.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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 />

--089e0158bf10962b0c0516d81fe4--

.

------=_Part_1049_1212568436.1432495421955
Content-Type: multipart/alternative;
 boundary="----=_Part_1050_17893822.1432495421955"

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

OK, you seem to have missed my point, so let me start over.

A function is not an arbitrary construct of commands. It is a specific=20
concept that has certain, very specific limitations on what it can do.=20
Functions can change values, adjust memory, call other functions, loop,=20
throw exceptions, return values, and so forth. This is without regard to=20
*when* that function executes.

At the same time, functions are specifically not empowered with certain=20
other things. A function cannot modify the scope of its caller. Because of=
=20
this, you can look at a function in isolation and know what you're getting;=
=20
it's all right there in the function body. You can see every definition,=20
every statement, everything that happens within a function, right there in=
=20
the text. Calling other functions doesn't change the nature of the caller;=
=20
a function is defined by its own source code and nobody else's.

What you are suggesting is to allow functions to modify their caller's=20
scope. Why? I'm not asking why you want to have a named sequence of steps=
=20
that modifies enclosing scopes. I'm asking why you want a *function* to be=
=20
able to do this.

The only reason I can see for why you want to hijack constexpr functions=20
for this is because... well, they're there. Compilers must already have=20
some way of calling them at compile-time. So you're not suggesting this=20
features because it's the best way (or even a good way) for people to use=
=20
the feature. It's simply because it's easy to design.

This way, you don't have to go through the effort of creating your own=20
construct, with its own rules. You don't have to go into compilers and=20
investigate how they structure this stuff, so you can figure out what the=
=20
limitations should be. You can just say, "hey, let's make constexpr=20
functions start poking at their caller's scope!"

That's not a good reason to fundamentally change the nature of how things=
=20
work in C++.

If you want to invent a construct that allows the execution of statements=
=20
that modify its enclosing scope, great. But that concept *should not look=
=20
like a function*. Just like a class does not look like a function. Just=20
like a template instantiation does not look like a function. What you are=
=20
proposing is not conceptually a function, so it should not look like one=20
nor should it be defined like one.

And simply using a prefix in the call syntax or definition isn't good=20
enough.

On Sunday, May 24, 2015 at 2:33:04 PM UTC-4, P=C3=A9ter N=C3=A9meth wrote:
>
> 2015-05-24 17:55 GMT+02:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:=
=20
>
>> Not only that, you're violating the whole notion of being able to call=
=20
>> `constexpr` functions at runtime. What happens when I call this function=
=20
>> with a runtime "ast_class" or whatever?
>>
> You can use it runtime. The rule is that emit block is just a no-op in=20
> runtime.
>

That sounds decidedly error-prone to me, and it is yet another piece of=20
evidence that this *shouldn't* be done via `constexpr`. Why?

Because if it were properly its own construct, you *wouldn't be able* to=20
call it at runtime. The syntax simply wouldn't allow for it, anymore than=
=20
template instantiation or macros could be called at runtime. No user would=
=20
be confused by the fact that his code looks like it ought to work at=20
runtime but doesn't. Instead, they'd get a compile error, or better yet the=
=20
idea of doing it at runtime wouldn't even be possible.

If you have to start making arbitrary rules like "well, this function works=
=20
one way at compile-time but another at runtime", then you're making a *lang=
uage=20
hack*, not a proper feature.

C++ has enough hacks in it as is; we don't need more.


>> Or you can just do it up through template metaprogramming. And if there'=
s=20
>> a problem with understanding that, then maybe there should be some targe=
ted=20
>> syntax/library improvements applied there to smooth the user process out=
=20
>> (say, Boost.Fusion).
>>
> You can't create code with TMP.
>

Maybe *you* can't ;)

With `tuples`, you have all of the effects of being able to generate new=20
object types on the fly. To be sure, such objects are rather unnatural to=
=20
use, as are the generation methods for them. But again, if you smooth those=
=20
edges out, then you have a functional system that works.=20

No need to hijack function calling or anything.

Not only that, but such systems would be useful for far more than just=20
that. Who hasn't wanted a more reasonable way to iterate through the=20
sequence of a template parameter pack than doing recursion? That would be=
=20
useful by more people than this.

--=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_1050_17893822.1432495421955
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">OK, you seem to have missed my point, so let me start over=
..<br><br>A function is not an arbitrary construct of commands. It is a spec=
ific concept that has certain, very specific limitations on what it can do.=
 Functions can change values, adjust memory, call other functions, loop, th=
row exceptions, return values, and so forth. This is without regard to <i>w=
hen</i> that function executes.<br><br>At the same time, functions are spec=
ifically not empowered with certain other things. A function cannot modify =
the scope of its caller. Because of this, you can look at a function in iso=
lation and know what you're getting; it's all right there in the function b=
ody. You can see every definition, every statement, everything that happens=
 within a function, right there in the text. Calling other functions doesn'=
t change the nature of the caller; a function is defined by its own source =
code and nobody else's.<br><br>What you are suggesting is to allow function=
s to modify their caller's scope. Why? I'm not asking why you want to have =
a named sequence of steps that modifies enclosing scopes. I'm asking why yo=
u want a <i>function</i> to be able to do this.<br><br>The only reason I ca=
n see for why you want to hijack constexpr functions for this is because...=
 well, they're there. Compilers must already have some way of calling them =
at compile-time. So you're not suggesting this features because it's the be=
st way (or even a good way) for people to use the feature. It's simply beca=
use it's easy to design.<br><br>This way, you don't have to go through the =
effort of creating your own construct, with its own rules. You don't have t=
o go into compilers and investigate how they structure this stuff, so you c=
an figure out what the limitations should be. You can just say, "hey, let's=
 make constexpr functions start poking at their caller's scope!"<br><br>Tha=
t's not a good reason to fundamentally change the nature of how things work=
 in C++.<br><br>If you want to invent a construct that allows the execution=
 of statements that modify its enclosing scope, great. But that concept <i>=
should not look like a function</i>. Just like a class does not look like a=
 function. Just like a template instantiation does not look like a function=
.. What you are proposing is not conceptually a function, so it should not l=
ook like one nor should it be defined like one.<br><br>And simply using a p=
refix in the call syntax or definition isn't good enough.<br><br>On Sunday,=
 May 24, 2015 at 2:33:04 PM UTC-4, P=C3=A9ter N=C3=A9meth wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote">2015-05-24 17:55 GMT+02:00 Nicol Bolas <span dir=3D"ltr">&lt;<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"JPOPXwfqhu4J" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onc=
lick=3D"this.href=3D'javascript:';return true;">jmck...@gmail.com</a>&gt;</=
span>: <br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div>Not only that, you're violating the whole notion of being able to c=
all `constexpr` functions at runtime. What happens when I call this functio=
n with a runtime "ast_class" or whatever?<br></div></div></blockquote><div>=
You can use it runtime. The rule is that emit block is just a no-op in runt=
ime.</div></div></div></div></blockquote><div><br>That sounds decidedly err=
or-prone to me, and it is yet another piece of evidence that this <i>should=
n't</i> be done via `constexpr`. Why?<br><br>Because if it were properly it=
s own construct, you <i>wouldn't be able</i> to call it at runtime. The syn=
tax simply wouldn't allow for it, anymore than template instantiation or ma=
cros could be called at runtime. No user would be confused by the fact that=
 his code looks like it ought to work at runtime but doesn't. Instead, they=
'd get a compile error, or better yet the idea of doing it at runtime would=
n't even be possible.<br><br>If you have to start making arbitrary rules li=
ke "well, this function works one way at compile-time but another at runtim=
e", then you're making a <i>language hack</i>, not a proper feature.<br><br=
>C++ has enough hacks in it as is; we don't need more.<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><br>Or you can just do it up through template metaprogramming. And if t=
here's a problem with understanding that, then maybe there should be some t=
argeted syntax/library improvements applied there to smooth the user proces=
s out (say, Boost.Fusion).<br></div></blockquote></div></div>You can't crea=
te code with TMP.<br></div></blockquote><div><br>Maybe <i>you</i> can't ;)<=
br><br>With `tuples`, you have all of the effects of being able to generate=
 new object types on the fly. To be sure, such objects are rather unnatural=
 to use, as are the generation methods for them. But again, if you smooth t=
hose edges out, then you have a functional system that works. <br><br>No ne=
ed to hijack function calling or anything.<br><br>Not only that, but such s=
ystems would be useful for far more than just=20
that. Who hasn't wanted a more reasonable way to iterate through the=20
sequence of a template parameter pack than doing recursion? That would be u=
seful by more people than this.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1050_17893822.1432495421955--
------=_Part_1049_1212568436.1432495421955--

.

--047d7b6d9086338cfd0516d9e4f4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-05-24 21:23 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:

> OK, you seem to have missed my point, so let me start over.
>
> A function is not an arbitrary construct of commands. It is a specific
> concept that has certain, very specific limitations on what it can do.
> Functions can change values, adjust memory, call other functions, loop,
> throw exceptions, return values, and so forth. This is without regard to
> *when* that function executes.
>
> At the same time, functions are specifically not empowered with certain
> other things. A function cannot modify the scope of its caller. Because o=
f
> this, you can look at a function in isolation and know what you're gettin=
g;
> it's all right there in the function body. You can see every definition,
> every statement, everything that happens within a function, right there i=
n
> the text. Calling other functions doesn't change the nature of the caller=
;
> a function is defined by its own source code and nobody else's.
>
> What you are suggesting is to allow functions to modify their caller's
> scope. Why? I'm not asking why you want to have a named sequence of steps
> that modifies enclosing scopes. I'm asking why you want a *function* to
> be able to do this.
>
This new kind of constexpr function can emit code in an emit block. And not
the function will modify the caller's scope but the #! invocation. So that
function can emit code to a marked place. That marked place will generate
the code.

#!generateSomething();
^^
  This generate the code. generateSomething() just emits code.

// without #!
generateSomething(); // just a normal function call




>
>
> The only reason I can see for why you want to hijack constexpr functions
> for this is because... well, they're there. Compilers must already have
> some way of calling them at compile-time. So you're not suggesting this
> features because it's the best way (or even a good way) for people to use
> the feature. It's simply because it's easy to design.
>
Well, what I planned earlier is a compile time repeater.... with a
filtering so I added the if part.. and I want to name such a thing.. so
added define and call... and I eneded up with a resyntaxed C++. Looks like
a dead end for me. But a constexpr is just a compile time interpreted C++
exactly what I want.

Here is my earlier plan:
[...]
III. Statement and declaration repeater

For a usable code generation the constexpr-id is not enough. Repeating a
templated-code is necessary.

My proposed syntax is:
  #<for> (item : items())
     declarations or
     statements
  #</for>

IV. Generalize the statement and declaration manipulation

If we allow for we should allow other control structures as well. Intended
use case is replacing the textual pre-processor.

My proposed syntax is:

1. if..else
  #<if> (member.size() =3D=3D 0)
    char dummy[4];
  #<else>
    #<if> (...)
    #</if>
  #</if>

2. switch.. case
  #<switch> (typeid<int>.size_in_bits())
    #<case> (4)
      int32();
    #</case>
    #<case> (8)
      int64();
    #</case>
    #<case> (16)
      int128();
    #</case>
    #<default>
      static_assert(false, "Not supported int size");
    #</default>
  #</switch>

3. define meta function

#<define> copyClassMembers(const std::ast::ast_class& srcClass)
  #<for> (member : srcClass.members())
    ''member.type()'' ''member.name()'';
  #</for>
  #<if> (members.empty())
     char padding[8];
  #</if>
#</define>

4. call meta function

#<call>copyClassMembers(typeid<TestClass>)#</call>

5. try lookup a symbol

#<lookup>symbolname#</lookup>
if symbolname is exist then the result is true otherwise false.

constexpr bool alloca_exist =3D #<lookup>void* alloca(size_t)#</lookup>;
#<if> (!alloca_exist)
void* alloca(size_t size)
{
  return 0;
}
#</if>


So I don't think we should invent new controlling syntaxes for compile time
for, if, while, function call, class creation whatever...


>
> This way, you don't have to go through the effort of creating your own
> construct, with its own rules. You don't have to go into compilers and
> investigate how they structure this stuff, so you can figure out what the
> limitations should be. You can just say, "hey, let's make constexpr
> functions start poking at their caller's scope!"
>
I started my implementation in clang. The fork is here:
https://github.com/hun-nemethpeter/clang/tree/typid_ast

This example is compiling in it:
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr=
-ast/test.cpp


What I really want, a repeater is just really a compile time for cycle. And
I prefer not reinvent every control struct with a new syntax.



>
> That's not a good reason to fundamentally change the nature of how things
> work in C++.
>
The main reason is a full compile time reflection with code generation
capability.


>
> If you want to invent a construct that allows the execution of statements
> that modify its enclosing scope, great. But that concept *should not look
> like a function*. Just like a class does not look like a function. Just
> like a template instantiation does not look like a function. What you are
> proposing is not conceptually a function, so it should not look like one
> nor should it be defined like one.
>
I think #!generateSomthing(); is quite different from
ordinaryFunctionCall();



>
> And simply using a prefix in the call syntax or definition isn't good
> enough.
>
Well, I originally wrote something like:
#<call>generateSomething()#</call>

but it is just too long so I just shortened it.


>
> On Sunday, May 24, 2015 at 2:33:04 PM UTC-4, P=C3=A9ter N=C3=A9meth wrote=
:
>>
>> 2015-05-24 17:55 GMT+02:00 Nicol Bolas <jmck...@gmail.com>:
>>
>>> Not only that, you're violating the whole notion of being able to call
>>> `constexpr` functions at runtime. What happens when I call this functio=
n
>>> with a runtime "ast_class" or whatever?
>>>
>> You can use it runtime. The rule is that emit block is just a no-op in
>> runtime.
>>
>
> That sounds decidedly error-prone to me, and it is yet another piece of
> evidence that this *shouldn't* be done via `constexpr`. Why?
>
> Because if it were properly its own construct, you *wouldn't be able* to
> call it at runtime. The syntax simply wouldn't allow for it, anymore than
> template instantiation or macros could be called at runtime. No user woul=
d
> be confused by the fact that his code looks like it ought to work at
> runtime but doesn't. Instead, they'd get a compile error, or better yet t=
he
> idea of doing it at runtime wouldn't even be possible.
>
Well. I think it would be too restrictive to prohibit to call it in
runtime. But.. I accept that it can be confusing. With the constexpr!
syntax you can achive that feature.



>
> If you have to start making arbitrary rules like "well, this function
> works one way at compile-time but another at runtime", then you're making=
 a *language
> hack*, not a proper feature.
>
Ok. One more reason to using the  constexpr! syntax.


>
> C++ has enough hacks in it as is; we don't need more.
>
Designing a new big feature in C++ is quite long process and there are so
many path. I think noody wants hacks.


>
>
>>> Or you can just do it up through template metaprogramming. And if
>>> there's a problem with understanding that, then maybe there should be s=
ome
>>> targeted syntax/library improvements applied there to smooth the user
>>> process out (say, Boost.Fusion).
>>>
>> You can't create code with TMP.
>>
>
> Maybe *you* can't ;)
>
> With `tuples`, you have all of the effects of being able to generate new
> object types on the fly. To be sure, such objects are rather unnatural to
> use, as are the generation methods for them. But again, if you smooth tho=
se
> edges out, then you have a functional system that works.
>
I think "unnatural to use" =3D=3D hack

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

--047d7b6d9086338cfd0516d9e4f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2015-05-24 21:23 GMT+02:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">OK, you seem to have missed my point, so let me start over.<br><br>A fun=
ction is not an arbitrary construct of commands. It is a specific concept t=
hat has certain, very specific limitations on what it can do. Functions can=
 change values, adjust memory, call other functions, loop, throw exceptions=
, return values, and so forth. This is without regard to <i>when</i> that f=
unction executes.<br><br>At the same time, functions are specifically not e=
mpowered with certain other things. A function cannot modify the scope of i=
ts caller. Because of this, you can look at a function in isolation and kno=
w what you&#39;re getting; it&#39;s all right there in the function body. Y=
ou can see every definition, every statement, everything that happens withi=
n a function, right there in the text. Calling other functions doesn&#39;t =
change the nature of the caller; a function is defined by its own source co=
de and nobody else&#39;s.<br><br>What you are suggesting is to allow functi=
ons to modify their caller&#39;s scope. Why? I&#39;m not asking why you wan=
t to have a named sequence of steps that modifies enclosing scopes. I&#39;m=
 asking why you want a <i>function</i> to be able to do this.<br></div></bl=
ockquote><div>This new kind of constexpr function can emit code in an emit =
block. And not the function will modify the caller&#39;s scope but the #! i=
nvocation. So that function can emit code to a marked place. That marked pl=
ace will generate the code.<br><br></div><div><span style=3D"font-family:mo=
nospace,monospace">#!generateSomething();<br></span></div><div><span style=
=3D"font-family:monospace,monospace">^^<br></span></div><div><span style=3D=
"font-family:monospace,monospace">=C2=A0 This generate the code. </span><sp=
an style=3D"font-family:monospace,monospace">generateSomething() just emits=
 code.<br></span></div><div><br></div><div><span style=3D"font-family:monos=
pace,monospace">// without #!<br></span></div><div><span style=3D"font-fami=
ly:monospace,monospace">generateSomething(); // just a normal function call=
<br></span><br></div><div><br></div><div><br></div>=C2=A0<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br>The only reason I can=
 see for why you want to hijack constexpr functions for this is because... =
well, they&#39;re there. Compilers must already have some way of calling th=
em at compile-time. So you&#39;re not suggesting this features because it&#=
39;s the best way (or even a good way) for people to use the feature. It&#3=
9;s simply because it&#39;s easy to design.<br></div></blockquote><div>Well=
, what I planned earlier is a compile time repeater.... with a filtering so=
 I added the if part.. and I want to name such a thing.. so added define an=
d call... and I eneded up with a resyntaxed C++. Looks like a dead end for =
me. But a constexpr is just a compile time interpreted C++ exactly what I w=
ant.<br><br></div><div>Here is my earlier plan:<br></div><div>[...]<br><spa=
n style=3D"font-family:monospace,monospace">III. Statement and declaration =
repeater<br><br>For a usable code generation the constexpr-id is not enough=
.. Repeating a templated-code is necessary.<br><br>My proposed syntax is:<br=
>=C2=A0 #&lt;for&gt; (item : items())<br>=C2=A0=C2=A0=C2=A0=C2=A0 declarati=
ons or<br>=C2=A0=C2=A0=C2=A0=C2=A0 statements<br>=C2=A0 #&lt;/for&gt;<br><b=
r>IV. Generalize the statement and declaration manipulation<br><br>If we al=
low for we should allow other control structures as well. Intended use case=
 is replacing the textual pre-processor.<br><br>My proposed syntax is:<br><=
br>1. if..else<br>=C2=A0 #&lt;if&gt; (member.size() =3D=3D 0)<br>=C2=A0=C2=
=A0=C2=A0 char dummy[4];<br>=C2=A0 #&lt;else&gt;<br>=C2=A0=C2=A0=C2=A0 #&lt=
;if&gt; (...)<br>=C2=A0=C2=A0=C2=A0 #&lt;/if&gt;<br>=C2=A0 #&lt;/if&gt;<br>=
<br>2. switch.. case<br>=C2=A0 #&lt;switch&gt; (typeid&lt;int&gt;.size_in_b=
its())<br>=C2=A0=C2=A0=C2=A0 #&lt;case&gt; (4)<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 int32();<br>=C2=A0=C2=A0=C2=A0 #&lt;/case&gt;<br>=C2=A0=C2=A0=C2=A0 =
#&lt;case&gt; (8)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int64();<br>=C2=A0=C2=
=A0=C2=A0 #&lt;/case&gt;<br>=C2=A0=C2=A0=C2=A0 #&lt;case&gt; (16)<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 int128();<br>=C2=A0=C2=A0=C2=A0 #&lt;/case&gt;<br>=
=C2=A0=C2=A0=C2=A0 #&lt;default&gt;<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 stati=
c_assert(false, &quot;Not supported int size&quot;);<br>=C2=A0=C2=A0=C2=A0 =
#&lt;/default&gt;<br>=C2=A0 #&lt;/switch&gt;<br><br>3. define meta function=
<br><br>#&lt;define&gt; copyClassMembers(const std::ast::ast_class&amp; src=
Class)<br>=C2=A0 #&lt;for&gt; (member : srcClass.members())<br>=C2=A0=C2=A0=
=C2=A0 &#39;&#39;member.type()&#39;&#39; &#39;&#39;<a href=3D"http://member=
..name">member.name</a>()&#39;&#39;;<br>=C2=A0 #&lt;/for&gt;<br>=C2=A0 #&lt;=
if&gt; (members.empty())<br>=C2=A0=C2=A0=C2=A0=C2=A0 char padding[8];<br>=
=C2=A0 #&lt;/if&gt;<br>#&lt;/define&gt;<br><br>4. call meta function<br><br=
>#&lt;call&gt;copyClassMembers(typeid&lt;TestClass&gt;)#&lt;/call&gt;<br><b=
r>5. try lookup a symbol<br><br>#&lt;lookup&gt;symbolname#&lt;/lookup&gt;<b=
r>if symbolname is exist then the result is true otherwise false.<br><br>co=
nstexpr bool alloca_exist =3D #&lt;lookup&gt;void* alloca(size_t)#&lt;/look=
up&gt;;<br>#&lt;if&gt; (!alloca_exist)<br>void* alloca(size_t size)<br>{<br=
>=C2=A0 return 0;<br>}<br>#&lt;/if&gt;<br></span><br><br></div><div>So I do=
n&#39;t think we should invent new controlling syntaxes for compile time fo=
r, if, while, function call, class creation whatever...<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><br>This way, you don&#39;t have to go through the effort of creating your=
 own construct, with its own rules. You don&#39;t have to go into compilers=
 and investigate how they structure this stuff, so you can figure out what =
the limitations should be. You can just say, &quot;hey, let&#39;s make cons=
texpr functions start poking at their caller&#39;s scope!&quot;<br></div></=
blockquote><div>I started my implementation in clang. The fork is here:<br>=
<a href=3D"https://github.com/hun-nemethpeter/clang/tree/typid_ast">https:/=
/github.com/hun-nemethpeter/clang/tree/typid_ast</a><br><br></div><div>This=
 example is compiling in it:<br><a href=3D"https://github.com/hun-nemethpet=
er/cpp-reflector-mini/blob/master/constexpr-ast/test.cpp">https://github.co=
m/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/test.cpp</a>=
<br></div><div><br><br></div><div>What I really want, a repeater is just re=
ally a compile time for cycle. And I prefer not reinvent every control stru=
ct with a new syntax.<br><br></div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><br>That&#39;s not a good reaso=
n to fundamentally change the nature of how things work in C++.<br></div></=
blockquote><div>The main reason is a full compile time reflection with code=
 generation capability.<br></div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><br>If you want to invent a const=
ruct that allows the execution of statements that modify its enclosing scop=
e, great. But that concept <i>should not look like a function</i>. Just lik=
e a class does not look like a function. Just like a template instantiation=
 does not look like a function. What you are proposing is not conceptually =
a function, so it should not look like one nor should it be defined like on=
e.<br></div></blockquote><div>I think #!generateSomthing(); is quite differ=
ent from ordinaryFunctionCall();<br></div><div><br>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br>And simply using=
 a prefix in the call syntax or definition isn&#39;t good enough.<br></div>=
</blockquote><div>Well, I originally wrote something like:<br></div><div><s=
pan style=3D"font-family:monospace,monospace">#&lt;call&gt;generateSomethin=
g()#&lt;/call&gt;<br></span><br></div><div>but it is just too long so I jus=
t shortened it.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><br>On Sunday, May 24, 2015 at 2:33:04 PM=
 UTC-4, P=C3=A9ter N=C3=A9meth wrote:<span class=3D""><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e">2015-05-24 17:55 GMT+02:00 Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"n=
ofollow">jmck...@gmail.com</a>&gt;</span>: <br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div>Not only that, you&#39;re viola=
ting the whole notion of being able to call `constexpr` functions at runtim=
e. What happens when I call this function with a runtime &quot;ast_class&qu=
ot; or whatever?<br></div></div></blockquote><div>You can use it runtime. T=
he rule is that emit block is just a no-op in runtime.</div></div></div></d=
iv></blockquote></span><div><br>That sounds decidedly error-prone to me, an=
d it is yet another piece of evidence that this <i>shouldn&#39;t</i> be don=
e via `constexpr`. Why?<br><br>Because if it were properly its own construc=
t, you <i>wouldn&#39;t be able</i> to call it at runtime. The syntax simply=
 wouldn&#39;t allow for it, anymore than template instantiation or macros c=
ould be called at runtime. No user would be confused by the fact that his c=
ode looks like it ought to work at runtime but doesn&#39;t. Instead, they&#=
39;d get a compile error, or better yet the idea of doing it at runtime wou=
ldn&#39;t even be possible.<br></div></div></blockquote><div>Well. I think =
it would be too restrictive to prohibit to call it in runtime. But.. I acce=
pt that it can be confusing. With the <span style=3D"font-family:monospace,=
monospace">constexpr!</span> syntax you can achive that feature.<br></div><=
div><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div><br>If you have to start making arbitrary rules like &quot=
;well, this function works one way at compile-time but another at runtime&q=
uot;, then you&#39;re making a <i>language hack</i>, not a proper feature.<=
br></div></div></blockquote><div>Ok. One more reason to using the=C2=A0 <sp=
an style=3D"font-family:monospace,monospace">constexpr!</span> syntax.<br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div><br>C++ has enough hacks in it as is; we don&#39;t need =
more.<br></div></div></blockquote><div>Designing a new big feature in C++ i=
s quite long process and there are so many path. I think noody wants hacks.=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div><br></div><span class=3D""><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br>Or y=
ou can just do it up through template metaprogramming. And if there&#39;s a=
 problem with understanding that, then maybe there should be some targeted =
syntax/library improvements applied there to smooth the user process out (s=
ay, Boost.Fusion).<br></div></blockquote></div></div>You can&#39;t create c=
ode with TMP.<br></div></blockquote></span><div><br>Maybe <i>you</i> can&#3=
9;t ;)<br><br>With `tuples`, you have all of the effects of being able to g=
enerate new object types on the fly. To be sure, such objects are rather un=
natural to use, as are the generation methods for them. But again, if you s=
mooth those edges out, then you have a functional system that works. <br></=
div></div></blockquote><div>I think &quot;unnatural to use&quot; =3D=3D hac=
k<br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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 />

--047d7b6d9086338cfd0516d9e4f4--

.

------=_Part_303_515523341.1432502911358
Content-Type: multipart/alternative;
 boundary="----=_Part_304_1451760189.1432502911358"

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

On Sunday, May 24, 2015 at 4:39:37 PM UTC-4, P=C3=A9ter N=C3=A9meth wrote:
>
> 2015-05-24 21:23 GMT+02:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>> The only reason I can see for why you want to hijack constexpr functions=
=20
>> for this is because... well, they're there. Compilers must already have=
=20
>> some way of calling them at compile-time. So you're not suggesting this=
=20
>> features because it's the best way (or even a good way) for people to us=
e=20
>> the feature. It's simply because it's easy to design.
>>
> Well, what I planned earlier is a compile time repeater.... with a=20
> filtering so I added the if part.. and I want to name such a thing.. so=
=20
> added define and call... and I eneded up with a resyntaxed C++. Looks lik=
e=20
> a dead end for me.
>

Why is that a dead end? It seems to me that this is the better way to go.
=20

> But a constexpr is just a compile time interpreted C++ exactly what I wan=
t.
>

But it's not "exactly what I want", as evidenced by the fact that you have=
=20
to change constexpr to get what you want. You add new definition and call=
=20
syntax specifically to separate "what you want" from "what normally=20
happens".

So you're admitting that you're piggybacking off of the syntax because it's=
=20
there, not because it's the right syntax for the problem.

If, as an implementation detail, you want to implement it using the same=20
compile-time interpretation system that the compiler uses for `constexpr`,=
=20
be my guest. But to the user, the feature should in no way look like a=20
function definition or a function call.

You could make it look like this:

InducerKeyword MetaFunctionName[MetaArgumentList]
{
  ...
}

Feel free to pick different names for these as you feel the need to. When=
=20
you call it, you use []. It would not be a function and thus not behave at=
=20
all like a function. You couldn't get a function pointer to it or pass it=
=20
around or anything. It could only take as parameters the results of certain=
=20
compile-time constructs (compile-time reflection commands) or typenames.

Not only that, but by defining it as something other than a function, you=
=20
can have entirely new contextual keywords used inside of it. The form of=20
C++ that happens within can be completely up to you. And therefore,=20
tortured syntax like "#<>" need not be used.

I don't care if your particular implementation of this internally=20
transforms that into the same compile-time interpretation system use by=20
`constexpr` functions. But it would not actually be reminiscent of a=20
`constexpr` function to the language itself and therefore not to the user.

So I don't think we should invent new controlling syntaxes for compile time=
=20
> for, if, while, function call, class creation whatever...
>

Why not? It's a completely new construct to C++, so it makes sense that it=
=20
ought to have a new, different syntax, distinct from the syntax for other=
=20
things.

Templates have a completely different syntax from non-template stuff in C++=
=20
too. They have their own parameter list, with their own parameter grouping=
=20
syntax, and so forth. As well it should. The nice thing about templates is=
=20
that, if you see angle brackets, you know you're dealing with some form of=
=20
template. And if you don't see angle brackets, you know that you're not=20
dealing with templates.

At least, until that ridiculous syntax from concepts gets accepted into=20
C++...


>> That's not a good reason to fundamentally change the nature of how thing=
s=20
>> work in C++.
>>
> The main reason is a full compile time reflection with code generation=20
> capability.
>

Which doesn't require fundamentally changing the nature of functions. The=
=20
goal does not justify the method you use to achieve it.
=20

>
>> If you have to start making arbitrary rules like "well, this function=20
>> works one way at compile-time but another at runtime", then you're makin=
g a *language=20
>> hack*, not a proper feature.
>>
> Ok. One more reason to using the  constexpr! syntax.
>

Right. Because using arbitrary punctuation to make a keyword mean something=
=20
fundamentally different from its normal meaning totally doesn't look like a=
=20
language hack...

--=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_304_1451760189.1432502911358
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, May 24, 2015 at 4:39:37 PM UTC-4, P=C3=A9ter N=
=C3=A9meth wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">2015-05-24 21:23 GMT+02:00 Nicol Bolas =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"l5ipdIVA3p8J" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>jmck...@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr">The only reason I can see for why you want to=
 hijack constexpr functions for this is because... well, they're there. Com=
pilers must already have some way of calling them at compile-time. So you'r=
e not suggesting this features because it's the best way (or even a good wa=
y) for people to use the feature. It's simply because it's easy to design.<=
br></div></blockquote><div>Well, what I planned earlier is a compile time r=
epeater.... with a filtering so I added the if part.. and I want to name su=
ch a thing.. so added define and call... and I eneded up with a resyntaxed =
C++. Looks like a dead end for me.</div></div></div></div></blockquote><div=
><br>Why is that a dead end? It seems to me that this is the better way to =
go.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><div>But a constexpr is just a compil=
e time interpreted C++ exactly what I want.<br></div></div></div></div></bl=
ockquote><div class=3D"gmail_quote"><br>But it's not "exactly what I want",=
 as evidenced by the fact that you have to change constexpr to get what you=
 want. You add new definition and call syntax specifically to separate "wha=
t you want" from "what normally happens".<br><br>So you're admitting that y=
ou're piggybacking off of the syntax because it's there, not because it's t=
he right syntax for the problem.<br><br>If, as an implementation detail, yo=
u want to implement it using the same compile-time interpretation system th=
at the compiler uses for `constexpr`, be my guest. But to the user, the fea=
ture should in no way look like a function definition or a function call.<b=
r><br>You could make it look like this:<br><br>InducerKeyword MetaFunctionN=
ame[MetaArgumentList]<br>{<br>&nbsp; ...<br>}<br><br>Feel free to pick diff=
erent names for these as you feel the need to. When you call it, you use []=
.. It would not be a function and thus not behave at all like a function. Yo=
u couldn't get a function pointer to it or pass it around or anything. It c=
ould only take as parameters the results of certain compile-time constructs=
 (compile-time reflection commands) or typenames.<br><br>Not only that, but=
 by defining it as something other than a function, you can have entirely n=
ew contextual keywords used inside of it. The form of C++ that happens with=
in can be completely up to you. And therefore, tortured syntax like "#&lt;&=
gt;" need not be used.<br><br>I don't care if your particular implementatio=
n of this internally transforms that into the same compile-time interpretat=
ion system use by `constexpr` functions. But it would not actually be remin=
iscent of a `constexpr` function to the language itself and therefore not t=
o the user.<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-l=
eft: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote=
"><div>So I don't think we should invent new controlling syntaxes for compi=
le time for, if, while, function call, class creation whatever...<br></div>=
</blockquote></div><div><br>Why not? It's a completely new construct to C++=
, so it makes sense that it ought to have a new, different syntax, distinct=
 from the syntax for other things.<br><br>Templates have a completely diffe=
rent syntax from non-template stuff in C++ too. They have their own paramet=
er list, with their own parameter grouping syntax, and so forth. As well it=
 should. The nice thing about templates is that, if you see angle brackets,=
 you know you're dealing with some form of template. And if you don't see a=
ngle brackets, you know that you're not dealing with templates.<br><br>At l=
east, until that ridiculous syntax from concepts gets accepted into C++...<=
br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr"><br>That's not a good reason to fundamen=
tally change the nature of how things work in C++.<br></div></blockquote><d=
iv>The main reason is a full compile time reflection with code generation c=
apability.<br></div></div></div></div></blockquote><div><br>Which doesn't r=
equire fundamentally changing the nature of functions. The goal does not ju=
stify the method you use to achieve it.<br>&nbsp;</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br>=
If you have to start making arbitrary rules like "well, this function works=
 one way at compile-time but another at runtime", then you're making a <i>l=
anguage hack</i>, not a proper feature.<br></div></div></blockquote><div>Ok=
.. One more reason to using the&nbsp; <span style=3D"font-family:monospace,m=
onospace">constexpr!</span> syntax.<br></div></div></div></div></blockquote=
><div><br>Right. Because using arbitrary punctuation to make a keyword mean=
 something fundamentally different from its normal meaning totally doesn't =
look like a language hack...</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_304_1451760189.1432502911358--
------=_Part_303_515523341.1432502911358--

.

--047d7b15a4898a7def0516e5dcff
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-05-24 23:28 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:

> On Sunday, May 24, 2015 at 4:39:37 PM UTC-4, P=C3=A9ter N=C3=A9meth wrote=
:
>>
>> 2015-05-24 21:23 GMT+02:00 Nicol Bolas <jmck...@gmail.com>:
>>
>>> The only reason I can see for why you want to hijack constexpr function=
s
>>> for this is because... well, they're there. Compilers must already have
>>> some way of calling them at compile-time. So you're not suggesting this
>>> features because it's the best way (or even a good way) for people to u=
se
>>> the feature. It's simply because it's easy to design.
>>>
>> Well, what I planned earlier is a compile time repeater.... with a
>> filtering so I added the if part.. and I want to name such a thing.. so
>> added define and call... and I eneded up with a resyntaxed C++. Looks li=
ke
>> a dead end for me.
>>
>
> Why is that a dead end? It seems to me that this is the better way to go.
>
The emit block base soulution is so much simpler and cleaner to me. It just
introduce one type of new block vs. resyntax every controlling structure.



>
>
>> But a constexpr is just a compile time interpreted C++ exactly what I
>> want.
>>
>
> But it's not "exactly what I want", as evidenced by the fact that you hav=
e
> to change constexpr to get what you want. You add new definition and call
> syntax specifically to separate "what you want" from "what normally
> happens".
>
Well. I am extending it not changing it. Extending one type of new block
and extending one type of new calling place. I need everything from a
constexpr.


>
> So you're admitting that you're piggybacking off of the syntax because
> it's there, not because it's the right syntax for the problem.
>
My intention is to use normal C++ syntax for manipulating/repeating
declaration/statement. In this approach the manipulated declaration or
statement got a new type of block. As the constexpr is running in compile
time it can emit these manipulated statements/expressions to a special
marked caller place. So this is the right syntax for me.


>
> If, as an implementation detail, you want to implement it using the same
> compile-time interpretation system that the compiler uses for `constexpr`=
,
> be my guest. But to the user, the feature should in no way look like a
> function definition or a function call.
>
> You could make it look like this:
>
> InducerKeyword MetaFunctionName[MetaArgumentList]
> {
>   ...
> }
>

Feel free to pick different names for these as you feel the need to. When
> you call it, you use []. It would not be a function and thus not behave a=
t
> all like a function. You couldn't get a function pointer to it or pass it
> around or anything. It could only take as parameters the results of certa=
in
> compile-time constructs (compile-time reflection commands) or typenames.
>
> Not only that, but by defining it as something other than a function, you
> can have entirely new contextual keywords used inside of it. The form of
> C++ that happens within can be completely up to you. And therefore,
> tortured syntax like "#<>" need not be used.
>
> I don't care if your particular implementation of this internally
> transforms that into the same compile-time interpretation system use by
> `constexpr` functions. But it would not actually be reminiscent of a
> `constexpr` function to the language itself and therefore not to the user=
..
>
> It's not everything clear to me
What is clear to me:
- you want really special syntax for declaration manipulation (constexpr!
is not enough for you)
- you don't like the extended constexpr syntax

What is not clear:
- where is the manipulated context here? So how can i create 16 int
variable with name int byte01, byte02.. byte16?
- how can I manipulate an id without "#<>"?
- why MetaFunctionName[MetaArgumentList] is better then
#!MetaFunctionName(MetaArgumentList)?
- How can use it as an OOP method or template?

As I understand you want something like this:

macro void generateVariables[const ast_class& myClass] {
  for (const auto& member : myClass.members()) {
    emit to class [] (const auto& member) {
      int newid[member.name()];
    }
  }
}
The advantage of this approach that I can create new keyword to here.

But the constexpr can be a class and template also so how how can use
this syntax for a macro object?

class MacroClass
{
   macro MacroClass[] { ... }
   macro void macroMethod[] { ... }
};

or
macro class MacroClass
{
  MacroClass[] {}
  Obj& operator[] (int index) {} // ???
};

And how can I template this mateThing?

template<typename T>
class MacroClass : public MacroBase
{
   macro MacroClass<T>[] {}
   macro void macroMethod[] { ... }
};

Or you want completly different syntax for creating a meta object or
that MetaFunctionName can be only just a function like thing?

// using as
template<typename T>
class Test {
 // why is this better than #!generateVariables(typename<T>); ?
  generateVariables[typename<T>];
};




> So I don't think we should invent new controlling syntaxes for compile
>> time for, if, while, function call, class creation whatever...
>>
>
> Why not? It's a completely new construct to C++, so it makes sense that i=
t
> ought to have a new, different syntax, distinct from the syntax for other
> things.
>
> Templates have a completely different syntax from non-template stuff in
> C++ too. They have their own parameter list, with their own parameter
> grouping syntax, and so forth. As well it should. The nice thing about
> templates is that, if you see angle brackets, you know you're dealing wit=
h
> some form of template. And if you don't see angle brackets, you know that
> you're not dealing with templates.
>
Well if you see #! you know that it will manipulate the callers context.
And that syntax is really syntax highlighting friendly.


If you have to start making arbitrary rules like "well, this function works
one way at compile-time but another at runtime", then you're making a *lang=
uage
hack*, not a proper feature.

> Ok. One more reason to using the  constexpr! syntax.
>>
>
> Right. Because using arbitrary punctuation to make a keyword mean
> something fundamentally different from its normal meaning totally doesn't
> look like a language hack...
>
Well with that ! sign the constexpr do only one thing extra, emit code
parts. So I don't feel that

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

--047d7b15a4898a7def0516e5dcff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2015-05-24 23:28 GMT+02:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">On Sunday, May 24, 2015 at 4:39:37 PM UTC-4, P=C3=A9ter N=C3=A9meth wrot=
e:<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote">2015-05-24 21:23 GMT+02:00 Nicol=
 Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">The only reason I can see for why you want to hijack constexpr functions=
 for this is because... well, they&#39;re there. Compilers must already hav=
e some way of calling them at compile-time. So you&#39;re not suggesting th=
is features because it&#39;s the best way (or even a good way) for people t=
o use the feature. It&#39;s simply because it&#39;s easy to design.<br></di=
v></blockquote><div>Well, what I planned earlier is a compile time repeater=
..... with a filtering so I added the if part.. and I want to name such a th=
ing.. so added define and call... and I eneded up with a resyntaxed C++. Lo=
oks like a dead end for me.</div></div></div></div></blockquote></span><div=
><br>Why is that a dead end? It seems to me that this is the better way to =
go.<br></div></div></blockquote><div>The emit block base soulution is so mu=
ch simpler and cleaner to me. It just introduce one type of new block vs. r=
esyntax every controlling structure.<br></div><div><br>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</div=
><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote"><div>But a constexpr is just a co=
mpile time interpreted C++ exactly what I want.<br></div></div></div></div>=
</blockquote></span><div class=3D"gmail_quote"><br>But it&#39;s not &quot;e=
xactly what I want&quot;, as evidenced by the fact that you have to change =
constexpr to get what you want. You add new definition and call syntax spec=
ifically to separate &quot;what you want&quot; from &quot;what normally hap=
pens&quot;.<br></div></div></blockquote><div>Well. I am extending it not ch=
anging it. Extending one type of new block and extending one type of new ca=
lling place. I need everything from a constexpr.<br></div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_quote"><br>So you&#39;re admitting that you&#39;re piggybacking=
 off of the syntax because it&#39;s there, not because it&#39;s the right s=
yntax for the problem.<br></div></div></blockquote><div>My intention is to =
use normal C++ syntax for manipulating/repeating declaration/statement. In =
this approach the manipulated declaration or statement got a new type of bl=
ock. As the constexpr is running in compile time it can emit these manipula=
ted statements/expressions to a special marked caller place. So this is the=
 right syntax for me.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><br>If, =
as an implementation detail, you want to implement it using the same compil=
e-time interpretation system that the compiler uses for `constexpr`, be my =
guest. But to the user, the feature should in no way look like a function d=
efinition or a function call.<br><br>You could make it look like this:<br><=
br>InducerKeyword MetaFunctionName[MetaArgumentList]<br>{<br>=C2=A0 ...<br>=
}<br></div></div></blockquote><br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote">Feel free to pick di=
fferent names for these as you feel the need to. When you call it, you use =
[]. It would not be a function and thus not behave at all like a function. =
You couldn&#39;t get a function pointer to it or pass it around or anything=
.. It could only take as parameters the results of certain compile-time cons=
tructs (compile-time reflection commands) or typenames.<br><br>Not only tha=
t, but by defining it as something other than a function, you can have enti=
rely new contextual keywords used inside of it. The form of C++ that happen=
s within can be completely up to you. And therefore, tortured syntax like &=
quot;#&lt;&gt;&quot; need not be used.<br><br>I don&#39;t care if your part=
icular implementation of this internally transforms that into the same comp=
ile-time interpretation system use by `constexpr` functions. But it would n=
ot actually be reminiscent of a `constexpr` function to the language itself=
 and therefore not to the user.<span class=3D""><br><br></span></div></div>=
</blockquote><div><div>It&#39;s not everything clear to me<br></div><div>Wh=
at is clear to me:<br></div><div>- you want really special syntax for decla=
ration manipulation (<span style=3D"font-family:monospace,monospace">conste=
xpr!</span> is not enough for you)<br></div><div>- you don&#39;t like the e=
xtended constexpr syntax<br></div><div><br></div><div>What is not clear:<br=
></div><div>- where is the manipulated context here? So how can i create 16=
 int variable with name int byte01, byte02.. byte16?<br></div><div>- how ca=
n I manipulate an id without &quot;#&lt;&gt;&quot;?<br></div><div>- why Met=
aFunctionName[MetaArgumentList] is better then #!MetaFunctionName(MetaArgum=
entList)?<br></div><div>- How can use it as an OOP method or template?<br><=
/div><br></div><div>As I understand you want something like this:<br></div>=
<div><pre><span>macro</span> <span>void</span> <span>generateVariables[</sp=
an><span>const</span> ast_class&amp; myClass] {
  <span>for</span> (<span>const</span> <span>auto</span>&amp; member : myCl=
ass.<span>members</span>()) {
    emit to class [] (<span>const</span> <span>auto</span>&amp; member) {
      <span>int</span> newid[member.<span>name</span>()];<br>   =C2=A0}
  }
}<br>The advantage of this approach that I can create new keyword to here.<=
br><br></pre><pre>But the constexpr can be a class and template also so how=
 how can use this syntax for a macro object?<br></pre><pre>class MacroClass=
<br>{<br>  =C2=A0macro MacroClass[] { ... }<br>  =C2=A0macro void macroMeth=
od[] { ... }<br>};<br><br></pre><pre>or<br>macro class MacroClass<br>{<br> =
=C2=A0MacroClass[] {}<br> =C2=A0Obj&amp; operator[] (int index) {} // ???<b=
r>};<br></pre><pre></pre><pre>And how can I template this mateThing?<br></p=
re><pre>template&lt;typename T&gt;<br>class MacroClass : public MacroBase<b=
r>{<br>   macro MacroClass&lt;T&gt;[] {}<br>   macro void macroMethod[] { .=
... }<br>};<br></pre><pre>Or you want completly different syntax for creatin=
g a meta object or that MetaFunctionName can be only just a function like t=
hing?</pre><pre></pre><pre>// using as<br>template&lt;typename T&gt;<br>cla=
ss Test {<br> // why is this better than #!generateVariables(typename&lt;T&=
gt;); ?<br>  generateVariables[typename&lt;T&gt;];<br>};<br><br><br></pre><=
span style=3D"font-family:monospace,monospace">=C2=A0</span>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><span class=3D""><blockquote style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmai=
l_quote"><div>So I don&#39;t think we should invent new controlling syntaxe=
s for compile time for, if, while, function call, class creation whatever..=
..<br></div></blockquote></span></div><div><br>Why not? It&#39;s a completel=
y new construct to C++, so it makes sense that it ought to have a new, diff=
erent syntax, distinct from the syntax for other things.<br><br>Templates h=
ave a completely different syntax from non-template stuff in C++ too. They =
have their own parameter list, with their own parameter grouping syntax, an=
d so forth. As well it should. The nice thing about templates is that, if y=
ou see angle brackets, you know you&#39;re dealing with some form of templa=
te. And if you don&#39;t see angle brackets, you know that you&#39;re not d=
ealing with templates.<br></div></div></blockquote><div>Well if you see #! =
you know that it will manipulate the callers context. And that syntax is re=
ally syntax highlighting friendly.<br></div><div>=C2=A0<br><br>If you have =
to start making arbitrary rules like &quot;well, this function works one wa=
y at compile-time but another at runtime&quot;, then you&#39;re making a <i=
>language hack</i>, not a proper feature.<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote"><div>Ok. One more reason to using the=C2=A0 <span style=3D"font-fa=
mily:monospace,monospace">constexpr!</span> syntax.<br></div></div></div></=
div></blockquote></span><div><br>Right. Because using arbitrary punctuation=
 to make a keyword mean something fundamentally different from its normal m=
eaning totally doesn&#39;t look like a language hack...</div></div></blockq=
uote></div>Well with that ! sign the constexpr do only one thing extra, emi=
t code parts. So I don&#39;t feel that <br><br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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 />
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 />

--047d7b15a4898a7def0516e5dcff--

.