------=_Part_31_327714113.1430842817600
Content-Type: multipart/alternative;
 boundary="----=_Part_32_1743026283.1430842817600"

------=_Part_32_1743026283.1430842817600
Content-Type: text/plain; charset=UTF-8

First of all, I couldn't find complete list on all SG7 WIP proposals. So
this could've been suggested. Though I didn't find exact match either.

Macro-blocks plus quasi quotations.

Why yet another?

 - template-based proposals are ugly, let's be honest (N4113 AFAIK)
 - syntax extensions propose adding counterpart to each control structure
(Like N3882 with its for <> loop)

A very brief example - modified from this one:
https://groups.google.com/a/isocpp.org/d/msg/reflection/B4KkTkQ02s8/qW55dmV6h7UJ

template<typename T>
class MirrorClass()
{
public:
  int foo;
  [[macro]]
  {
    for (auto const& member: T.fields())
      emit ${ $member.type() $member.name(); };
  }
};


1. [[macro]] here marks block as compile-time logic. Used for brevity,
subject to change.
2. Types, statements, expressions become variables. So you can perfectly
retrieve list of type's fields/methods/statics/supertypes etc.
3. 'emit' keyword - emits a piece of code into context. Acts more like
'yield', to be able to emit several chunks of code without composing them
into single variable. Though yield/return may be reused here.
4. ${} - quasi-quotation, denotes piece of code. $-prefixed identifiers
there are macro-variables from macro context. They're expanded into their
context upon emit. They can contain [[macro]] blocks themselves, creating
nested emit.

Another example:
template<typename... Args>
[[macro]] static_assert(constexpr_expr condition, Args&&... args) -> void
{
  if (condition.type != bool)
    error("static_assert condition must be a constexpr expression resolving
to boolean type");
  if (condition.result() != true)
    error(format("static_assert violated: ", std::forward<Args>(args)...));
}

Shows possible implementation of static_assert with variadic argument
support. Here 'condition's type shows that it accepts constexpr expression,
evaluable at compile time. Though it can be just expr's property
is_constexpr. Variadic arguments for such functions can be implemented not
only via variadic templates. Doesn't matter here.
'void' return type might either denote that this particular function
doesn't emit anything, or all macro functions might be void, as emitting
code differs logically from returning value.
'error' call produces compile error. 'format' is some kind of constexpr
formatter.

Pros:
+ Cleaner syntax, no template verbosity or fancy constructs
+ Semantics seem to be easier to understand - we work with AST as with
data, just in compile time and with certain limitations.

Cons:
- compile-time blocks look like ordinary code. Possible mix with other
pieces
- Need to support at least part of STL for compile-time mode. Or implement
types of their own for identifiers, collections of members and the like.

--

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

<div dir=3D"ltr">First of all, I couldn't find complete list on all SG7 WIP=
 proposals. So this could've been suggested. Though I didn't find exact mat=
ch either.<br><br>Macro-blocks plus quasi quotations.<br><br>Why yet anothe=
r?<br><br>&nbsp;- template-based proposals are ugly, let's be honest (N4113=
 AFAIK)<br>&nbsp;- syntax extensions propose adding counterpart to each con=
trol structure (Like N3882 with its for &lt;&gt; loop)<br><br>A very brief =
example - modified from this one: https://groups.google.com/a/isocpp.org/d/=
msg/reflection/B4KkTkQ02s8/qW55dmV6h7UJ<br><br><div class=3D"prettyprint" s=
tyle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 1=
87); border-style: solid; border-width: 1px; word-wrap: break-word;"><code =
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #=
008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">MirrorCla=
ss</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">public</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>&nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">[[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">mac=
ro</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]]</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">const</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> member</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">fields</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">())</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; emit $=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> $member</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">type</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> $member</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">name</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></code>=
</div><br>1. [[macro]] here marks block as compile-time logic. Used for bre=
vity, subject to change.<br>2. Types, statements, expressions become variab=
les. So you can perfectly retrieve list of type's fields/methods/statics/su=
pertypes etc.<br>3. 'emit' keyword - emits a piece of code into context. Ac=
ts more like 'yield', to be able to emit several chunks of code without com=
posing them into single variable. Though yield/return may be reused here.<b=
r>4. ${} - quasi-quotation, denotes piece of code. $-prefixed identifiers t=
here are macro-variables from macro context. They're expanded into their co=
ntext upon emit. They can contain [[macro]] blocks themselves, creating nes=
ted emit.<br><br>Another example:<br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">typename</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Args</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">macro</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">]]</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">static_assert</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">constexpr_expr condition</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Args</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&amp;&amp;...</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> args</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">condition</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">typ=
e </span><span style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">bool</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; error</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify">"static_assert condition must be =
a constexpr expression resolving to boolean type"</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">condition</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">resu=
lt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">!=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">true</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>&nbsp; &nbsp; error</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">format</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by=
-prettify">"static_assert violated: "</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">forward</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Args<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">args</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)...));</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span></div></code></div>Shows =
possible implementation of static_assert with variadic argument support. He=
re 'condition's type shows that it accepts constexpr expression, evaluable =
at compile time. Though it can be just expr's property is_constexpr. Variad=
ic arguments for such functions can be implemented not only via variadic te=
mplates. Doesn't matter here.<br>'void' return type might either denote tha=
t this particular function doesn't emit anything, or all macro functions mi=
ght be void, as emitting code differs logically from returning value.<br>'e=
rror' call produces compile error. 'format' is some kind of constexpr forma=
tter.<br><br>Pros:<br>+ Cleaner syntax, no template verbosity or fancy cons=
tructs<br>+ Semantics seem to be easier to understand - we work with AST as=
 with data, just in compile time and with certain limitations.<br><br>Cons:=
<br>- compile-time blocks look like ordinary code. Possible mix with other =
pieces<br>- Need to support at least part of STL for compile-time mode. Or =
implement types of their own for identifiers, collections of members and th=
e like.<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_32_1743026283.1430842817600--
------=_Part_31_327714113.1430842817600--

.

------=_Part_744_68500289.1430844949189
Content-Type: multipart/alternative;
 boundary="----=_Part_745_233122431.1430844949190"

------=_Part_745_233122431.1430844949190
Content-Type: text/plain; charset=UTF-8

Another example:
// decltype-like, but returns bool
[[macro]] expression_typed(expr expression) -> bool
{
  return !expr.result().type().empty();
}

template<
  typename T,
  // Do not instantiate if we have it
  typename = std::enable_if_t<!expression_typed( (declvalue<T>() ==
declvalue<T>()) == true )>
>
bool operator == (T const& left, T const& right) const
{
  [[macro]]
  {
    emit ${
      return true
      [[macro]] // using in expression context forces it to emit expressions
      {
        for (auto const& m: T.accessAll().fields())
          emit ${ && (left.$member == right.$member) };
      };
    }
  }
}

And another pros - many type-checking traits can be reimplemented with
macro blocks and no template magic. Much cleaner and simpler.

--

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

<div dir=3D"ltr">Another example:<br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">// decltype-like, but returns bool</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">macro</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">]]</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> expression_typed</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">expr expression</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">boo=
l</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">!</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">expr</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">result</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">().</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">type</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">empty</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>&nbsp; </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">// Do not instantiate if we have it</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">enable_if_t</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;!</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">expression_typed</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">declvalue</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&gt;()</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> declvalue</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;())</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">true</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">)&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">operator</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">T </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> left</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> T </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">const</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> right</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">macro</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]]</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>&nbsp; &nbsp; emit $</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">true</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">macro</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">]]</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// u=
sing in expression context forces it to emit expressions</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbs=
p; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
for</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> m</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">accessAll=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">().</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">fields</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">())</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; emit $</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">left</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">$member </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> right</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">$member</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nb=
sp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nb=
sp; &nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><=
br>And another pros - many type-checking traits can be reimplemented with m=
acro blocks and no template magic. Much cleaner and simpler.<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_745_233122431.1430844949190--
------=_Part_744_68500289.1430844949189--

.

------=_Part_1797_1987407289.1431072130117
Content-Type: multipart/alternative;
 boundary="----=_Part_1798_393660785.1431072130117"

------=_Part_1798_393660785.1431072130117
Content-Type: text/plain; charset=UTF-8

I sent a message very similar to yours. My idea was to expand on constexpr
functions since these already give you compile-time functions, just to need
add support for quoting, splicing, "emitting" code, (hygienic) name
generation, a standardized AST/reflection library, etc.

I think an extended constexpr approach may has some interesting results for
example being able to use the same code for both compile-time and runtime.
Imagine we had a rich standardized reflection library like in .NET/Java but
all the types/functions are also constexpr, it could mean that you have a
reflection library that can be used for both compile-time and runtime (and
there are definitely times when run-time meta-programming is
needed/desirable).

We could further expand on these capabilities to support user-defined
attributes like in .NET, a user-defined attribute is just a class, in C++
it could be a constexpr class. Nemerle is a .NET programming language which
on top of the standard .NET attributes lets your write user-defined
attributes with it's macro system, we could do the same for AST constexpr
functions.

Template meta-programming is not only ugly it's:

   - Severely limited compared to a real-solution for meta-programming.
   - The meta-language is different from the object language which requires
   C++ programmers to know 2 languages (3 with preprocessor macros in the mix).
   - Meta-language is untyped.
   - No debugging support and probably non-trivial to add such a thing.
   - Heavy template meta-programming bloats compile-times and code.
   - Only the "1%" knows and are willing to use it, the "99%" don't and is
   typically banned because it obscures code and hard to maintain.
   - Adding more features to templates for the sake of meta-programming
   just makes templates even more complex than they already are for everyone
   (users & compiler vendors), it's gaining to many responsibilities,
   templates should just focus on one thing what they originally designed to
   be used for that is parametric polymorphism.

On Tuesday, May 5, 2015 at 5:20:17 PM UTC+1, Igor Baidiuk wrote:
>
> First of all, I couldn't find complete list on all SG7 WIP proposals. So
> this could've been suggested. Though I didn't find exact match either.
>
> Macro-blocks plus quasi quotations.
>
> Why yet another?
>
>  - template-based proposals are ugly, let's be honest (N4113 AFAIK)
>  - syntax extensions propose adding counterpart to each control structure
> (Like N3882 with its for <> loop)
>
> A very brief example - modified from this one:
> https://groups.google.com/a/isocpp.org/d/msg/reflection/B4KkTkQ02s8/qW55dmV6h7UJ
>
> template<typename T>
> class MirrorClass()
> {
> public:
>   int foo;
>   [[macro]]
>   {
>     for (auto const& member: T.fields())
>       emit ${ $member.type() $member.name(); };
>   }
> };
>
>
> 1. [[macro]] here marks block as compile-time logic. Used for brevity,
> subject to change.
> 2. Types, statements, expressions become variables. So you can perfectly
> retrieve list of type's fields/methods/statics/supertypes etc.
> 3. 'emit' keyword - emits a piece of code into context. Acts more like
> 'yield', to be able to emit several chunks of code without composing them
> into single variable. Though yield/return may be reused here.
> 4. ${} - quasi-quotation, denotes piece of code. $-prefixed identifiers
> there are macro-variables from macro context. They're expanded into their
> context upon emit. They can contain [[macro]] blocks themselves, creating
> nested emit.
>
> Another example:
> template<typename... Args>
> [[macro]] static_assert(constexpr_expr condition, Args&&... args) -> void
> {
>   if (condition.type != bool)
>     error("static_assert condition must be a constexpr expression
> resolving to boolean type");
>   if (condition.result() != true)
>     error(format("static_assert violated: ", std::forward<Args>(args
> )...));
> }
>
> Shows possible implementation of static_assert with variadic argument
> support. Here 'condition's type shows that it accepts constexpr expression,
> evaluable at compile time. Though it can be just expr's property
> is_constexpr. Variadic arguments for such functions can be implemented not
> only via variadic templates. Doesn't matter here.
> 'void' return type might either denote that this particular function
> doesn't emit anything, or all macro functions might be void, as emitting
> code differs logically from returning value.
> 'error' call produces compile error. 'format' is some kind of constexpr
> formatter.
>
> Pros:
> + Cleaner syntax, no template verbosity or fancy constructs
> + Semantics seem to be easier to understand - we work with AST as with
> data, just in compile time and with certain limitations.
>
> Cons:
> - compile-time blocks look like ordinary code. Possible mix with other
> pieces
> - Need to support at least part of STL for compile-time mode. Or implement
> types of their own for identifiers, collections of members and the like.
>

--

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

<div dir=3D"ltr">I sent a message very similar to yours. My idea was to exp=
and on constexpr functions since these already give you compile-time functi=
ons, just to need add support for quoting, splicing, "emitting" code, (hygi=
enic) name generation, a standardized AST/reflection library, etc.<br><br>I=
 think an extended constexpr approach may has some interesting results for =
example being able to use the same code for both compile-time and runtime. =
Imagine we had a rich standardized reflection library like in .NET/Java but=
 all the types/functions are also constexpr, it could mean that you have a =
reflection library that can be used for both compile-time and runtime (and =
there are definitely times when run-time meta-programming is needed/desirab=
le).<br><br>We could further expand on these capabilities to support user-d=
efined attributes like in .NET, a user-defined attribute is just a class, i=
n C++ it could be a constexpr class. Nemerle is a .NET programming language=
 which on top of the standard .NET attributes lets your write user-defined =
attributes with it's macro system, we could do the same for AST constexpr f=
unctions.<br><br>Template meta-programming is not only ugly it's:<br><ul><l=
i>Severely limited compared to a real-solution for meta-programming.<br></l=
i><li>The meta-language is different from the object language which require=
s C++ programmers to know 2 languages (3 with preprocessor macros in the mi=
x).</li><li>Meta-language is untyped.</li><li>No debugging support and prob=
ably non-trivial to add such a thing.<br></li><li>Heavy template meta-progr=
amming bloats compile-times and code.<br></li><li>Only the "1%" knows and a=
re willing to use it, the "99%" don't and is typically banned because it ob=
scures code and hard to maintain.</li><li>Adding more features to templates=
 for the sake of meta-programming just makes templates even more complex th=
an they already are for everyone (users &amp; compiler vendors), it's gaini=
ng to many responsibilities, templates should just focus on one thing what =
they originally designed to be used for that is parametric polymorphism.<br=
></li></ul>On Tuesday, May 5, 2015 at 5:20:17 PM UTC+1, Igor Baidiuk wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">First of all,=
 I couldn't find complete list on all SG7 WIP proposals. So this could've b=
een suggested. Though I didn't find exact match either.<br><br>Macro-blocks=
 plus quasi quotations.<br><br>Why yet another?<br><br>&nbsp;- template-bas=
ed proposals are ugly, let's be honest (N4113 AFAIK)<br>&nbsp;- syntax exte=
nsions propose adding counterpart to each control structure (Like N3882 wit=
h its for &lt;&gt; loop)<br><br>A very brief example - modified from this o=
ne: <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/reflection/B4Kk=
TkQ02s8/qW55dmV6h7UJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'https://groups.google.com/a/isocpp.org/d/msg/reflection/B4KkTkQ02=
s8/qW55dmV6h7UJ';return true;" onclick=3D"this.href=3D'https://groups.googl=
e.com/a/isocpp.org/d/msg/reflection/B4KkTkQ02s8/qW55dmV6h7UJ';return true;"=
>https://groups.google.com/a/<wbr>isocpp.org/d/msg/reflection/<wbr>B4KkTkQ0=
2s8/qW55dmV6h7UJ</a><br><br><div style=3D"background-color:rgb(250,250,250)=
;border-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wra=
p:break-word"><code><div><span style=3D"color:#008">template</span><span st=
yle=3D"color:#660">&lt;</span><span style=3D"color:#008">typename</span><sp=
an style=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#008">class</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#606">MirrorClass</sp=
an><span style=3D"color:#660">()</span><span style=3D"color:#000"><br></spa=
n><span style=3D"color:#660">{</span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#008">public</span><span style=3D"color:#660">:</span>=
<span style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">int=
</span><span style=3D"color:#000"> foo</span><span style=3D"color:#660">;</=
span><span style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#660=
">[[</span><span style=3D"color:#000">macro</span><span style=3D"color:#660=
">]]</span><span style=3D"color:#000"><br>&nbsp; </span><span style=3D"colo=
r:#660">{</span><span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span s=
tyle=3D"color:#008">for</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">const</span><span style=
=3D"color:#660">&amp;</span><span style=3D"color:#000"> member</span><span =
style=3D"color:#660">:</span><span style=3D"color:#000"> T</span><span styl=
e=3D"color:#660">.</span><span style=3D"color:#000">fields</span><span styl=
e=3D"color:#660">())</span><span style=3D"color:#000"><br>&nbsp; &nbsp; &nb=
sp; emit $</span><span style=3D"color:#660">{</span><span style=3D"color:#0=
00"> $member</span><span style=3D"color:#660">.</span><span style=3D"color:=
#000">type</span><span style=3D"color:#660">()</span><span style=3D"color:#=
000"> $member</span><span style=3D"color:#660">.</span><span style=3D"color=
:#000">name</span><span style=3D"color:#660">();</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">};</span><span style=3D"color:#00=
0"><br>&nbsp; </span><span style=3D"color:#660">}</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#660">};</span><span style=3D"color=
:#000"><br><br></span></div></code></div><br>1. [[macro]] here marks block =
as compile-time logic. Used for brevity, subject to change.<br>2. Types, st=
atements, expressions become variables. So you can perfectly retrieve list =
of type's fields/methods/statics/<wbr>supertypes etc.<br>3. 'emit' keyword =
- emits a piece of code into context. Acts more like 'yield', to be able to=
 emit several chunks of code without composing them into single variable. T=
hough yield/return may be reused here.<br>4. ${} - quasi-quotation, denotes=
 piece of code. $-prefixed identifiers there are macro-variables from macro=
 context. They're expanded into their context upon emit. They can contain [=
[macro]] blocks themselves, creating nested emit.<br><br>Another example:<b=
r><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><=
span style=3D"color:#008">template</span><span style=3D"color:#660">&lt;</s=
pan><span style=3D"color:#008">typename</span><span style=3D"color:#660">..=
..</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Args<=
/span><span style=3D"color:#660">&gt;</span><span style=3D"color:#000"><br>=
</span><span style=3D"color:#660">[[</span><span style=3D"color:#000">macro=
</span><span style=3D"color:#660">]]</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">static_assert</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">constexpr_expr condition</span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Args</span><span style=3D"color:#660">&amp;&amp;...</span><=
span style=3D"color:#000"> args</span><span style=3D"color:#660">)</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">-&gt;</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#008">void</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#008">if</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span =
style=3D"color:#000">condition</span><span style=3D"color:#660">.</span><sp=
an style=3D"color:#000">type </span><span style=3D"color:#660">!=3D</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">bool</span><sp=
an style=3D"color:#660">)</span><span style=3D"color:#000"><br>&nbsp; &nbsp=
; error</span><span style=3D"color:#660">(</span><span style=3D"color:#080"=
>"static_assert condition must be a constexpr expression resolving to boole=
an type"</span><span style=3D"color:#660">);</span><span style=3D"color:#00=
0"><br>&nbsp; </span><span style=3D"color:#008">if</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#660">(</span><span style=3D"color:#0=
00">condition</span><span style=3D"color:#660">.</span><span style=3D"color=
:#000">result</span><span style=3D"color:#660">()</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">!=3D</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">true</span><span style=3D"color:#6=
60">)</span><span style=3D"color:#000"><br>&nbsp; &nbsp; error</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">format</span><span =
style=3D"color:#660">(</span><span style=3D"color:#080">"static_assert viol=
ated: "</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> std</span><span style=3D"color:#660">::</span><span style=3D"color:#000">=
forward</span><span style=3D"color:#660">&lt;</span><span style=3D"color:#6=
06">Args</span><span style=3D"color:#660">&gt;(</span><span style=3D"color:=
#000">args</span><span style=3D"color:#660">)...));</span><span style=3D"co=
lor:#000"><br></span><span style=3D"color:#660">}</span><span style=3D"colo=
r:#000"><br><br></span></div></code></div>Shows possible implementation of =
static_assert with variadic argument support. Here 'condition's type shows =
that it accepts constexpr expression, evaluable at compile time. Though it =
can be just expr's property is_constexpr. Variadic arguments for such funct=
ions can be implemented not only via variadic templates. Doesn't matter her=
e.<br>'void' return type might either denote that this particular function =
doesn't emit anything, or all macro functions might be void, as emitting co=
de differs logically from returning value.<br>'error' call produces compile=
 error. 'format' is some kind of constexpr formatter.<br><br>Pros:<br>+ Cle=
aner syntax, no template verbosity or fancy constructs<br>+ Semantics seem =
to be easier to understand - we work with AST as with data, just in compile=
 time and with certain limitations.<br><br>Cons:<br>- compile-time blocks l=
ook like ordinary code. Possible mix with other pieces<br>- Need to support=
 at least part of STL for compile-time mode. Or implement types of their ow=
n for identifiers, collections of members and the like.<br></div></blockquo=
te></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_1798_393660785.1431072130117--
------=_Part_1797_1987407289.1431072130117--

.

------=_Part_140_556909586.1431077495199
Content-Type: multipart/alternative;
 boundary="----=_Part_141_1245678276.1431077495199"

------=_Part_141_1245678276.1431077495199
Content-Type: text/plain; charset=UTF-8

On Friday, May 8, 2015 at 4:02:10 AM UTC-4, snk_kid wrote:
>
> I sent a message very similar to yours. My idea was to expand on constexpr
> functions since these already give you compile-time functions, just to need
> add support for quoting, splicing, "emitting" code, (hygienic) name
> generation, a standardized AST/reflection library, etc.
>

.... these are not "just" things to add. You seem to underestimate the
complexity of such functionality, particularly from a conceptual
perspective.

Here's my favorite example of a basic sanity check for any compile-time
reflection proposal: how much code do I need to write in order to, given
some object reference `obj`, go through all of the non-static data members
of `obj`'s (static) type and call a particular function for each member,
passing that member's value as a parameter?

Best case, this should be no more than three lines (of pseudo-code):

auto MemberDescriptionList = GetMemberIterator(decltype(obj));
SomeLoop(MemberDescription &desc = ...)
  Function(AccessMember(obj, desc));

That cannot be a function (constexpr or not) of any kind under the rules of
C++. The problem is that C++ is statically typed. And every expression must
have a single, well-defined type. The return type of `AccessMember` will
have to be different, based on the contents of `desc`. But you can't vary
the return type of a function based on the *contents* of a parameter.
That's a hard-and-fast rule of C++.

Template metaprogramming side-steps this rule via recursion.
`MemberDescriptionList` would be a class that has a variadic template
argument list. Each argument would be some `MemberDescription<T>`, with `T`
being the type of the argument. And therefore, you can have an
`AccessMember` that takes a `MemberDescription<T>` and returns a `T&` or
`const T&`. And you walk the list via recursively calling the function, as
with standard practice for variadic templates.

You can't break this rule without rewriting some of the most fundamental
rules of C++. At which point, your criticism of template metaprogramming
becomes rather ironic. Because however much you may want to think of what
you're suggesting as "just" a `constexpr` function, it will have to operate
under rules so alien to C++ that it will be as different from regular
runtime C++ as template metaprogramming is.

Take the OP's suggestion. It's basically a second macro language. Because
the first one worked out so well. It may look a bit like C++, but so does
template metaprogrmaming. And to be honest, TMP behaves more like regular
C++ than this macro language.


>
>    - No debugging support and probably non-trivial to add such a thing.
>
>
I fail to see how the proposed macro-style solution will be any easier to
debug. At least with concepts, TMP will be a lot easier to catch errors in.
Also, TMP is still nominally C++, so it works under the same rules.

>
>    - Adding more features to templates for the sake of meta-programming
>    just makes templates even more complex than they already are for everyone
>    (users & compiler vendors), it's gaining to many responsibilities,
>    templates should just focus on one thing what they originally designed to
>    be used for that is parametric polymorphism.
>
>
I admit that I haven't gone in depth with any of the reflection proposals.
But I didn't think that they were adding features to *templates*
specifically. I thought the various reflection features were simply
designed to work with existing metaprogramming facilities. That is,
reflection functionality returns metafunctions, tuples, or classes
containing variadic template parameter packs of types and so forth.

What language features, which makes templates "even more complex than they
already are," have been suggested for addition?

Also, I fail to see how introducing a second macro language (third if you
count templates as a limited, type-checked, macro language) makes the
language less 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_141_1245678276.1431077495199
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, May 8, 2015 at 4:02:10 AM UTC-4, snk_kid wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I sent a mess=
age very similar to yours. My idea was to expand on constexpr functions sin=
ce these already give you compile-time functions, just to need add support =
for quoting, splicing, "emitting" code, (hygienic) name generation, a stand=
ardized AST/reflection library, etc.<br></div></blockquote><div><br>... the=
se are not "just" things to add. You seem to underestimate the complexity o=
f such functionality, particularly from a conceptual perspective.<br><br>He=
re's my favorite example of a basic sanity check for any compile-time refle=
ction proposal: how much code do I need to write in order to, given some ob=
ject reference `obj`, go through all of the non-static data members of `obj=
`'s (static) type and call a particular function for each member, passing t=
hat member's value as a parameter?<br><br>Best case, this should be no more=
 than three lines (of pseudo-code):<br><br>auto MemberDescriptionList =3D G=
etMemberIterator(decltype(obj));<br>SomeLoop(MemberDescription &amp;desc =
=3D ...)<br>&nbsp; Function(AccessMember(obj, desc));<br><br>That cannot be=
 a function (constexpr or not) of any kind under the rules of C++. The prob=
lem is that C++ is statically typed. And every expression must have a singl=
e, well-defined type. The return type of `AccessMember` will have to be dif=
ferent, based on the contents of `desc`. But you can't vary the return type=
 of a function based on the <i>contents</i> of a parameter. That's a hard-a=
nd-fast rule of C++.<br><br>Template metaprogramming side-steps this rule v=
ia recursion. `MemberDescriptionList` would be a class that has a variadic =
template argument list. Each argument would be some `MemberDescription&lt;T=
&gt;`, with `T` being the type of the argument. And therefore, you can have=
 an `AccessMember` that takes a `MemberDescription&lt;T&gt;` and returns a =
`T&amp;` or `const T&amp;`. And you walk the list via recursively calling t=
he function, as with standard practice for variadic templates.<br><br>You c=
an't break this rule without rewriting some of the most fundamental rules o=
f C++. At which point, your criticism of template metaprogramming becomes r=
ather ironic. Because however much you may want to think of what you're sug=
gesting as "just" a `constexpr` function, it will have to operate under rul=
es so alien to C++ that it will be as different from regular runtime C++ as=
 template metaprogramming is.<br><br>Take the OP's suggestion. It's basical=
ly a second macro language. Because the first one worked out so well. It ma=
y look a bit like C++, but so does template metaprogrmaming. And to be hone=
st, TMP behaves more like regular C++ than this macro language.<br>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><ul><li>N=
o debugging support and probably non-trivial to add such a thing.<br></li><=
/ul></div></blockquote><div><br>I fail to see how the proposed macro-style =
solution will be any easier to debug. At least with concepts, TMP will be a=
 lot easier to catch errors in. Also, TMP is still nominally C++, so it wor=
ks under the same rules. <br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><ul><li>Adding more features to templates for the sa=
ke of meta-programming just makes templates even more complex than they alr=
eady are for everyone (users &amp; compiler vendors), it's gaining to many =
responsibilities, templates should just focus on one thing what they origin=
ally designed to be used for that is parametric polymorphism.<br></li></ul>=
</div></blockquote><div><br>I admit that I haven't gone in depth with any o=
f the reflection proposals. But I didn't think that they were adding featur=
es to <i>templates</i> specifically. I thought the various reflection featu=
res were simply designed to work with existing metaprogramming facilities. =
That is, reflection functionality returns metafunctions, tuples, or classes=
 containing variadic template parameter packs of types and so forth.<br><br=
>What language features, which makes templates "even more complex than they=
 already are," have been suggested for addition?<br><br>Also, I fail to see=
 how introducing a second macro language (third if you count templates as a=
 limited, type-checked, macro language) makes the language less complex.</d=
iv><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_141_1245678276.1431077495199--
------=_Part_140_556909586.1431077495199--

.

------=_Part_2081_518536520.1431078992717
Content-Type: multipart/alternative;
 boundary="----=_Part_2082_554652114.1431078992717"

------=_Part_2082_554652114.1431078992717
Content-Type: text/plain; charset=UTF-8

I made a similar proposal in the past month. I came up with this constexpr
ast lib:
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/ast.h

dd

Here's my favorite example of a basic sanity check for any compile-time
> reflection proposal: how much code do I need to write in order to, given
> some object reference `obj`, go through all of the non-static data members
> of `obj`'s (static) type and call a particular function for each member,
> passing that member's value as a parameter?
>
> Best case, this should be no more than three lines (of pseudo-code):
>
> auto MemberDescriptionList = GetMemberIterator(decltype(obj));
> SomeLoop(MemberDescription &desc = ...)
>   Function(AccessMember(obj, desc));
>

With my proposal (
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/constexpr_id_proposal.md
) it will looks like this

#<for> (member : typeid<decltype(obj)>.members())
   #<if> (!(member.specifiers() |= ast_decl::Static))
      Function(#<id>member.name()#</id>);
  #</if>
#</for>



> That cannot be a function (constexpr or not) of any kind under the rules
> of C++. The problem is that C++ is statically typed. And every expression
> must have a single, well-defined type. The return type of `AccessMember`
> will have to be different, based on the contents of `desc`. But you can't
> vary the return type of a function based on the *contents* of a
> parameter. That's a hard-and-fast rule of C++.
>
But you can store the type in an enum vale, and you can create safe casts
on it. Just look at the linked ast.h. Every AST node can store its type in
an enum value.

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

<div dir=3D"ltr">I made a similar proposal in the past month. I came up wit=
h this constexpr ast lib:<div><a href=3D"https://github.com/hun-nemethpeter=
/cpp-reflector-mini/blob/master/constexpr-ast/ast.h">https://github.com/hun=
-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/ast.h</a></div><d=
iv><br></div><div>dd<br><br><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>Here's my favorite example of a basic sanity check for =
any compile-time reflection proposal: how much code do I need to write in o=
rder to, given some object reference `obj`, go through all of the non-stati=
c data members of `obj`'s (static) type and call a particular function for =
each member, passing that member's value as a parameter?<br><br>Best case, =
this should be no more than three lines (of pseudo-code):<br><br>auto Membe=
rDescriptionList =3D GetMemberIterator(decltype(<wbr>obj));<br>SomeLoop(Mem=
berDescription &amp;desc =3D ...)<br>&nbsp; Function(AccessMember(obj, desc=
));<br></div></div></blockquote><div><br></div><div>With my proposal ( <a h=
ref=3D"https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/co=
nstexpr-ast/constexpr_id_proposal.md">https://github.com/hun-nemethpeter/cp=
p-reflector-mini/blob/master/constexpr-ast/constexpr_id_proposal.md</a> ) i=
t will looks like this</div><div><br></div><font face=3D"courier new, monos=
pace">#&lt;for&gt; (member : typeid&lt;decltype(obj)&gt;.members())<br>&nbs=
p; &nbsp;#&lt;if&gt; (!(member.specifiers() |=3D ast_decl::Static))<br>&nbs=
p; &nbsp; &nbsp; Function(#&lt;id&gt;member.name()#&lt;/id&gt;);<br>&nbsp; =
#&lt;/if&gt;<br>#&lt;/for&gt;<br></font><br><br><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div><br>That cannot be a function (cons=
texpr or not) of any kind under the rules of C++. The problem is that C++ i=
s statically typed. And every expression must have a single, well-defined t=
ype. The return type of `AccessMember` will have to be different, based on =
the contents of `desc`. But you can't vary the return type of a function ba=
sed on the <i>contents</i> of a parameter. That's a hard-and-fast rule of C=
++.<br></div></div></blockquote><div>But you can store the type in an enum =
vale, and you can create safe casts on it. Just look at the linked ast.h. E=
very AST node can store its type in an enum value.</div><div><br></div><div=
>Peter</div><div>&nbsp;</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 />

------=_Part_2082_554652114.1431078992717--
------=_Part_2081_518536520.1431078992717--

.

On Friday 08 May 2015 01:02:10 snk_kid wrote:
>    - The meta-language is different from the object language which requires
> C++ programmers to know 2 languages (3 with preprocessor macros in the
> mix). - Meta-language is untyped.
>    - No debugging support and probably non-trivial to add such a thing.
>    - Only the "1%" knows and are willing to use it, the "99%" don't and is
>    typically banned because it obscures code and hard to maintain.

The above points also apply to a language for meta programming.

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

--

---
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_2695_1225279948.1431102111075
Content-Type: multipart/alternative;
 boundary="----=_Part_2696_1059394953.1431102111075"

------=_Part_2696_1059394953.1431102111075
Content-Type: text/plain; charset=UTF-8



On Friday, May 8, 2015 at 5:56:32 AM UTC-4, hun.nem...@gmail.com wrote:
>
> I made a similar proposal in the past month. I came up with this constexpr
> ast lib:
>
> https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/ast.h
>
> dd
>
> Here's my favorite example of a basic sanity check for any compile-time
>> reflection proposal: how much code do I need to write in order to, given
>> some object reference `obj`, go through all of the non-static data members
>> of `obj`'s (static) type and call a particular function for each member,
>> passing that member's value as a parameter?
>>
>> Best case, this should be no more than three lines (of pseudo-code):
>>
>> auto MemberDescriptionList = GetMemberIterator(decltype(obj));
>> SomeLoop(MemberDescription &desc = ...)
>>   Function(AccessMember(obj, desc));
>>
>
> With my proposal (
> https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/constexpr_id_proposal.md
> ) it will looks like this
>
> #<for> (member : typeid<decltype(obj)>.members())
>    #<if> (!(member.specifiers() |= ast_decl::Static))
>       Function(#<id>member.name()#</id>);
>   #</if>
> #</for>
>

I don't see the part where it accesses the member of `obj`. It looks like
this just passes the member names.

Also, as Thiago pointed out, this is very much:

* A different language from C++
* Lacks any effective debugging (it's more debuggable than macro
programming, but still difficult to find errors with)
* Only the "1%" will know how to use it effectively (due to being a new
language).


>
>> That cannot be a function (constexpr or not) of any kind under the rules
>> of C++. The problem is that C++ is statically typed. And every expression
>> must have a single, well-defined type. The return type of `AccessMember`
>> will have to be different, based on the contents of `desc`. But you can't
>> vary the return type of a function based on the *contents* of a
>> parameter. That's a hard-and-fast rule of C++.
>>
> But you can store the type in an enum vale, and you can create safe casts
> on it. Just look at the linked ast.h. Every AST node can store its type in
> an enum value.
>

Oh sure, you can store a type as an enum. But you cannot reverse that
process. Once you have converted a type into an value, you have lost the
ability to go backwards. You cannot do this:

type_cast(enum_value) T{};

Whatever `type_cast` is, it must result in exactly and only one type,
regardless of the value of `enum_value`. It could potentially result in a
different type based on the *type* of `enum_value`, but not based on its
actual value.

At least, you can't do that without fundamentally changing C++ by adding
some new kind of thing to it. And to do that breaks static typing, which is
something that even TMP does not do.

--

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

<div dir=3D"ltr"><br><br>On Friday, May 8, 2015 at 5:56:32 AM UTC-4, hun.ne=
m...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">I made a similar proposal in the past month. I came up with this c=
onstexpr ast lib:<div><a href=3D"https://github.com/hun-nemethpeter/cpp-ref=
lector-mini/blob/master/constexpr-ast/ast.h" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F=
%2Fgithub.com%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2Fmaster%2Fcons=
texpr-ast%2Fast.h\46sa\75D\46sntz\0751\46usg\75AFQjCNEGnz62S59pNq6soP8Uh6ex=
66RVnw';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\=
75https%3A%2F%2Fgithub.com%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2F=
master%2Fconstexpr-ast%2Fast.h\46sa\75D\46sntz\0751\46usg\75AFQjCNEGnz62S59=
pNq6soP8Uh6ex66RVnw';return true;">https://github.com/hun-<wbr>nemethpeter/=
cpp-reflector-<wbr>mini/blob/master/constexpr-<wbr>ast/ast.h</a></div><div>=
<br></div><div>dd<br><br><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>Here's my favorite example of a basic sanity check for any co=
mpile-time reflection proposal: how much code do I need to write in order t=
o, given some object reference `obj`, go through all of the non-static data=
 members of `obj`'s (static) type and call a particular function for each m=
ember, passing that member's value as a parameter?<br><br>Best case, this s=
hould be no more than three lines (of pseudo-code):<br><br>auto MemberDescr=
iptionList =3D GetMemberIterator(decltype(<wbr>obj));<br>SomeLoop(MemberDes=
cription &amp;desc =3D ...)<br>&nbsp; Function(AccessMember(obj, desc));<br=
></div></div></blockquote><div><br></div><div>With my proposal ( <a href=3D=
"https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexp=
r-ast/constexpr_id_proposal.md" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com=
%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2Fmaster%2Fconstexpr-ast%2Fc=
onstexpr_id_proposal.md\46sa\75D\46sntz\0751\46usg\75AFQjCNGk8qzLjVMcKU_Mm2=
AN3kzmdxA3cA';return true;" onclick=3D"this.href=3D'https://www.google.com/=
url?q\75https%3A%2F%2Fgithub.com%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fb=
lob%2Fmaster%2Fconstexpr-ast%2Fconstexpr_id_proposal.md\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGk8qzLjVMcKU_Mm2AN3kzmdxA3cA';return true;">https://github.=
com/hun-<wbr>nemethpeter/cpp-reflector-<wbr>mini/blob/master/constexpr-<wbr=
>ast/constexpr_id_proposal.md</a> ) it will looks like this</div><div><br><=
/div><font face=3D"courier new, monospace">#&lt;for&gt; (member : typeid&lt=
;decltype(obj)&gt;.members(<wbr>))<br>&nbsp; &nbsp;#&lt;if&gt; (!(member.sp=
ecifiers() |=3D ast_decl::Static))<br>&nbsp; &nbsp; &nbsp; Function(#&lt;id=
&gt;<a href=3D"http://member.name" target=3D"_blank" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmember.na=
me\46sa\75D\46sntz\0751\46usg\75AFQjCNEAvoyC-dUSGkhSr0g1s2DVoXsBsw';return =
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fm=
ember.name\46sa\75D\46sntz\0751\46usg\75AFQjCNEAvoyC-dUSGkhSr0g1s2DVoXsBsw'=
;return true;">member.name</a>()#&lt;/<wbr>id&gt;);<br>&nbsp; #&lt;/if&gt;<=
br>#&lt;/for&gt;<br></font></div></div></blockquote><div><br>I don't see th=
e part where it accesses the member of `obj`. It looks like this just passe=
s the member names.<br><br>Also, as Thiago pointed out, this is very much:<=
br><br>* A different language from C++<br>* Lacks any effective debugging (=
it's more debuggable than macro programming, but still difficult to find er=
rors with)<br>* Only the "1%" will know how to use it effectively (due to b=
eing a new language).<br>&nbsp;</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div><font face=3D"courier new, monospace"></font><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>That canno=
t be a function (constexpr or not) of any kind under the rules of C++. The =
problem is that C++ is statically typed. And every expression must have a s=
ingle, well-defined type. The return type of `AccessMember` will have to be=
 different, based on the contents of `desc`. But you can't vary the return =
type of a function based on the <i>contents</i> of a parameter. That's a ha=
rd-and-fast rule of C++.<br></div></div></blockquote><div>But you can store=
 the type in an enum vale, and you can create safe casts on it. Just look a=
t the linked ast.h. Every AST node can store its type in an enum value.</di=
v></div></div></blockquote><div><br>Oh sure, you can store a type as an enu=
m. But you cannot reverse that process. Once you have converted a type into=
 an value, you have lost the ability to go backwards. You cannot do this:<b=
r><br>type_cast(enum_value) T{};<br><br>Whatever `type_cast` is, it must re=
sult in exactly and only one type, regardless of the value of `enum_value`.=
 It could potentially result in a different type based on the <i>type</i> o=
f `enum_value`, but not based on its actual value.<br><br>At least, you can=
't do that without fundamentally changing C++ by adding some new kind of th=
ing to it. And to do that breaks static typing, which is something that eve=
n TMP does not do.</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_2696_1059394953.1431102111075--
------=_Part_2695_1225279948.1431102111075--

.

------=_Part_412_30465988.1431104885410
Content-Type: multipart/alternative;
 boundary="----=_Part_413_940752330.1431104885410"

------=_Part_413_940752330.1431104885410
Content-Type: text/plain; charset=UTF-8



On Friday, May 8, 2015 at 6:21:51 PM UTC+2, Nicol Bolas wrote:
>
>
>
> On Friday, May 8, 2015 at 5:56:32 AM UTC-4, hun.nem...@gmail.com wrote:
>>
>> I made a similar proposal in the past month. I came up with this
>> constexpr ast lib:
>>
>> https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/ast.h
>>
>> dd
>>
>> Here's my favorite example of a basic sanity check for any compile-time
>>> reflection proposal: how much code do I need to write in order to, given
>>> some object reference `obj`, go through all of the non-static data members
>>> of `obj`'s (static) type and call a particular function for each member,
>>> passing that member's value as a parameter?
>>>
>>> Best case, this should be no more than three lines (of pseudo-code):
>>>
>>> auto MemberDescriptionList = GetMemberIterator(decltype(obj));
>>> SomeLoop(MemberDescription &desc = ...)
>>>   Function(AccessMember(obj, desc));
>>>
>>
>> With my proposal (
>> https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/constexpr_id_proposal.md
>> ) it will looks like this
>>
>> #<for> (member : typeid<decltype(obj)>.members())
>>    #<if> (!(member.specifiers() |= ast_decl::Static))
>>       Function(#<id>member.name()#</id>);
>>   #</if>
>> #</for>
>>
>
> I don't see the part where it accesses the member of `obj`. It looks like
> this just passes the member names.
>
Sorry, I missed it. Here is the corrected one line:
      Function(obj.#<id>member.name()#</id>);


> Also, as Thiago pointed out, this is very much:
>
>
* A different language from C++
>
Why do you think that this is a different language? It is just an
extension. Very similar to the preprocessor, but it deal with constexpr.
Just now there is now statement and declaration repeater in the language.
Only runtime repeater is exist. And a new feature requires a new language
construct.


> * Lacks any effective debugging (it's more debuggable than macro
> programming, but still difficult to find errors with)
>
Why do you think that it lacks any "effective debugging"? And why do think
that "difficult to find errors with" it? For example without any extra
effort you can simply call clang as
clang++ -cc1 -std=c++1z -ast-print $FILE
or
clang++ -cc1 -std=c++1z -ast-dump $FILE
And can check what was generated.



> * Only the "1%" will know how to use it effectively (due to being a new
> language).
>
I think this kind of construct has no cognitive overhead. It doesn't force
you to think differently. But a functional style meta programming has
serious cognitive overhead. Okey, at least for me and most of my
colleagues. Maybe we aren't the smartest people in the world.


>
>
>>
>>> That cannot be a function (constexpr or not) of any kind under the rules
>>> of C++. The problem is that C++ is statically typed. And every expression
>>> must have a single, well-defined type. The return type of `AccessMember`
>>> will have to be different, based on the contents of `desc`. But you can't
>>> vary the return type of a function based on the *contents* of a
>>> parameter. That's a hard-and-fast rule of C++.
>>>
>> But you can store the type in an enum vale, and you can create safe casts
>> on it. Just look at the linked ast.h. Every AST node can store its type in
>> an enum value.
>>
>
> Oh sure, you can store a type as an enum. But you cannot reverse that
> process. Once you have converted a type into an value, you have lost the
> ability to go backwards. You cannot do this:
>
> type_cast(enum_value) T{};
>
> Whatever `type_cast` is, it must result in exactly and only one type,
> regardless of the value of `enum_value`. It could potentially result in a
> different type based on the *type* of `enum_value`, but not based on its
> actual value.
>

I don't understand this part. Can you give me a detailed example what you
want to achieve with this construct?
What I really like to do with my proposal is an easy
serialization/deserialization and automactic generation of client/server
RPC classes. Now I have to use external code generation tools for it.


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

<div dir=3D"ltr"><br><br>On Friday, May 8, 2015 at 6:21:51 PM UTC+2, Nicol =
Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br><br>On Friday, May 8, 2015 at 5:56:32 AM UTC-4, <a>hun.nem...@gmail.com<=
/a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I made a=
 similar proposal in the past month. I came up with this constexpr ast lib:=
<div><a href=3D"https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/=
master/constexpr-ast/ast.h" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2F=
hun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2Fmaster%2Fconstexpr-ast%2Fast.=
h\46sa\75D\46sntz\0751\46usg\75AFQjCNEGnz62S59pNq6soP8Uh6ex66RVnw';return t=
rue;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2F=
github.com%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2Fmaster%2Fconstex=
pr-ast%2Fast.h\46sa\75D\46sntz\0751\46usg\75AFQjCNEGnz62S59pNq6soP8Uh6ex66R=
Vnw';return true;">https://github.com/hun-<wbr>nemethpeter/cpp-reflector-<w=
br>mini/blob/master/constexpr-<wbr>ast/ast.h</a></div><div><br></div><div>d=
d<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Here=
's my favorite example of a basic sanity check for any compile-time reflect=
ion proposal: how much code do I need to write in order to, given some obje=
ct reference `obj`, go through all of the non-static data members of `obj`'=
s (static) type and call a particular function for each member, passing tha=
t member's value as a parameter?<br><br>Best case, this should be no more t=
han three lines (of pseudo-code):<br><br>auto MemberDescriptionList =3D Get=
MemberIterator(decltype(<wbr>obj));<br>SomeLoop(MemberDescription &amp;desc=
 =3D ...)<br>&nbsp; Function(AccessMember(obj, desc));<br></div></div></blo=
ckquote><div><br></div><div>With my proposal ( <a href=3D"https://github.co=
m/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/constexpr_id=
_proposal.md" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fhun-nemethpet=
er%2Fcpp-reflector-mini%2Fblob%2Fmaster%2Fconstexpr-ast%2Fconstexpr_id_prop=
osal.md\46sa\75D\46sntz\0751\46usg\75AFQjCNGk8qzLjVMcKU_Mm2AN3kzmdxA3cA';re=
turn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\75https%3A=
%2F%2Fgithub.com%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2Fmaster%2Fc=
onstexpr-ast%2Fconstexpr_id_proposal.md\46sa\75D\46sntz\0751\46usg\75AFQjCN=
Gk8qzLjVMcKU_Mm2AN3kzmdxA3cA';return true;">https://github.com/hun-<wbr>nem=
ethpeter/cpp-reflector-<wbr>mini/blob/master/constexpr-<wbr>ast/constexpr_i=
d_proposal.md</a> ) it will looks like this</div><div><br></div><font face=
=3D"courier new, monospace">#&lt;for&gt; (member : typeid&lt;decltype(obj)&=
gt;.members(<wbr>))<br>&nbsp; &nbsp;#&lt;if&gt; (!(member.specifiers() |=3D=
 ast_decl::Static))<br>&nbsp; &nbsp; &nbsp; Function(#&lt;id&gt;<a href=3D"=
http://member.name" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.=
href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmember.name\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNEAvoyC-dUSGkhSr0g1s2DVoXsBsw';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fmember.name\46s=
a\75D\46sntz\0751\46usg\75AFQjCNEAvoyC-dUSGkhSr0g1s2DVoXsBsw';return true;"=
>member.name</a>()#&lt;/<wbr>id&gt;);<br>&nbsp; #&lt;/if&gt;<br>#&lt;/for&g=
t;<br></font></div></div></blockquote><div><br>I don't see the part where i=
t accesses the member of `obj`. It looks like this just passes the member n=
ames.<br></div></div></blockquote><div>Sorry, I missed it. Here is the corr=
ected one line:<br><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbs=
p; Function(obj.#&lt;id&gt;<a href=3D"http://member.name" rel=3D"nofollow" =
target=3D"_blank">member.name</a>()#&lt;/<wbr>id&gt;);<br></font><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>Also=
, as Thiago pointed out, this is very much:<br>&nbsp;</div></div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>* A d=
ifferent language from C++<br></div></div></blockquote><div>Why do you thin=
k that this is a different language? It is just an extension. Very similar =
to the preprocessor, but it deal with constexpr. Just now there is now stat=
ement and declaration repeater in the language. Only runtime repeater is ex=
ist. And a new feature requires a new language construct. <br></div><div>&n=
bsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>* Lacks any effective debugging (it's more debuggable than macro programm=
ing, but still difficult to find errors with)<br></div></div></blockquote><=
div>Why do you think that it lacks any "effective debugging"? And why do th=
ink that "difficult to find errors with" it? For example without any extra =
effort you can simply call clang as<br>clang++ -cc1 -std=3Dc++1z -ast-print=
 $FILE<br>or<br>clang++ -cc1 -std=3Dc++1z -ast-dump $FILE<br>And can check =
what was generated.<br><br>&nbsp;</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div>* Only the "1%" will know how to use it effe=
ctively (due to being a new language).<br></div></div></blockquote><div>I t=
hink this kind of construct has no cognitive overhead. It doesn't force you=
 to think differently. But a functional style meta programming has serious =
cognitive overhead. Okey, at least for me and most of my colleagues. Maybe =
we aren't the smartest people in the world.<br>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><font face=3D"courier new=
, monospace"></font><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><br>That cannot be a function (constexpr or not) of any kind under t=
he rules of C++. The problem is that C++ is statically typed. And every exp=
ression must have a single, well-defined type. The return type of `AccessMe=
mber` will have to be different, based on the contents of `desc`. But you c=
an't vary the return type of a function based on the <i>contents</i> of a p=
arameter. That's a hard-and-fast rule of C++.<br></div></div></blockquote><=
div>But you can store the type in an enum vale, and you can create safe cas=
ts on it. Just look at the linked ast.h. Every AST node can store its type =
in an enum value.</div></div></div></blockquote><div><br>Oh sure, you can s=
tore a type as an enum. But you cannot reverse that process. Once you have =
converted a type into an value, you have lost the ability to go backwards. =
You cannot do this:<br><br>type_cast(enum_value) T{};<br><br>Whatever `type=
_cast` is, it must result in exactly and only one type, regardless of the v=
alue of `enum_value`. It could potentially result in a different type based=
 on the <i>type</i> of `enum_value`, but not based on its actual value.<br>=
</div></div></blockquote><div><br>I don't understand this part. Can you giv=
e me a detailed example what you want to achieve with this construct?<br>Wh=
at I really like to do with my proposal is an easy serialization/deserializ=
ation and automactic generation of client/server RPC classes. Now I have to=
 use external code generation tools for it.<br><br><br>Peter <br></div><br>=
</div>

<p></p>

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

.

------=_Part_428_1891391330.1431106397295
Content-Type: multipart/alternative;
 boundary="----=_Part_429_131772666.1431106397300"

------=_Part_429_131772666.1431106397300
Content-Type: text/plain; charset=UTF-8

On Friday, May 8, 2015 at 1:08:05 PM UTC-4, hun.nem...@gmail.com wrote:
>
> On Friday, May 8, 2015 at 6:21:51 PM UTC+2, Nicol Bolas wrote:
>
>
>> Also, as Thiago pointed out, this is very much:
>>
>>
> * A different language from C++
>>
> Why do you think that this is a different language? It is just an
> extension. Very similar to the preprocessor, but it deal with constexpr.
> Just now there is now statement and declaration repeater in the language.
> Only runtime repeater is exist. And a new feature requires a new language
> construct.
>

If macros are a new language, as you claimed, then so is this. You're doing
token pasting, token parsing. These #<> constructs are not merely an
extension; they have completely different rules from regular,
statically-typed C++.

Again, in C++, every expression has a type that is known purely from the
types of the components of that expression. In your meta-language, this is
no longer the case.


>
>
>> * Lacks any effective debugging (it's more debuggable than macro
>> programming, but still difficult to find errors with)
>>
> Why do you think that it lacks any "effective debugging"? And why do think
> that "difficult to find errors with" it?
>

Because you can't put a breakpoint on it and look at symbols. Take your
#<for> construct. That is a loop which must be unrolled. At compile-time.
So, if I put a breakpoint in that loop... where does it get hit? How can I
inspect the "variables" that are nothing more than macros?

The #<if> condition. Those are compile-time conditions. So at compile time,
the compiler will detect the condition and eliminate both the internals and
the check itself if the condition fails. So... how do I put a break point
on it and see which members are being tested against?


> For example without any extra effort you can simply call clang as
> clang++ -cc1 -std=c++1z -ast-print $FILE
> or
> clang++ -cc1 -std=c++1z -ast-dump $FILE
> And can check what was generated.
>

You consider running a command-line tool and dumping an AST to be
"debuggable"? You're basically saying that it's no easier to debug than
macros.


>
>>
>>>
>>>> That cannot be a function (constexpr or not) of any kind under the
>>>> rules of C++. The problem is that C++ is statically typed. And every
>>>> expression must have a single, well-defined type. The return type of
>>>> `AccessMember` will have to be different, based on the contents of `desc`.
>>>> But you can't vary the return type of a function based on the
>>>> *contents* of a parameter. That's a hard-and-fast rule of C++.
>>>>
>>> But you can store the type in an enum vale, and you can create safe
>>> casts on it. Just look at the linked ast.h. Every AST node can store its
>>> type in an enum value.
>>>
>>
>> Oh sure, you can store a type as an enum. But you cannot reverse that
>> process. Once you have converted a type into an value, you have lost the
>> ability to go backwards. You cannot do this:
>>
>> type_cast(enum_value) T{};
>>
>> Whatever `type_cast` is, it must result in exactly and only one type,
>> regardless of the value of `enum_value`. It could potentially result in a
>> different type based on the *type* of `enum_value`, but not based on its
>> actual value.
>>
>
> I don't understand this part. Can you give me a detailed example what you
> want to achieve with this construct?
>

I'm not suggesting that as syntax. I'm explaining that C++ doesn't allow
for *any* such construct, where different executions of that statement can
result in the creation of objects of varying types. Indeed, 90% of the
complexity of TMP is working around the fact that C++ is statically typed.

So any modification to C++ to allow that, like your macro syntax, is
effectively changing the rules of C++ in a very significant way.


> What I really like to do with my proposal is an easy
> serialization/deserialization and automactic generation of client/server
> RPC classes. Now I have to use external code generation tools for it.
>

In my experience, "easy serialization" is not viable. Sooner or later, you
are going to want to modify a class. Which means you need to be able to
read the old format and the new.

At which point, most if not all of your automatic, reflection-based
techniques go out the window. Because now you need to write special-case
code to do the 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_429_131772666.1431106397300
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, May 8, 2015 at 1:08:05 PM UTC-4, hun.nem...@gma=
il.com wrote:<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">=
On Friday, May 8, 2015 at 6:21:51 PM UTC+2, Nicol Bolas wrote:<br><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>Als=
o, as Thiago pointed out, this is very much:<br>&nbsp;</div></div></blockqu=
ote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>* A diffe=
rent language from C++<br></div></div></blockquote><div>Why do you think th=
at this is a different language? It is just an extension. Very similar to t=
he preprocessor, but it deal with constexpr. Just now there is now statemen=
t and declaration repeater in the language. Only runtime repeater is exist.=
 And a new feature requires a new language construct. <br></div></div></blo=
ckquote><div><br>If macros are a new language, as you claimed, then so is t=
his. You're doing token pasting, token parsing. These #&lt;&gt; constructs =
are not merely an extension; they have <i></i>completely different rules fr=
om regular, statically-typed C++.<br><br>Again, in C++, every expression ha=
s a type that is known purely from the types of the components of that expr=
ession. In your meta-language, this is no longer the case.<br>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><di=
v>&nbsp;</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=
>* Lacks any effective debugging (it's more debuggable than macro programmi=
ng, but still difficult to find errors with)<br></div></div></blockquote><d=
iv>Why do you think that it lacks any "effective debugging"? And why do thi=
nk that "difficult to find errors with" it?</div></div></blockquote><div><b=
r>Because you can't put a breakpoint on it and look at symbols. Take your #=
&lt;for&gt; construct. That is a loop which must be unrolled. At compile-ti=
me. So, if I put a breakpoint in that loop... where does it get hit? How ca=
n I inspect the "variables" that are nothing more than macros?<br><br>The #=
&lt;if&gt; condition. Those are compile-time conditions. So at compile time=
, the compiler will detect the condition and eliminate both the internals a=
nd the check itself if the condition fails. So... how do I put a break poin=
t on it and see which members are being tested against?<br>&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>For example =
without any extra effort you can simply call clang as<br>clang++ -cc1 -std=
=3Dc++1z -ast-print $FILE<br>or<br>clang++ -cc1 -std=3Dc++1z -ast-dump $FIL=
E<br>And can check what was generated.<br></div></div></blockquote><div><br=
>You consider running a command-line tool and dumping an AST to be "debugga=
ble"? You're basically saying that it's no easier to debug than macros. <br=
>&nbsp;</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">=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>&nbsp;</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><font face=3D"=
courier new, monospace"></font><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><br>That cannot be a function (constexpr or not) of any k=
ind under the rules of C++. The problem is that C++ is statically typed. An=
d every expression must have a single, well-defined type. The return type o=
f `AccessMember` will have to be different, based on the contents of `desc`=
.. But you can't vary the return type of a function based on the <i>contents=
</i> of a parameter. That's a hard-and-fast rule of C++.<br></div></div></b=
lockquote><div>But you can store the type in an enum vale, and you can crea=
te safe casts on it. Just look at the linked ast.h. Every AST node can stor=
e its type in an enum value.</div></div></div></blockquote><div><br>Oh sure=
, you can store a type as an enum. But you cannot reverse that process. Onc=
e you have converted a type into an value, you have lost the ability to go =
backwards. You cannot do this:<br><br>type_cast(enum_value) T{};<br><br>Wha=
tever `type_cast` is, it must result in exactly and only one type, regardle=
ss of the value of `enum_value`. It could potentially result in a different=
 type based on the <i>type</i> of `enum_value`, but not based on its actual=
 value.<br></div></div></blockquote><div><br>I don't understand this part. =
Can you give me a detailed example what you want to achieve with this const=
ruct?<br></div></div></blockquote><div><br>I'm not suggesting that as synta=
x. I'm explaining that C++ doesn't allow for <i>any</i> such construct, whe=
re different executions of that statement can result in the creation of obj=
ects of varying types. Indeed, 90% of the complexity of TMP is working arou=
nd the fact that C++ is statically typed.<br><br>So any modification to C++=
 to allow that, like your macro syntax, is effectively changing the rules o=
f C++ in a very significant way.<br>&nbsp;</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div>What I really like to do with my pr=
oposal is an easy serialization/deserialization and automactic generation o=
f client/server RPC classes. Now I have to use external code generation too=
ls for it.<br></div></div></blockquote><div><br>In my experience, "easy ser=
ialization" is not viable. Sooner or later, you are going to want to modify=
 a class. Which means you need to be able to read the old format and the ne=
w.<br><br>At which point, most if not all of your automatic, reflection-bas=
ed techniques go out the window. Because now you need to write special-case=
 code to do the translation.</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_429_131772666.1431106397300--
------=_Part_428_1891391330.1431106397295--

.

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

>> Also, as Thiago pointed out, this is very much:
>>>
>>>
>> * A different language from C++
>>>
>> Why do you think that this is a different language? It is just an
>> extension. Very similar to the preprocessor, but it deal with constexpr.
>> Just now there is now statement and declaration repeater in the language.
>> Only runtime repeater is exist. And a new feature requires a new language
>> construct.
>>
>
> If macros are a new language, as you claimed, then so is this. You're
> doing token pasting, token parsing. These #<> constructs are not merely an
> extension; they have completely different rules from regular,
> statically-typed C++.
>
The preprocessor is part of the C++ language and it is a textual tool. What
I want is a little bit similar but in a non-textual form. It will be much
safer to use than the C++ preprocessor part. They can work on declarations
and statements. This lowering is needed for code generation. And I think my
proposal doesn't hurt the statically-typed C++ concept.

Again, in C++, every expression has a type that is known purely from the
types of the components of that expression. In your meta-language, this is
no longer the case.


>
>>
>>> * Lacks any effective debugging (it's more debuggable than macro
>>> programming, but still difficult to find errors with)
>>>
>> Why do you think that it lacks any "effective debugging"? And why do
>> think that "difficult to find errors with" it?
>>
>
> Because you can't put a breakpoint on it and look at symbols. Take your
> #<for> construct. That is a loop which must be unrolled. At compile-time.
> So, if I put a breakpoint in that loop... where does it get hit? How can I
> inspect the "variables" that are nothing more than macros?
>
And do you think you can put a breakpoint to a variable declaration or a
constexpr expression? Constexpr is part of the language and it "runs" in
compile time. C++ is not runtime only.



>
> The #<if> condition. Those are compile-time conditions. So at compile
> time, the compiler will detect the condition and eliminate both the
> internals and the check itself if the condition fails. So... how do I put a
> break point on it and see which members are being tested against?
>
Breakpoints work in runtime not in compile time. But theoretically you can
invent a compile time debugger. A constexpr is basically a compile time
interpreted C++.



>
>
>> For example without any extra effort you can simply call clang as
>> clang++ -cc1 -std=c++1z -ast-print $FILE
>> or
>> clang++ -cc1 -std=c++1z -ast-dump $FILE
>> And can check what was generated.
>>
>
> You consider running a command-line tool and dumping an AST to be
> "debuggable"? You're basically saying that it's no easier to debug than
> macros.
>
The problem with macros is that they ruins the namespaces and do everything
textually. Textual macros "invented" somewhere in the 1960s. It was just
inherited from C.



>
> I don't understand this part. Can you give me a detailed example what you
>> want to achieve with this construct?
>>
>
> I'm not suggesting that as syntax. I'm explaining that C++ doesn't allow
> for *any* such construct, where different executions of that statement
> can result in the creation of objects of varying types. Indeed, 90% of the
> complexity of TMP is working around the fact that C++ is statically typed.
>
> So any modification to C++ to allow that, like your macro syntax, is
> effectively changing the rules of C++ in a very significant way.
>
I don't think so. The language is evolving that's all.


>
>
>> What I really like to do with my proposal is an easy
>> serialization/deserialization and automactic generation of client/server
>> RPC classes. Now I have to use external code generation tools for it.
>>
>
> In my experience, "easy serialization" is not viable. Sooner or later, you
> are going to want to modify a class. Which means you need to be able to
> read the old format and the new.
>
> At which point, most if not all of your automatic, reflection-based
> techniques go out the window. Because now you need to write special-case
> code to do the translation.
>
No. Code generators can be replaced with compile time code generators.


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

--e89a8ff25680416315051595b934
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"><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">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br><div dir=3D"ltr"><spa=
n 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 dir=3D"=
ltr"><div>Also, as Thiago pointed out, this is very much:<br>=C2=A0</div></=
div></blockquote><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>* A different language from C++<br></div></div></blockquote><=
div>Why do you think that this is a different language? It is just an exten=
sion. Very similar to the preprocessor, but it deal with constexpr. Just no=
w there is now statement and declaration repeater in the language. Only run=
time repeater is exist. And a new feature requires a new language construct=
.. <br></div></span></div></blockquote><div><br>If macros are a new language=
, as you claimed, then so is this. You&#39;re doing token pasting, token pa=
rsing. These #&lt;&gt; constructs are not merely an extension; they have <i=
></i>completely different rules from regular, statically-typed C++.<br></di=
v></div></blockquote><div>The preprocessor is part of the C++ language and =
it is a textual tool. What I want is a little bit similar but in a non-text=
ual form. It will be much safer to use than the C++ preprocessor part. They=
 can work on declarations and statements. This lowering is needed for code =
generation. And I think my proposal doesn&#39;t hurt the statically-typed C=
++ concept.<br></div><div>=C2=A0<br>Again, in C++, every expression has a t=
ype that is known purely from the types of the components of that expressio=
n. In your meta-language, this is no longer the case.<br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D=
""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div>* Lacks any effective debugging (it&#39;s more debuggab=
le than macro programming, but still difficult to find errors with)<br></di=
v></div></blockquote><div>Why do you think that it lacks any &quot;effectiv=
e debugging&quot;? And why do think that &quot;difficult to find errors wit=
h&quot; it?</div></div></blockquote></span><div><br>Because you can&#39;t p=
ut a breakpoint on it and look at symbols. Take your #&lt;for&gt; construct=
.. That is a loop which must be unrolled. At compile-time. So, if I put a br=
eakpoint in that loop... where does it get hit? How can I inspect the &quot=
;variables&quot; that are nothing more than macros?<br></div></div></blockq=
uote><div>And do you think you can put a breakpoint to a variable declarati=
on or a constexpr expression? Constexpr is part of the language and it &quo=
t;runs&quot; in compile time. C++ is not runtime only.<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"><div dir=3D"l=
tr"><div><br>The #&lt;if&gt; condition. Those are compile-time conditions. =
So at compile time, the compiler will detect the condition and eliminate bo=
th the internals and the check itself if the condition fails. So... how do =
I put a break point on it and see which members are being tested against?<b=
r></div></div></blockquote><div>Breakpoints work in runtime not in compile =
time. But theoretically you can invent a compile time debugger. A constexpr=
 is basically a compile time interpreted C++.<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"><div dir=3D"ltr"><div>=
=C2=A0</div><span class=3D""><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div>For example without any extra effort you can simp=
ly call clang as<br>clang++ -cc1 -std=3Dc++1z -ast-print $FILE<br>or<br>cla=
ng++ -cc1 -std=3Dc++1z -ast-dump $FILE<br>And can check what was generated.=
<br></div></div></blockquote></span><div><br>You consider running a command=
-line tool and dumping an AST to be &quot;debuggable&quot;? You&#39;re basi=
cally saying that it&#39;s no easier to debug than macros. <br></div></div>=
</blockquote><div>The problem with macros is that they ruins the namespaces=
 and do everything textually. Textual macros &quot;invented&quot; somewhere=
 in the 1960s. It was just inherited from C.<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"><div dir=3D"ltr"><br><spa=
n 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 dir=3D"=
ltr"><div>I don&#39;t understand this part. Can you give me a detailed exam=
ple what you want to achieve with this construct?<br></div></div></blockquo=
te></span><div><br>I&#39;m not suggesting that as syntax. I&#39;m explainin=
g that C++ doesn&#39;t allow for <i>any</i> such construct, where different=
 executions of that statement can result in the creation of objects of vary=
ing types. Indeed, 90% of the complexity of TMP is working around the fact =
that C++ is statically typed.<br><br>So any modification to C++ to allow th=
at, like your macro syntax, is effectively changing the rules of C++ in a v=
ery significant way.<br></div></div></blockquote><div>I don&#39;t think so.=
 The language is evolving that&#39;s all.<br></div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=C2=A0</di=
v><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>What I really like to do with my proposal is an easy serial=
ization/deserialization and automactic generation of client/server RPC clas=
ses. Now I have to use external code generation tools for it.<br></div></di=
v></blockquote></span><div><br>In my experience, &quot;easy serialization&q=
uot; is not viable. Sooner or later, you are going to want to modify a clas=
s. Which means you need to be able to read the old format and the new.<br><=
br>At which point, most if not all of your automatic, reflection-based tech=
niques go out the window. Because now you need to write special-case code t=
o do the translation.</div></div></blockquote></div>No. Code generators can=
 be replaced with compile time code generators.<br></div><div class=3D"gmai=
l_extra"><br><br></div><div class=3D"gmail_extra">Peter<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 />

--e89a8ff25680416315051595b934--

.

--001a11c31f74da52660515961c81
Content-Type: text/plain; charset=UTF-8

On Fri, May 8, 2015 at 10:33 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> In my experience, "easy serialization" is not viable. Sooner or later, you
> are going to want to modify a class. Which means you need to be able to
> read the old format and the new.
>
> At which point, most if not all of your automatic, reflection-based
> techniques go out the window. Because now you need to write special-case
> code to do the translation.
>

I agree with pretty much everything that you've said except for this. I've
written a good deal of preprocessor-based reflection facilities, similar to
Boost.Fusion-adapted structs but with both template and preprocessor
introspection facilities. You still can get benefits of reflection for
serialization of your aggregate types as they evolve even if you need
backwards compatibility. One way you can do this is by preserving your type
history in the files. In other words, if version 2 adds in a new member at
the end, you use reflection to say that this new type has all of the
members of the old one, followed by an additional one (often with an
explicit default value). Sort of like inheritance. You can imagine a
similar operation for "removing" members in a later version by pulling in
all of the old members, only filtered, and ignoring filtered members during
deserialization, though I admittedly never implemented this as the need
hasn't come up.

The main problem with this is that it's difficult for users to see the type
all in one place, though because of introspection, you'd also have the
ability to do traditional code generation as well fairly easily, even if
you're just generating simple docs to describe the type in a way that looks
exactly like a regular struct, which is all that it really is anyway.

Aside from that, even without versioning, reflection-based serialization
and deserialization has its uses. For instance, when serializing for
communication between local processes running on the same machine (and
generally coming from the same exact build), your versions are guaranteed
to be in sync so no versioning is required. Serialization there is just an
artifact of IPC and it is a perfect match for reflection-based
serialization.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 8, 2015 at 10:33 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>In my exper=
ience, &quot;easy serialization&quot; is not viable. Sooner or later, you a=
re going to want to modify a class. Which means you need to be able to read=
 the old format and the new.<br><br>At which point, most if not all of your=
 automatic, reflection-based techniques go out the window. Because now you =
need to write special-case code to do the translation.</div></div></blockqu=
ote><div><br></div><div>I agree with pretty much everything that you&#39;ve=
 said except for this. I&#39;ve written a good deal of preprocessor-based r=
eflection facilities, similar to Boost.Fusion-adapted structs but with both=
 template and preprocessor introspection facilities. You still can get bene=
fits of reflection for serialization of your aggregate types as they evolve=
 even if you need backwards compatibility. One way you can do this is by pr=
eserving your type history in the files. In other words, if version 2 adds =
in a new member at the end, you use reflection to say that this new type ha=
s all of the members of the old one, followed by an additional one (often w=
ith an explicit default value). Sort of like inheritance. You can imagine a=
 similar operation for &quot;removing&quot; members in a later version by p=
ulling in all of the old members, only filtered, and ignoring filtered memb=
ers during deserialization, though I admittedly never implemented this as t=
he need hasn&#39;t come up.</div><div><br></div><div>The main problem with =
this is that it&#39;s difficult for users to see the type all in one place,=
 though because of introspection, you&#39;d also have the ability to do tra=
ditional code generation as well fairly easily, even if you&#39;re just gen=
erating simple docs to describe the type in a way that looks exactly like a=
 regular struct, which is all that it really is anyway.</div><div><br></div=
><div>Aside from that, even without versioning, reflection-based serializat=
ion and deserialization has its uses. For instance, when serializing for co=
mmunication between local processes running on the same machine (and genera=
lly coming from the same exact build), your versions are guaranteed to be i=
n sync so no versioning is required. Serialization there is just an artifac=
t of IPC and it is a perfect match for reflection-based serialization.</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 />

--001a11c31f74da52660515961c81--

.

------=_Part_2617_380238060.1431123601435
Content-Type: multipart/alternative;
 boundary="----=_Part_2618_1897224595.1431123601435"

------=_Part_2618_1897224595.1431123601435
Content-Type: text/plain; charset=UTF-8



On Friday, May 8, 2015 at 12:31:35 PM UTC+3, Nicol Bolas wrote:
>
> On Friday, May 8, 2015 at 4:02:10 AM UTC-4, snk_kid wrote:
>>
>> I sent a message very similar to yours. My idea was to expand on
>> constexpr functions since these already give you compile-time functions,
>> just to need add support for quoting, splicing, "emitting" code, (hygienic)
>> name generation, a standardized AST/reflection library, etc.
>>
>
> ... these are not "just" things to add. You seem to underestimate the
> complexity of such functionality, particularly from a conceptual
> perspective.
>
> Here's my favorite example of a basic sanity check for any compile-time
> reflection proposal: how much code do I need to write in order to, given
> some object reference `obj`, go through all of the non-static data members
> of `obj`'s (static) type and call a particular function for each member,
> passing that member's value as a parameter?
>
> Best case, this should be no more than three lines (of pseudo-code):
>
> auto MemberDescriptionList = GetMemberIterator(decltype(obj));
> SomeLoop(MemberDescription &desc = ...)
>   Function(AccessMember(obj, desc));
>

Almost 3 lines, if you take comments and surrounding function

template<typename T, typename Functor>
void apply(T&& t, Functor&& func)
{
  [[macro]]
  {
    for (auto m: T.members()) // enumerate all type members
      // check that our member isn't static and that it's a field
      if (!m.is_static() && m.is_field())
        emit ${ func(t.$m); }; // emit func invocation
  }
}




>
> That cannot be a function (constexpr or not) of any kind under the rules
> of C++. The problem is that C++ is statically typed. And every expression
> must have a single, well-defined type. The return type of `AccessMember`
> will have to be different, based on the contents of `desc`. But you can't
> vary the return type of a function based on the *contents* of a
> parameter. That's a hard-and-fast rule of C++.
>

I think you're missing one very important point. Types, declarations, etc.
are just AST elements at some point of compilation. And AST is just a data
processed by some program, compiler in our case. So type from within a
program becomes a descriptor, which lists its elements.
So the idea is to allow programmers to influence the way AST is processed.
By adding mini-pieces of code which are run by compiler as some kind of
mini-plugins.


>
> Template metaprogramming side-steps this rule via recursion.
> `MemberDescriptionList` would be a class that has a variadic template
> argument list. Each argument would be some `MemberDescription<T>`, with `T`
> being the type of the argument. And therefore, you can have an
> `AccessMember` that takes a `MemberDescription<T>` and returns a `T&` or
> `const T&`. And you walk the list via recursively calling the function, as
> with standard practice for variadic templates.
>
> You can't break this rule without rewriting some of the most fundamental
> rules of C++. At which point, your criticism of template metaprogramming
> becomes rather ironic. Because however much you may want to think of what
> you're suggesting as "just" a `constexpr` function, it will have to operate
> under rules so alien to C++ that it will be as different from regular
> runtime C++ as template metaprogramming is.
>
> Take the OP's suggestion. It's basically a second macro language. Because
> the first one worked out so well. It may look a bit like C++, but so does
> template metaprogrmaming. And to be honest, TMP behaves more like regular
> C++ than this macro language.
>

If we wanna real compile-time reflection, we need to implement it in its
domain. Full-fledged reflection means working with types, expressions etc.
as a kind of data. TMP on the other hand is designed to work with types, in
the way of a very limited pure functional language. Using integrals and
constexpr pointers is more like to side effect.


>
>
>>
>>    - No debugging support and probably non-trivial to add such a thing.
>>
>>
> I fail to see how the proposed macro-style solution will be any easier to
> debug. At least with concepts, TMP will be a lot easier to catch errors in.
> Also, TMP is still nominally C++, so it works under the same rules.
>
>>
>>    - Adding more features to templates for the sake of meta-programming
>>    just makes templates even more complex than they already are for everyone
>>    (users & compiler vendors), it's gaining to many responsibilities,
>>    templates should just focus on one thing what they originally designed to
>>    be used for that is parametric polymorphism.
>>
>>
> I admit that I haven't gone in depth with any of the reflection proposals.
> But I didn't think that they were adding features to *templates*
> specifically. I thought the various reflection features were simply
> designed to work with existing metaprogramming facilities. That is,
> reflection functionality returns metafunctions, tuples, or classes
> containing variadic template parameter packs of types and so forth.
>

Please describe how I can check nowadays that a type passed in is a
variadic template function.


>
> What language features, which makes templates "even more complex than they
> already are," have been suggested for addition?
>

I think it's because compiler maintainers will need to introduce another
bunch of magic attributes/extensions/intrinsics to retrieve list of members
for arbitrary type T. Let's have even more internal magic!


> Also, I fail to see how introducing a second macro language (third if you
> count templates as a limited, type-checked, macro language) makes the
> language less complex.
>
> It doesn't, for sure
Though
* Macro language is a simple sed/awk search and replace.
* Templates were meant to generalize collections over arbitrary types.
Personally I think that adding non-type template parameters was a second
billion-dollar mistake.

It's like we need a set of wrenches to dismantle something properly. But
instead we have only a hammer and a screwdriver.

--

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

<div dir=3D"ltr"><br><br>On Friday, May 8, 2015 at 12:31:35 PM UTC+3, Nicol=
 Bolas wrote:<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">=
On Friday, May 8, 2015 at 4:02:10 AM UTC-4, snk_kid wrote:<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">I sent a message very similar to yo=
urs. My idea was to expand on constexpr functions since these already give =
you compile-time functions, just to need add support for quoting, splicing,=
 "emitting" code, (hygienic) name generation, a standardized AST/reflection=
 library, etc.<br></div></blockquote><div><br>... these are not "just" thin=
gs to add. You seem to underestimate the complexity of such functionality, =
particularly from a conceptual perspective.<br><br>Here's my favorite examp=
le of a basic sanity check for any compile-time reflection proposal: how mu=
ch code do I need to write in order to, given some object reference `obj`, =
go through all of the non-static data members of `obj`'s (static) type and =
call a particular function for each member, passing that member's value as =
a parameter?<br><br>Best case, this should be no more than three lines (of =
pseudo-code):<br><br>auto MemberDescriptionList =3D GetMemberIterator(declt=
ype(<wbr>obj));<br>SomeLoop(MemberDescription &amp;desc =3D ...)<br>&nbsp; =
Function(AccessMember(obj, desc));<br></div></div></blockquote><div><br>Alm=
ost 3 lines, if you take comments and surrounding function<br><br><div clas=
s=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">template</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Functor</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">void<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> apply</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> t</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Functor</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> func</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">macro</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">]]</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> m</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">members</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">())</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">// enumerate all type members</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// check t=
hat our member isn't static and that it's a field</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(!</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">m</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">is_static</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> m</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">is_field</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">())</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; =
emit $</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> func</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">t</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">$m</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// emit fu=
nc invocation</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>&nbsp; </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div=
></code></div><br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div><br>That cannot be a function (constexpr or not) of a=
ny kind under the rules of C++. The problem is that C++ is statically typed=
.. And every expression must have a single, well-defined type. The return ty=
pe of `AccessMember` will have to be different, based on the contents of `d=
esc`. But you can't vary the return type of a function based on the <i>cont=
ents</i> of a parameter. That's a hard-and-fast rule of C++.<br></div></div=
></blockquote><div><br>I think you're missing one very important point. Typ=
es, declarations, etc. are just AST elements at some point of compilation. =
And AST is just a data processed by some program, compiler in our case. So =
type from within a program becomes a descriptor, which lists its elements.<=
br>So the idea is to allow programmers to influence the way AST is processe=
d. By adding mini-pieces of code which are run by compiler as some kind of =
mini-plugins.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><br>Template metaprogramming side-steps this rule via =
recursion. `MemberDescriptionList` would be a class that has a variadic tem=
plate argument list. Each argument would be some `MemberDescription&lt;T&gt=
;`, with `T` being the type of the argument. And therefore, you can have an=
 `AccessMember` that takes a `MemberDescription&lt;T&gt;` and returns a `T&=
amp;` or `const T&amp;`. And you walk the list via recursively calling the =
function, as with standard practice for variadic templates.<br><br>You can'=
t break this rule without rewriting some of the most fundamental rules of C=
++. At which point, your criticism of template metaprogramming becomes rath=
er ironic. Because however much you may want to think of what you're sugges=
ting as "just" a `constexpr` function, it will have to operate under rules =
so alien to C++ that it will be as different from regular runtime C++ as te=
mplate metaprogramming is.<br><br>Take the OP's suggestion. It's basically =
a second macro language. Because the first one worked out so well. It may l=
ook a bit like C++, but so does template metaprogrmaming. And to be honest,=
 TMP behaves more like regular C++ than this macro language.<br></div></div=
></blockquote><div><br>If we wanna real compile-time reflection, we need to=
 implement it in its domain. Full-fledged reflection means working with typ=
es, expressions etc. as a kind of data. TMP on the other hand is designed t=
o work with types, in the way of a very limited pure functional language. U=
sing integrals and constexpr pointers is more like to side effect.<br>&nbsp=
;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><d=
iv>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><ul=
><li>No debugging support and probably non-trivial to add such a thing.<br>=
</li></ul></div></blockquote><div><br>I fail to see how the proposed macro-=
style solution will be any easier to debug. At least with concepts, TMP wil=
l be a lot easier to catch errors in. Also, TMP is still nominally C++, so =
it works under the same rules. <br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><ul><li>Adding more features to templates for the sa=
ke of meta-programming just makes templates even more complex than they alr=
eady are for everyone (users &amp; compiler vendors), it's gaining to many =
responsibilities, templates should just focus on one thing what they origin=
ally designed to be used for that is parametric polymorphism.<br></li></ul>=
</div></blockquote><div><br>I admit that I haven't gone in depth with any o=
f the reflection proposals. But I didn't think that they were adding featur=
es to <i>templates</i> specifically. I thought the various reflection featu=
res were simply designed to work with existing metaprogramming facilities. =
That is, reflection functionality returns metafunctions, tuples, or classes=
 containing variadic template parameter packs of types and so forth.<br></d=
iv></div></blockquote><div><br>Please describe how I can check nowadays tha=
t a type passed in is a variadic template function.<br>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>What languag=
e features, which makes templates "even more complex than they already are,=
" have been suggested for addition?<br></div></div></blockquote><div><br>I =
think it's because compiler maintainers will need to introduce another bunc=
h of magic attributes/extensions/intrinsics to retrieve list of members for=
 arbitrary type T. Let's have even more internal magic!<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>Also, I fa=
il to see how introducing a second macro language (third if you count templ=
ates as a limited, type-checked, macro language) makes the language less co=
mplex.</div><br></div></blockquote><div>It doesn't, for sure<br>Though<br>*=
 Macro language is a simple sed/awk search and replace.<br>* Templates were=
 meant to generalize collections over arbitrary types. Personally I think t=
hat adding non-type template parameters was a second billion-dollar mistake=
..<br><br>It's like we need a set of wrenches to dismantle something properl=
y. But instead we have only a hammer and a screwdriver. <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_2618_1897224595.1431123601435--
------=_Part_2617_380238060.1431123601435--

.

------=_Part_2980_1201395474.1431124469706
Content-Type: multipart/alternative;
 boundary="----=_Part_2981_1212482424.1431124469706"

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



On Friday, May 8, 2015 at 1:54:47 PM UTC-4, P=C3=A9ter N=C3=A9meth wrote:
>
> =20
>
>> =20
>>>
>>>> * Lacks any effective debugging (it's more debuggable than macro=20
>>>> programming, but still difficult to find errors with)
>>>>
>>> Why do you think that it lacks any "effective debugging"? And why do=20
>>> think that "difficult to find errors with" it?
>>>
>>
>> Because you can't put a breakpoint on it and look at symbols. Take your=
=20
>> #<for> construct. That is a loop which must be unrolled. At compile-time=
..=20
>> So, if I put a breakpoint in that loop... where does it get hit? How can=
 I=20
>> inspect the "variables" that are nothing more than macros?
>>
> And do you think you can put a breakpoint to a variable declaration or a=
=20
> constexpr expression? Constexpr is part of the language and it "runs" in=
=20
> compile time. C++ is not runtime only.
>

You're arguing my point for me. The original statement was that doing=20
reflection via TMP was bad because TMP is hard to debug. This suggested=20
feature has the exact same debugging problems that TMP does.

Indeed, I would argue that it's easier to debug. When I put a breakpoint in=
=20
a TMP recursive call, I can at least see what types are involved. I can=20
look at the call stack and see where I am in the loop.

I recognize that reflection, particularly code-generation-based reflection=
=20
mechanics, will be difficult to debug. But this will be no less true via=20
this macro mechanism than via TMP.

The same goes for many of the rest of the reasons that TMP is ostensibly=20
bad for reflection: macro-style syntax will in many cases be no better than=
=20
TMP-style reflection.

I don't understand this part. Can you give me a detailed example what you=
=20
>>> want to achieve with this construct?
>>>
>>
>> I'm not suggesting that as syntax. I'm explaining that C++ doesn't allow=
=20
>> for *any* such construct, where different executions of that statement=
=20
>> can result in the creation of objects of varying types. Indeed, 90% of t=
he=20
>> complexity of TMP is working around the fact that C++ is statically type=
d.
>>
>> So any modification to C++ to allow that, like your macro syntax, is=20
>> effectively changing the rules of C++ in a very significant way.
>>
> I don't think so. The language is evolving that's all.
>

Whatever word you choose to describe it is irrelevant. You're talking about=
=20
compile-time mechanisms, and those require a lot from the user. As well as=
=20
tools.

And thus, the original statement I was responding to (that TMP is only used=
=20
by a small number of programmers) applies just as much to this new syntax,=
=20
because it operates in a very different way from regular C++. It may not be=
=20
functional programming, but it is different. And that difference is going=
=20
to make many C++ programmers leery of using it.

Just like TMP.

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

<div dir=3D"ltr"><br><br>On Friday, May 8, 2015 at 1:54:47 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: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr">&nbsp;<div><div class=3D"gmail_quote"><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"><span><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>&nbsp;</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>* Lacks any effectiv=
e debugging (it's more debuggable than macro programming, but still difficu=
lt to find errors with)<br></div></div></blockquote><div>Why do you think t=
hat it lacks any "effective debugging"? And why do think that "difficult to=
 find errors with" it?</div></div></blockquote></span><div><br>Because you =
can't put a breakpoint on it and look at symbols. Take your #&lt;for&gt; co=
nstruct. That is a loop which must be unrolled. At compile-time. So, if I p=
ut a breakpoint in that loop... where does it get hit? How can I inspect th=
e "variables" that are nothing more than macros?<br></div></div></blockquot=
e><div>And do you think you can put a breakpoint to a variable declaration =
or a constexpr expression? Constexpr is part of the language and it "runs" =
in compile time. C++ is not runtime only.<br></div></div></div></div></bloc=
kquote><div><br>You're arguing my point for me. The original statement was =
that doing reflection via TMP was bad because TMP is hard to debug. This su=
ggested feature has the exact same debugging problems that TMP does.<br><br=
>Indeed, I would argue that it's easier to debug. When I put a breakpoint i=
n a TMP recursive call, I can at least see what types are involved. I can l=
ook at the call stack and see where I am in the loop.<br><br>I recognize th=
at reflection, particularly code-generation-based reflection mechanics, wil=
l be difficult to debug. But this will be no less true via this macro mecha=
nism than via TMP.<br><br>The same goes for many of the rest of the reasons=
 that TMP is ostensibly bad for reflection: macro-style syntax will in many=
 cases be no better than TMP-style reflection.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quo=
te"><div></div><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"><span><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><div>I don't understand this part. Can you give me a detail=
ed example what you want to achieve with this construct?<br></div></div></b=
lockquote></span><div><br>I'm not suggesting that as syntax. I'm explaining=
 that C++ doesn't allow for <i>any</i> such construct, where different exec=
utions of that statement can result in the creation of objects of varying t=
ypes. Indeed, 90% of the complexity of TMP is working around the fact that =
C++ is statically typed.<br><br>So any modification to C++ to allow that, l=
ike your macro syntax, is effectively changing the rules of C++ in a very s=
ignificant way.<br></div></div></blockquote><div>I don't think so. The lang=
uage is evolving that's all.<br></div></div></div></div></blockquote><div><=
br>Whatever word you choose to describe it is irrelevant. You're talking ab=
out compile-time mechanisms, and those require a lot from the user. As well=
 as tools.<br><br>And thus, the original statement I was responding to (tha=
t TMP is only used by a small number of programmers) applies just as much t=
o this new syntax, because it operates in a very different way from regular=
 C++. It may not be functional programming, but it is different. And that d=
ifference is going to make many C++ programmers leery of using it.<br><br>J=
ust like TMP.<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_2981_1212482424.1431124469706--
------=_Part_2980_1201395474.1431124469706--

.

------=_Part_2929_907063893.1431127224048
Content-Type: multipart/alternative;
 boundary="----=_Part_2930_36439598.1431127224048"

------=_Part_2930_36439598.1431127224048
Content-Type: text/plain; charset=UTF-8



On Friday, May 8, 2015 at 6:20:01 PM UTC-4, Igor Baidiuk wrote:
>
> On Friday, May 8, 2015 at 12:31:35 PM UTC+3, Nicol Bolas wrote:
>
>> That cannot be a function (constexpr or not) of any kind under the rules
>> of C++. The problem is that C++ is statically typed. And every expression
>> must have a single, well-defined type. The return type of `AccessMember`
>> will have to be different, based on the contents of `desc`. But you can't
>> vary the return type of a function based on the *contents* of a
>> parameter. That's a hard-and-fast rule of C++.
>>
>
> I think you're missing one very important point. Types, declarations, etc.
> are just AST elements at some point of compilation. And AST is just a data
> processed by some program, compiler in our case. So type from within a
> program becomes a descriptor, which lists its elements.
> So the idea is to allow programmers to influence the way AST is processed.
> By adding mini-pieces of code which are run by compiler as some kind of
> mini-plugins.
>

I don't see the part of the C++ stnadard that formalizes this notion of an
AST. So, you can't really describe this concept as modifying something that
is an implementation detail.

Oh sure, we all know what this stuff means. But the standard doesn't.

More importantly, I don't feel we need that level of access or manipulation
to make compile-time reflection worthwhile.

Template metaprogramming side-steps this rule via recursion.
>> `MemberDescriptionList` would be a class that has a variadic template
>> argument list. Each argument would be some `MemberDescription<T>`, with `T`
>> being the type of the argument. And therefore, you can have an
>> `AccessMember` that takes a `MemberDescription<T>` and returns a `T&` or
>> `const T&`. And you walk the list via recursively calling the function, as
>> with standard practice for variadic templates.
>>
>> You can't break this rule without rewriting some of the most fundamental
>> rules of C++. At which point, your criticism of template metaprogramming
>> becomes rather ironic. Because however much you may want to think of what
>> you're suggesting as "just" a `constexpr` function, it will have to operate
>> under rules so alien to C++ that it will be as different from regular
>> runtime C++ as template metaprogramming is.
>>
>> Take the OP's suggestion. It's basically a second macro language. Because
>> the first one worked out so well. It may look a bit like C++, but so does
>> template metaprogrmaming. And to be honest, TMP behaves more like regular
>> C++ than this macro language.
>>
>
> If we wanna real compile-time reflection, we need to implement it in its
> domain. Full-fledged reflection means working with types, expressions etc.
> as a kind of data. TMP on the other hand is designed to work with types, in
> the way of a very limited pure functional language. Using integrals and
> constexpr pointers is more like to side effect.
>

It depends on how much compile-time reflection you're talking about.

The most basic level of compile-time reflection is accessing what the
compiler knows about a particular type. Being able to introspect what
members of a type are, where it is defined, etc.

This is something that requires no expression manipulation. It could be
done purely with TMP, plus a way to ask for the type/member data.

Above that is more active reflection: the ability to use the information
acquired above to access data. The ability not merely to introspect the
members, but to construct types based only on a compile-time type
description. To access members of an instance based on the member
descriptor of that member.

This requires a bit more functionality, and TMP is really not specifically
involved with it. It's more about compiler "functions" that can convert, at
compile-time, type or member descriptors into actual types and members.

The highest level of compile-time reflection is the ability to *generate*
elements of a type, and/or new types arbitrarily.

It's that last level that requires lots of heavy syntax that TMP + a few
intrinsics can't (reasonably) provide. That's where you want to "work with
.... expressions".


>>>    - No debugging support and probably non-trivial to add such a thing.
>>>
>>>
>> I fail to see how the proposed macro-style solution will be any easier to
>> debug. At least with concepts, TMP will be a lot easier to catch errors in.
>> Also, TMP is still nominally C++, so it works under the same rules.
>>
>>>
>>>    - Adding more features to templates for the sake of meta-programming
>>>    just makes templates even more complex than they already are for everyone
>>>    (users & compiler vendors), it's gaining to many responsibilities,
>>>    templates should just focus on one thing what they originally designed to
>>>    be used for that is parametric polymorphism.
>>>
>>>
>> I admit that I haven't gone in depth with any of the reflection
>> proposals. But I didn't think that they were adding features to
>> *templates* specifically. I thought the various reflection features were
>> simply designed to work with existing metaprogramming facilities. That is,
>> reflection functionality returns metafunctions, tuples, or classes
>> containing variadic template parameter packs of types and so forth.
>>
>
> Please describe how I can check nowadays that a type passed in is a
> variadic template function.
>

"Nowadays"? You'd probably use some horrible std::enable_if thing.

"Eventually"? You'd use a concept. An appropriate concept could easily be
provided by the reflection facilities.


> What language features, which makes templates "even more complex than they
>> already are," have been suggested for addition?
>>
>
> I think it's because compiler maintainers will need to introduce another
> bunch of magic attributes/extensions/intrinsics to retrieve list of members
> for arbitrary type T. Let's have even more internal magic!
>

You say that as though `T.members()` will somehow not be "internal magic".

Also, I fail to see how introducing a second macro language (third if you
>> count templates as a limited, type-checked, macro language) makes the
>> language less complex.
>>
>> It doesn't, for sure
> Though
> * Macro language is a simple sed/awk search and replace.
> * Templates were meant to generalize collections over arbitrary types.
> Personally I think that adding non-type template parameters was a second
> billion-dollar mistake.
>

Given the fruits of metaprogramming, I'd love to make that kind of
"mistake" ;)

Also, templates were not created for STL. They were created as an
alternative to macros, so that we could have a method to generalize a
concept over a type, without having type-unsafe elements like macros.
Instead of writing and calling a macro function, you write a template
function.

Lastly, non-type template parameters aren't a huge part of TMP. They're
useful to be sure, but hardly essential for the concept.

--

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

<div dir=3D"ltr"><br><br>On Friday, May 8, 2015 at 6:20:01 PM UTC-4, Igor B=
aidiuk wrote:<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">=
On Friday, May 8, 2015 at 12:31:35 PM UTC+3, Nicol Bolas wrote:<br><blockqu=
ote 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>That cannot be a func=
tion (constexpr or not) of any kind under the rules of C++. The problem is =
that C++ is statically typed. And every expression must have a single, well=
-defined type. The return type of `AccessMember` will have to be different,=
 based on the contents of `desc`. But you can't vary the return type of a f=
unction based on the <i>contents</i> of a parameter. That's a hard-and-fast=
 rule of C++.<br></div></div></blockquote><div><br>I think you're missing o=
ne very important point. Types, declarations, etc. are just AST elements at=
 some point of compilation. And AST is just a data processed by some progra=
m, compiler in our case. So type from within a program becomes a descriptor=
, which lists its elements.<br>So the idea is to allow programmers to influ=
ence the way AST is processed. By adding mini-pieces of code which are run =
by compiler as some kind of mini-plugins.<br></div></div></blockquote><div>=
<br>I don't see the part of the C++ stnadard that formalizes this notion of=
 an AST. So, you can't really describe this concept as modifying something =
that is an implementation detail.<br><br>Oh sure, we all know what this stu=
ff means. But the standard doesn't.<br><br>More importantly, I don't feel w=
e need that level of access or manipulation to make compile-time reflection=
 worthwhile.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
Template metaprogramming side-steps this rule via recursion. `MemberDescrip=
tionList` would be a class that has a variadic template argument list. Each=
 argument would be some `MemberDescription&lt;T&gt;`, with `T` being the ty=
pe of the argument. And therefore, you can have an `AccessMember` that take=
s a `MemberDescription&lt;T&gt;` and returns a `T&amp;` or `const T&amp;`. =
And you walk the list via recursively calling the function, as with standar=
d practice for variadic templates.<br><br>You can't break this rule without=
 rewriting some of the most fundamental rules of C++. At which point, your =
criticism of template metaprogramming becomes rather ironic. Because howeve=
r much you may want to think of what you're suggesting as "just" a `constex=
pr` function, it will have to operate under rules so alien to C++ that it w=
ill be as different from regular runtime C++ as template metaprogramming is=
..<br><br>Take the OP's suggestion. It's basically a second macro language. =
Because the first one worked out so well. It may look a bit like C++, but s=
o does template metaprogrmaming. And to be honest, TMP behaves more like re=
gular C++ than this macro language.<br></div></div></blockquote><div><br>If=
 we wanna real compile-time reflection, we need to implement it in its doma=
in. Full-fledged reflection means working with types, expressions etc. as a=
 kind of data. TMP on the other hand is designed to work with types, in the=
 way of a very limited pure functional language. Using integrals and conste=
xpr pointers is more like to side effect.<br></div></div></blockquote><div>=
<br>It depends on how much compile-time reflection you're talking about.<br=
><br>The most basic level of compile-time reflection is accessing what the =
compiler knows about a particular type. Being able to introspect what membe=
rs of a type are, where it is defined, etc.<br><br>This is something that r=
equires no expression manipulation. It could be done purely with TMP, plus =
a way to ask for the type/member data.<br><br>Above that is more active ref=
lection: the ability to use the information acquired above to access data. =
The ability not merely to introspect the members, but to construct types ba=
sed only on a compile-time type description. To access members of an instan=
ce based on the member descriptor of that member.<br><br>This requires a bi=
t more functionality, and TMP is really not specifically involved with it. =
It's more about compiler "functions" that can convert, at compile-time, typ=
e or member descriptors into actual types and members.<br><br>The highest l=
evel of compile-time reflection is the ability to <i>generate</i> elements =
of a type, and/or new types arbitrarily.<br><br>It's that last level that r=
equires lots of heavy syntax that TMP + a few intrinsics can't (reasonably)=
 provide. That's where you want to "work with ... expressions".<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><ul><li>No debugging support and probably non-t=
rivial to add such a thing.<br></li></ul></div></blockquote><div><br>I fail=
 to see how the proposed macro-style solution will be any easier to debug. =
At least with concepts, TMP will be a lot easier to catch errors in. Also, =
TMP is still nominally C++, so it works under the same rules. <br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><ul><li>Adding more f=
eatures to templates for the sake of meta-programming just makes templates =
even more complex than they already are for everyone (users &amp; compiler =
vendors), it's gaining to many responsibilities, templates should just focu=
s on one thing what they originally designed to be used for that is paramet=
ric polymorphism.<br></li></ul></div></blockquote><div><br>I admit that I h=
aven't gone in depth with any of the reflection proposals. But I didn't thi=
nk that they were adding features to <i>templates</i> specifically. I thoug=
ht the various reflection features were simply designed to work with existi=
ng metaprogramming facilities. That is, reflection functionality returns me=
tafunctions, tuples, or classes containing variadic template parameter pack=
s of types and so forth.<br></div></div></blockquote><div>&nbsp;<br>Please =
describe how I can check nowadays that a type passed in is a variadic templ=
ate function.<br></div></div></blockquote><div><br>"Nowadays"? You'd probab=
ly use some horrible std::enable_if thing.<br><br>"Eventually"? You'd use a=
 concept. An appropriate concept could easily be provided by the reflection=
 facilities.<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><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"=
><div>What language features, which makes templates "even more complex than=
 they already are," have been suggested for addition?<br></div></div></bloc=
kquote><div><br>I think it's because compiler maintainers will need to intr=
oduce another bunch of magic attributes/extensions/<wbr>intrinsics to retri=
eve list of members for arbitrary type T. Let's have even more internal mag=
ic!<br></div></div></blockquote><div><br>You say that as though `T.members(=
)` will somehow not be "internal magic".<br><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>Also, I fail to see how introducing a second ma=
cro language (third if you count templates as a limited, type-checked, macr=
o language) makes the language less complex.</div><br></div></blockquote><d=
iv>It doesn't, for sure<br>Though<br>* Macro language is a simple sed/awk s=
earch and replace.<br>* Templates were meant to generalize collections over=
 arbitrary types. Personally I think that adding non-type template paramete=
rs was a second billion-dollar mistake.<br></div></div></blockquote><div><b=
r>Given the fruits of metaprogramming, I'd love to make that kind of "mista=
ke" ;)<br><br>Also, templates were not created for STL. They were created a=
s an alternative to macros, so that we could have a method to generalize a =
concept over a type, without having type-unsafe elements like macros. Inste=
ad of writing and calling a macro function, you write a template function.<=
br><br>Lastly, non-type template parameters aren't a huge part of TMP. They=
're useful to be sure, but hardly essential for the concept.</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_2930_36439598.1431127224048--
------=_Part_2929_907063893.1431127224048--

.

--90e6ba2125012ea0f205159ab0e0
Content-Type: text/plain; charset=UTF-8

On Fri, May 8, 2015 at 4:20 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> "Nowadays"? You'd probably use some horrible std::enable_if thing.
>

You can't do that with enable_if nowadays. I don't think there is a valid
way to do it at all in the language currently.


> "Eventually"? You'd use a concept. An appropriate concept could easily be
> provided by the reflection facilities.
>

AFAIK, neither concepts-lite nor C++0x concepts can do exactly that.


> Given the fruits of metaprogramming, I'd love to make that kind of
> "mistake" ;)
>

+1

I'd also not exactly call it a "mistake." That makes it sound like we
accidentally got it because of poor specification of templates. The ability
to use templates for metaprogramming is a necessary side-effect of having a
template facility that is capable of everything that is done in the STL and
other generic libraries. Even if we had concepts from the start doing most
of the hairy work, and unconstrained templates themselves were less
powerful on their own, all that would have happened is that concepts would
have been the thing that could be used for metaprogramming rather than
templates.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 8, 2015 at 4:20 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>&quot;Nowada=
ys&quot;? You&#39;d probably use some horrible std::enable_if thing.<br></d=
iv></div></blockquote><div><br></div><div>You can&#39;t do that with enable=
_if nowadays. I don&#39;t think there is a valid way to do it at all in the=
 language currently.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>&quot;Eventually&quot;? You&#39;d use a concept. An ap=
propriate concept could easily be provided by the reflection facilities.<br=
></div></div></blockquote><div><br></div><div>AFAIK, neither concepts-lite =
nor C++0x concepts can do exactly that.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div>Given the fruits of metaprogramming=
, I&#39;d love to make that kind of &quot;mistake&quot; ;)</div></div></blo=
ckquote><div><br></div><div>+1</div><div><br></div><div>I&#39;d also not ex=
actly call it a &quot;mistake.&quot; That makes it sound like we accidental=
ly got it because of poor specification of templates. The ability to use te=
mplates for metaprogramming is a necessary side-effect of having a template=
 facility that is capable of everything that is done in the STL and other g=
eneric libraries. Even if we had concepts from the start doing most of the =
hairy work, and unconstrained templates themselves were less powerful on th=
eir own, all that would have happened is that concepts would have been the =
thing that could be used for metaprogramming rather than templates.</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 />

--90e6ba2125012ea0f205159ab0e0--

.

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

2015-05-09 0:34 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:

>
>
> On Friday, May 8, 2015 at 1:54:47 PM UTC-4, P=C3=A9ter N=C3=A9meth wrote:
>>
>>
>>
>>>
>>>>
>>>>> * Lacks any effective debugging (it's more debuggable than macro
>>>>> programming, but still difficult to find errors with)
>>>>>
>>>> Why do you think that it lacks any "effective debugging"? And why do
>>>> think that "difficult to find errors with" it?
>>>>
>>>
>>> Because you can't put a breakpoint on it and look at symbols. Take your
>>> #<for> construct. That is a loop which must be unrolled. At compile-tim=
e.
>>> So, if I put a breakpoint in that loop... where does it get hit? How ca=
n I
>>> inspect the "variables" that are nothing more than macros?
>>>
>> And do you think you can put a breakpoint to a variable declaration or a
>> constexpr expression? Constexpr is part of the language and it "runs" in
>> compile time. C++ is not runtime only.
>>
>
> You're arguing my point for me. The original statement was that doing
> reflection via TMP was bad because TMP is hard to debug. This suggested
> feature has the exact same debugging problems that TMP does.
>
> Indeed, I would argue that it's easier to debug. When I put a breakpoint
> in a TMP recursive call, I can at least see what types are involved. I ca=
n
> look at the call stack and see where I am in the loop.
>
> I recognize that reflection, particularly code-generation-based reflectio=
n
> mechanics, will be difficult to debug. But this will be no less true via
> this macro mechanism than via TMP.
>
> The same goes for many of the rest of the reasons that TMP is ostensibly
> bad for reflection: macro-style syntax will in many cases be no better th=
an
> TMP-style reflection.
>

Debugging a TMP program is a hard thing. I created DEBUG macros for me but
it has significant cognitive overhead.

#define DEBUG_TYPE(x) do { typedef void(*T)x; debug_type<T>(T(), #x); }
while(0)

template<typename T>
struct debug_type
{
    template<typename U>
    debug_type(void(*)(U), const std::string& p_str)
    {
        std::string str(p_str.begin() + 1, p_str.end() - 1);
        std::cout << str << " =3D> ";
        int status;
        char* name =3D abi::__cxa_demangle(typeid(U).name(), 0, 0, &status)=
;
        std::cout << name << std::endl;
        free(name);
    }
};

DEBUG_TYPE((if_c<true, true_, false_>::type));

which prints
if_c<true, true_, false_>::type =3D> bool_<true>

You have to think in function calls always. And you have to think in
type-wrapped-values and boost::mpl is not even standardized.

On the other hand a simple #<for> (item : items) #</for> is just a
declaration and statement repeater and work in the same way as a normal for
cycle.

And you can write unit test cases for your reflection based code parts. For
example

class Test
{
   #<for> (member : typeid<ClassA>.members())
      int #<id>member.name()#</id>;
  #</for>
};

// unit tests
static_assert(typid<Test>.members().size() =3D=3D 6);
....

Or you can examine in runtime the whole ast is you want. And you can easily
transform your meta program to a run time one.
And TMP is just enough for compile time reflection an compile time for and
if is needed for code generation and compile time id generation is also a
must.



>
>
> Whatever word you choose to describe it is irrelevant. You're talking
> about compile-time mechanisms, and those require a lot from the user. As
> well as tools.
>
> And thus, the original statement I was responding to (that TMP is only
> used by a small number of programmers) applies just as much to this new
> syntax, because it operates in a very different way from regular C++. It
> may not be functional programming, but it is different. And that differen=
ce
> is going to make many C++ programmers leery of using it.
>
> Just like TMP.
>
I think my proposal has no cognitive overhead over normal for-cycle and
normal pre processor macro. TMP has a big cognitive overhead because it is
a functional programming sub-language with horrible syntax. C++ is not a
functional programming language.


Peter

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

--001a1135f85432bee90515a220fe
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-09 0:34 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.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><span class=3D""><br><br>On Friday, May 8, 2015 at 1:54:47 PM UTC-4, P=C3=
=A9ter N=C3=A9meth wrote:<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">=C2=A0<div><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"g=
mail_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><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>* Lacks any effe=
ctive debugging (it&#39;s more debuggable than macro programming, but still=
 difficult to find errors with)<br></div></div></blockquote><div>Why do you=
 think that it lacks any &quot;effective debugging&quot;? And why do think =
that &quot;difficult to find errors with&quot; it?</div></div></blockquote>=
</span><div><br>Because you can&#39;t put a breakpoint on it and look at sy=
mbols. Take your #&lt;for&gt; construct. That is a loop which must be unrol=
led. At compile-time. So, if I put a breakpoint in that loop... where does =
it get hit? How can I inspect the &quot;variables&quot; that are nothing mo=
re than macros?<br></div></div></blockquote><div>And do you think you can p=
ut a breakpoint to a variable declaration or a constexpr expression? Conste=
xpr is part of the language and it &quot;runs&quot; in compile time. C++ is=
 not runtime only.<br></div></div></div></div></blockquote></span><div><br>=
You&#39;re arguing my point for me. The original statement was that doing r=
eflection via TMP was bad because TMP is hard to debug. This suggested feat=
ure has the exact same debugging problems that TMP does.<br><br>Indeed, I w=
ould argue that it&#39;s easier to debug. When I put a breakpoint in a TMP =
recursive call, I can at least see what types are involved. I can look at t=
he call stack and see where I am in the loop.<br><br>I recognize that refle=
ction, particularly code-generation-based reflection mechanics, will be dif=
ficult to debug. But this will be no less true via this macro mechanism tha=
n via TMP.<br><br>The same goes for many of the rest of the reasons that TM=
P is ostensibly bad for reflection: macro-style syntax will in many cases b=
e no better than TMP-style reflection.<br></div></div></blockquote><div><br=
></div><div>Debugging a TMP program is a hard thing. I created DEBUG macros=
 for me but it has significant cognitive overhead.<br><span style=3D"font-f=
amily:monospace,monospace"><br>#define DEBUG_TYPE(x) do { typedef void(*T)x=
; debug_type&lt;T&gt;(T(), #x); } while(0)<br><br>template&lt;typename T&gt=
;<br>struct debug_type<br>{<br>=C2=A0 =C2=A0 template&lt;typename U&gt;<br>=
=C2=A0 =C2=A0 debug_type(void(*)(U), const std::string&amp; p_str)<br>=C2=
=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::string str(p_str.begin() +=
 1, p_str.end() - 1);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::cout &lt;&lt; str=
 &lt;&lt; &quot; =3D&gt; &quot;;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 int status;=
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 char* name =3D abi::__cxa_demangle(typeid(U=
).name(), 0, 0, &amp;status);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 std::cout &lt;=
&lt; name &lt;&lt; std::endl;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 free(name);<br=
>=C2=A0 =C2=A0 }<br>};</span><br><br></div><div>DEBUG_TYPE((if_c&lt;true, t=
rue_, false_&gt;::type));<br><br></div><div>which prints<br><span style=3D"=
font-family:monospace,monospace">if_c&lt;true, true_, false_&gt;::type =3D&=
gt; bool_&lt;true&gt;</span><br><br></div><div>You have to think in functio=
n calls always. And you have to think in type-wrapped-values and boost::mpl=
 is not even standardized.<br><br></div><div>On the other hand a simple #&l=
t;for&gt; (item : items) #&lt;/for&gt; is just a declaration and statement =
repeater and work in the same way as a normal for cycle.<br><br></div><div>=
And you can write unit test cases for your reflection based code parts. For=
 example<br><span style=3D"font-family:monospace,monospace"><br></span></di=
v><div><span style=3D"font-family:monospace,monospace">class Test<br>{<br><=
/span></div><div><span style=3D"font-family:monospace,monospace">=C2=A0=C2=
=A0 #&lt;for&gt; (member : typeid&lt;ClassA&gt;.members()) <br></span></div=
><div><span style=3D"font-family:monospace,monospace">=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 int #&lt;id&gt;<a href=3D"http://member.name">member.name</a>()#&=
lt;/id&gt;;</span></div><div><span style=3D"font-family:monospace,monospace=
">=C2=A0 #&lt;/for&gt;<br></span></div><div><span style=3D"font-family:mono=
space,monospace">};<br><br></span></div><div><span style=3D"font-family:mon=
ospace,monospace">// unit tests<br></span></div><div><span style=3D"font-fa=
mily:monospace,monospace">static_assert(typid&lt;Test&gt;.members().size() =
=3D=3D 6);<br>...</span><br><br></div><div>Or you can examine in runtime th=
e whole ast is you want. And you can easily transform your meta program to =
a run time one.<br></div><div>And TMP is just enough for compile time refle=
ction an compile time <span style=3D"font-family:monospace,monospace">for</=
span> and <span style=3D"font-family:monospace,monospace">if</span> is need=
ed for code generation and compile time id generation is also a must.<br></=
div><div><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"><br><div dir=3D"ltr"><br><div>Whatever word you choose to descri=
be it is irrelevant. You&#39;re talking about compile-time mechanisms, and =
those require a lot from the user. As well as tools.<br><br>And thus, the o=
riginal statement I was responding to (that TMP is only used by a small num=
ber of programmers) applies just as much to this new syntax, because it ope=
rates in a very different way from regular C++. It may not be functional pr=
ogramming, but it is different. And that difference is going to make many C=
++ programmers leery of using it. <br><br>Just like TMP.<br></div></div></b=
lockquote></div>I think my proposal has no cognitive overhead over normal f=
or-cycle and normal pre processor macro. TMP has a big cognitive overhead b=
ecause it is a functional programming sub-language with horrible syntax. C+=
+ is not a functional programming language.<br></div><div class=3D"gmail_ex=
tra"><br><br></div><div class=3D"gmail_extra">Peter<br></div><div class=3D"=
gmail_extra"><br></div></div>

<p></p>

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

--001a1135f85432bee90515a220fe--

.

------=_Part_104_242822264.1431164086169
Content-Type: multipart/alternative;
 boundary="----=_Part_105_894861748.1431164086169"

------=_Part_105_894861748.1431164086169
Content-Type: text/plain; charset=UTF-8



Almost 3 lines, if you take comments and surrounding function
>
> template<typename T, typename Functor>
> void apply(T&& t, Functor&& func)
> {
>   [[macro]]
>   {
>     for (auto m: T.members()) // enumerate all type members
>       // check that our member isn't static and that it's a field
>       if (!m.is_static() && m.is_field())
>         emit ${ func(t.$m); }; // emit func invocation
>   }
> }
>
>
>
>
So what you want here is that
  [[macro]] // a block which doesn't introduce a scope and it contains
constexprs
  {
     constexpr
     for (auto m: T.members()) // enumerate all type members
                  ^^ // this is your proposed syntax to get the ast
      if (!m.is_static() && m.is_field())
        emit // a block which doesn't introduce a scope and it contains
normal statements and declarations
        ${
             func(t.$m);
                    ^^ your proposed syntax to paste a token
        };
}

So you want two new kinds of block
1.

  [[macro]] // a block which doesn't introduce a scope and it contains
constexprs
  {
  }


2.
   emit
   ${
   }

I think they should use similar syntax for example:

[[constexpr]]
{
  for (member : typeid<T>.members())
      if (!member.is_static() && member.is_field())
      [[emit]]
      {
        func(t.$member);
      };
}

Interesting twist... So instead of introducing new control syntaxes it
introduce new kind of blocks. I can also use this idea for my proposal.
#<constexpr>
  for (const auto& member : typeid<T>.members()) {
    if (!member.is_static() && member.is_field()) {
      #<emit>
        func(t.#<id>member#</id>);
      #</emit>
    }
  }
#</constexpr>

And what is your  idea about AST?
Can you take a look at this approach?
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/ast.h

I think the first step is to agree an AST library.

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

<div dir=3D"ltr"><br><br><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div>Almost 3 lines, if you take comments and surrounding funct=
ion<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb=
(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><co=
de><div><span style=3D"color:#008">template</span><span style=3D"color:#660=
">&lt;</span><span style=3D"color:#008">typename</span><span style=3D"color=
:#000"> T</span><span style=3D"color:#660">,</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#008">typename</span><span style=3D"color:#=
000"> </span><span style=3D"color:#606">Functor</span><span style=3D"color:=
#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#008">void</span><span style=3D"color:#000"> apply</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#000">T</span><span style=3D"color:#=
660">&amp;&amp;</span><span style=3D"color:#000"> t</span><span style=3D"co=
lor:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#=
606">Functor</span><span style=3D"color:#660">&amp;&amp;</span><span style=
=3D"color:#000"> func</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#660">[[</span><span=
 style=3D"color:#000">macro</span><span style=3D"color:#660">]]</span><span=
 style=3D"color:#000"><br>&nbsp; </span><span style=3D"color:#660">{</span>=
<span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span style=3D"color:#0=
08">for</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>(</span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> =
m</span><span style=3D"color:#660">:</span><span style=3D"color:#000"> T</s=
pan><span style=3D"color:#660">.</span><span style=3D"color:#000">members</=
span><span style=3D"color:#660">())</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#800">// enumerate all type members</span><span styl=
e=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#800"=
>// check that our member isn't static and that it's a field</span><span st=
yle=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#00=
8">if</span><span style=3D"color:#000"> </span><span style=3D"color:#660">(=
!</span><span style=3D"color:#000">m</span><span style=3D"color:#660">.</sp=
an><span style=3D"color:#000">is_static</span><span style=3D"color:#660">()=
</span><span style=3D"color:#000"> </span><span style=3D"color:#660">&amp;&=
amp;</span><span style=3D"color:#000"> m</span><span style=3D"color:#660">.=
</span><span style=3D"color:#000">is_field</span><span style=3D"color:#660"=
>())</span><span style=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; emit =
$</span><span style=3D"color:#660">{</span><span style=3D"color:#000"> func=
</span><span style=3D"color:#660">(</span><span style=3D"color:#000">t</spa=
n><span style=3D"color:#660">.</span><span style=3D"color:#000">$m</span><s=
pan style=3D"color:#660">);</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">};</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#800">// emit func invocation</span><span style=3D"color:#000"><=
br>&nbsp; </span><span style=3D"color:#660">}</span><span style=3D"color:#0=
00"><br></span><span style=3D"color:#660">}</span><span style=3D"color:#000=
"><br><br></span></div></code></div><br>&nbsp;</div></div></blockquote><div=
>So what you want here is that<br><code>&nbsp; [[macro]] // a block which d=
oesn't introduce a scope and it contains constexprs<br>&nbsp; {<br>&nbsp;&n=
bsp;&nbsp;&nbsp; constexpr<br>&nbsp;</code><code><code><span style=3D"color=
:#000">&nbsp; &nbsp; </span><span style=3D"color:#008">for</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=3D"=
color:#008">auto</span><span style=3D"color:#000"> m</span><span style=3D"c=
olor:#660">:</span><span style=3D"color:#000"> T</span><span style=3D"color=
:#660">.</span><span style=3D"color:#000">members</span><span style=3D"colo=
r:#660">())</span><span style=3D"color:#000"> </span><span style=3D"color:#=
800">// enumerate all type members</span><span style=3D"color:#000"><br>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; ^^ // this is your proposed syntax to get the ast<=
br></span></code></code><code><code><span style=3D"color:#000">&nbsp; &nbsp=
; &nbsp; </span><span style=3D"color:#008">if</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#660">(!</span><span style=3D"color:#000">=
m</span><span style=3D"color:#660">.</span><span style=3D"color:#000">is_st=
atic</span><span style=3D"color:#660">()</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">&amp;&amp;</span><span style=3D"color:#00=
0"> m</span><span style=3D"color:#660">.</span><span style=3D"color:#000">i=
s_field</span><span style=3D"color:#660">())</span><span style=3D"color:#00=
0"><br>&nbsp; &nbsp; &nbsp; &nbsp; emit </span></code></code><code><code><s=
pan style=3D"color:#000"><code> // a block which doesn't introduce a scope =
and it contains normal statements and declarations</code><br>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; $</span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;=
 func</span><span style=3D"color:#660">(</span><span style=3D"color:#000">t=
</span><span style=3D"color:#660">.</span><span style=3D"color:#000">$m</sp=
an><span style=3D"color:#660">);</span><span style=3D"color:#000"><br>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^^ your proposed syntax to paste a token=
<br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color:#660">};</span>=
<span style=3D"color:#800"></span><span style=3D"color:#000"><br></span></c=
ode>}<br><br>So you want two new kinds of block<br>1.<br><span style=3D"col=
or:#660"></span></code><br><code>&nbsp; [[macro]] // a block which doesn't =
introduce a scope and it contains constexprs<br>&nbsp; {<br>&nbsp; }<br><br=
><br>2.</code><code><span style=3D"color:#000"><code><span style=3D"color:#=
660"></span><span style=3D"color:#000"></span></code><br></span></code>&nbs=
p; &nbsp;emit<br>&nbsp; &nbsp;${<br>&nbsp; &nbsp;}<br><code><code><span sty=
le=3D"color:#000"><br>I think they should use similar syntax for example:<b=
r></span></code></code><br>[[constexpr]]<br>{<br>&nbsp; for (member : typei=
d&lt;T&gt;.members())<br>&nbsp; &nbsp; &nbsp; if (!member.is_static() &amp;=
&amp; member.is_field())<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [[emit]]<br>&nbs=
p; &nbsp; &nbsp; {<br>&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; func(t.$member);<br>=
&nbsp; &nbsp; &nbsp; };<br>}<br><br>Interesting twist... So instead of intr=
oducing new control syntaxes it introduce new kind of blocks. I can also us=
e this idea for my proposal.<br><span style=3D"font-family: courier new,mon=
ospace;">#&lt;constexpr&gt;<br>&nbsp; for (const auto&amp; member : typeid&=
lt;T&gt;.members()) {<br>&nbsp; &nbsp; if (!member.is_static() &amp;&amp; m=
ember.is_field()) {<br>&nbsp; &nbsp;&nbsp;&nbsp; #&lt;emit&gt;<br>&nbsp; &n=
bsp; &nbsp;&nbsp;&nbsp; func(t.#&lt;id&gt;member#&lt;/id&gt;);<br>&nbsp; &n=
bsp; &nbsp; #&lt;/emit&gt;<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp; }<br>#&lt;/con=
stexpr&gt;<br></span><br>And what is your&nbsp; idea about AST?<br>Can you =
take a look at this approach?<br><a href=3D"https://github.com/hun-nemethpe=
ter/cpp-reflector-mini/blob/master/constexpr-ast/ast.h">https://github.com/=
hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/ast.h</a><br><=
br>I think the first step is to agree an AST library.<br><br>Peter<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 />

------=_Part_105_894861748.1431164086169--
------=_Part_104_242822264.1431164086169--

.

------=_Part_3001_633836642.1431166211949
Content-Type: multipart/alternative;
 boundary="----=_Part_3002_1373552974.1431166211949"

------=_Part_3002_1373552974.1431166211949
Content-Type: text/plain; charset=UTF-8



On Saturday, May 9, 2015 at 2:20:24 AM UTC+3, Nicol Bolas wrote:
>
>
>
> On Friday, May 8, 2015 at 6:20:01 PM UTC-4, Igor Baidiuk wrote:
>>
>> On Friday, May 8, 2015 at 12:31:35 PM UTC+3, Nicol Bolas wrote:
>>
>>> That cannot be a function (constexpr or not) of any kind under the rules
>>> of C++. The problem is that C++ is statically typed. And every expression
>>> must have a single, well-defined type. The return type of `AccessMember`
>>> will have to be different, based on the contents of `desc`. But you can't
>>> vary the return type of a function based on the *contents* of a
>>> parameter. That's a hard-and-fast rule of C++.
>>>
>>
>> I think you're missing one very important point. Types, declarations,
>> etc. are just AST elements at some point of compilation. And AST is just a
>> data processed by some program, compiler in our case. So type from within a
>> program becomes a descriptor, which lists its elements.
>> So the idea is to allow programmers to influence the way AST is
>> processed. By adding mini-pieces of code which are run by compiler as some
>> kind of mini-plugins.
>>
>
> I don't see the part of the C++ stnadard that formalizes this notion of an
> AST. So, you can't really describe this concept as modifying something that
> is an implementation detail.
>
> Oh sure, we all know what this stuff means. But the standard doesn't.
>
> More importantly, I don't feel we need that level of access or
> manipulation to make compile-time reflection worthwhile.
>
> Template metaprogramming side-steps this rule via recursion.
>>> `MemberDescriptionList` would be a class that has a variadic template
>>> argument list. Each argument would be some `MemberDescription<T>`, with `T`
>>> being the type of the argument. And therefore, you can have an
>>> `AccessMember` that takes a `MemberDescription<T>` and returns a `T&` or
>>> `const T&`. And you walk the list via recursively calling the function, as
>>> with standard practice for variadic templates.
>>>
>>> You can't break this rule without rewriting some of the most fundamental
>>> rules of C++. At which point, your criticism of template metaprogramming
>>> becomes rather ironic. Because however much you may want to think of what
>>> you're suggesting as "just" a `constexpr` function, it will have to operate
>>> under rules so alien to C++ that it will be as different from regular
>>> runtime C++ as template metaprogramming is.
>>>
>>> Take the OP's suggestion. It's basically a second macro language.
>>> Because the first one worked out so well. It may look a bit like C++, but
>>> so does template metaprogrmaming. And to be honest, TMP behaves more like
>>> regular C++ than this macro language.
>>>
>>
>> If we wanna real compile-time reflection, we need to implement it in its
>> domain. Full-fledged reflection means working with types, expressions etc.
>> as a kind of data. TMP on the other hand is designed to work with types, in
>> the way of a very limited pure functional language. Using integrals and
>> constexpr pointers is more like to side effect.
>>
>
> It depends on how much compile-time reflection you're talking about.
>
> The most basic level of compile-time reflection is accessing what the
> compiler knows about a particular type. Being able to introspect what
> members of a type are, where it is defined, etc.
>
Not very useful by itself, I'd say.

>
> This is something that requires no expression manipulation. It could be
> done purely with TMP, plus a way to ask for the type/member data.
>
> Above that is more active reflection: the ability to use the information
> acquired above to access data. The ability not merely to introspect the
> members, but to construct types based only on a compile-time type
> description. To access members of an instance based on the member
> descriptor of that member.
>
> This requires a bit more functionality, and TMP is really not specifically
> involved with it. It's more about compiler "functions" that can convert, at
> compile-time, type or member descriptors into actual types and members.
>
> The highest level of compile-time reflection is the ability to *generate*
> elements of a type, and/or new types arbitrarily.
>
> It's that last level that requires lots of heavy syntax that TMP + a few
> intrinsics can't (reasonably) provide. That's where you want to "work with
> ... expressions".
>

The minimal viable level is the one providing ability to generate something
like equality operator for arbitrary type, using only user-accessible
facilities and no compiler-only magic (I mean no =default
constrictors/assignments, which are blackboxes). Though we'll certainly
want much more in a short term. Like get list of all class' derived classes.


>
>
>>>>    - No debugging support and probably non-trivial to add such a thing.
>>>>
>>>>
>>> I fail to see how the proposed macro-style solution will be any easier
>>> to debug. At least with concepts, TMP will be a lot easier to catch errors
>>> in. Also, TMP is still nominally C++, so it works under the same rules.
>>>
>>>>
>>>>    - Adding more features to templates for the sake of
>>>>    meta-programming just makes templates even more complex than they already
>>>>    are for everyone (users & compiler vendors), it's gaining to many
>>>>    responsibilities, templates should just focus on one thing what they
>>>>    originally designed to be used for that is parametric polymorphism.
>>>>
>>>>
>>> I admit that I haven't gone in depth with any of the reflection
>>> proposals. But I didn't think that they were adding features to
>>> *templates* specifically. I thought the various reflection features
>>> were simply designed to work with existing metaprogramming facilities. That
>>> is, reflection functionality returns metafunctions, tuples, or classes
>>> containing variadic template parameter packs of types and so forth.
>>>
>>
>> Please describe how I can check nowadays that a type passed in is a
>> variadic template function.
>>
>
> "Nowadays"? You'd probably use some horrible std::enable_if thing.
>
> "Eventually"? You'd use a concept. An appropriate concept could easily be
> provided by the reflection facilities.
>
>
>> What language features, which makes templates "even more complex than
>>> they already are," have been suggested for addition?
>>>
>>
>> I think it's because compiler maintainers will need to introduce another
>> bunch of magic attributes/extensions/intrinsics to retrieve list of members
>> for arbitrary type T. Let's have even more internal magic!
>>
>
> You say that as though `T.members()` will somehow not be "internal magic".
>

At least it looks easier to understand than
std::class_descriptor<T>::member_list::head, where we'll eventually end
with TMP.

>
> Also, I fail to see how introducing a second macro language (third if you
>>> count templates as a limited, type-checked, macro language) makes the
>>> language less complex.
>>>
>>> It doesn't, for sure
>> Though
>> * Macro language is a simple sed/awk search and replace.
>> * Templates were meant to generalize collections over arbitrary types.
>> Personally I think that adding non-type template parameters was a second
>> billion-dollar mistake.
>>
>
> Given the fruits of metaprogramming, I'd love to make that kind of
> "mistake" ;)
>
> Also, templates were not created for STL. They were created as an
> alternative to macros, so that we could have a method to generalize a
> concept over a type, without having type-unsafe elements like macros.
> Instead of writing and calling a macro function, you write a template
> function.
>
This says much about templates. They were just an extension to preprocessor
at the beginning.

>
> Lastly, non-type template parameters aren't a huge part of TMP. They're
> useful to be sure, but hardly essential for the concept.
>
Ok, an overstatement from my side. Though the current templates spec
provokes their use in a way they weren't mean to be used. That's what I
don't like. Several layers of enable_if/decay/is_some_fancy_stuff and a few
hundred lines of template errors. And I hope we'll have concepts someday
along with ability to enforce their use unconditionally.

To conclude, I just don't like attempts to extend tool out of its normal
function, making it abomination.
When I imagine CT reflection with TMP, I remember that pic with Mickey
tearing his eyes.

--

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

<div dir=3D"ltr"><br><br>On Saturday, May 9, 2015 at 2:20:24 AM UTC+3, Nico=
l Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><br><br>On Friday, May 8, 2015 at 6:20:01 PM UTC-4, Igor Baidiuk wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, May 8, 201=
5 at 12:31:35 PM UTC+3, Nicol Bolas wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>That cannot be a function (constexpr or no=
t) of any kind under the rules of C++. The problem is that C++ is staticall=
y typed. And every expression must have a single, well-defined type. The re=
turn type of `AccessMember` will have to be different, based on the content=
s of `desc`. But you can't vary the return type of a function based on the =
<i>contents</i> of a parameter. That's a hard-and-fast rule of C++.<br></di=
v></div></blockquote><div><br>I think you're missing one very important poi=
nt. Types, declarations, etc. are just AST elements at some point of compil=
ation. And AST is just a data processed by some program, compiler in our ca=
se. So type from within a program becomes a descriptor, which lists its ele=
ments.<br>So the idea is to allow programmers to influence the way AST is p=
rocessed. By adding mini-pieces of code which are run by compiler as some k=
ind of mini-plugins.<br></div></div></blockquote><div><br>I don't see the p=
art of the C++ stnadard that formalizes this notion of an AST. So, you can'=
t really describe this concept as modifying something that is an implementa=
tion detail.<br><br>Oh sure, we all know what this stuff means. But the sta=
ndard doesn't.<br><br>More importantly, I don't feel we need that level of =
access or manipulation to make compile-time reflection worthwhile.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div>Template metaprogramming s=
ide-steps this rule via recursion. `MemberDescriptionList` would be a class=
 that has a variadic template argument list. Each argument would be some `M=
emberDescription&lt;T&gt;`, with `T` being the type of the argument. And th=
erefore, you can have an `AccessMember` that takes a `MemberDescription&lt;=
T&gt;` and returns a `T&amp;` or `const T&amp;`. And you walk the list via =
recursively calling the function, as with standard practice for variadic te=
mplates.<br><br>You can't break this rule without rewriting some of the mos=
t fundamental rules of C++. At which point, your criticism of template meta=
programming becomes rather ironic. Because however much you may want to thi=
nk of what you're suggesting as "just" a `constexpr` function, it will have=
 to operate under rules so alien to C++ that it will be as different from r=
egular runtime C++ as template metaprogramming is.<br><br>Take the OP's sug=
gestion. It's basically a second macro language. Because the first one work=
ed out so well. It may look a bit like C++, but so does template metaprogrm=
aming. And to be honest, TMP behaves more like regular C++ than this macro =
language.<br></div></div></blockquote><div><br>If we wanna real compile-tim=
e reflection, we need to implement it in its domain. Full-fledged reflectio=
n means working with types, expressions etc. as a kind of data. TMP on the =
other hand is designed to work with types, in the way of a very limited pur=
e functional language. Using integrals and constexpr pointers is more like =
to side effect.<br></div></div></blockquote><div><br>It depends on how much=
 compile-time reflection you're talking about.<br><br>The most basic level =
of compile-time reflection is accessing what the compiler knows about a par=
ticular type. Being able to introspect what members of a type are, where it=
 is defined, etc.<br></div></div></blockquote><div>Not very useful by itsel=
f, I'd say. <br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><br>This is something that requires no expression manipulatio=
n. It could be done purely with TMP, plus a way to ask for the type/member =
data.<br><br>Above that is more active reflection: the ability to use the i=
nformation acquired above to access data. The ability not merely to introsp=
ect the members, but to construct types based only on a compile-time type d=
escription. To access members of an instance based on the member descriptor=
 of that member.<br><br>This requires a bit more functionality, and TMP is =
really not specifically involved with it. It's more about compiler "functio=
ns" that can convert, at compile-time, type or member descriptors into actu=
al types and members.<br><br>The highest level of compile-time reflection i=
s the ability to <i>generate</i> elements of a type, and/or new types arbit=
rarily.<br><br>It's that last level that requires lots of heavy syntax that=
 TMP + a few intrinsics can't (reasonably) provide. That's where you want t=
o "work with ... expressions". <br></div></div></blockquote><div><br>The mi=
nimal viable level is the one providing ability to generate something like =
equality operator for arbitrary type, using only user-accessible facilities=
 and no compiler-only magic (I mean no =3Ddefault constrictors/assignments,=
 which are blackboxes). Though we'll certainly want much more in a short te=
rm. Like get list of all class' derived classes.<br>&nbsp;<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><br></div><bloc=
kquote 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"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><ul><li>No debugging support and probably non-trivial to =
add such a thing.<br></li></ul></div></blockquote><div><br>I fail to see ho=
w the proposed macro-style solution will be any easier to debug. At least w=
ith concepts, TMP will be a lot easier to catch errors in. Also, TMP is sti=
ll nominally C++, so it works under the same rules. <br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><ul><li>Adding more features to=
 templates for the sake of meta-programming just makes templates even more =
complex than they already are for everyone (users &amp; compiler vendors), =
it's gaining to many responsibilities, templates should just focus on one t=
hing what they originally designed to be used for that is parametric polymo=
rphism.<br></li></ul></div></blockquote><div><br>I admit that I haven't gon=
e in depth with any of the reflection proposals. But I didn't think that th=
ey were adding features to <i>templates</i> specifically. I thought the var=
ious reflection features were simply designed to work with existing metapro=
gramming facilities. That is, reflection functionality returns metafunction=
s, tuples, or classes containing variadic template parameter packs of types=
 and so forth.<br></div></div></blockquote><div>&nbsp;<br>Please describe h=
ow I can check nowadays that a type passed in is a variadic template functi=
on.<br></div></div></blockquote><div><br>"Nowadays"? You'd probably use som=
e horrible std::enable_if thing.<br><br>"Eventually"? You'd use a concept. =
An appropriate concept could easily be provided by the reflection facilitie=
s.<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>What lang=
uage features, which makes templates "even more complex than they already a=
re," have been suggested for addition?<br></div></div></blockquote><div><br=
>I think it's because compiler maintainers will need to introduce another b=
unch of magic attributes/extensions/<wbr>intrinsics to retrieve list of mem=
bers for arbitrary type T. Let's have even more internal magic!<br></div></=
div></blockquote><div><br>You say that as though `T.members()` will somehow=
 not be "internal magic".<br></div></div></blockquote><div><br>At least it =
looks easier to understand than std::class_descriptor&lt;T&gt;::member_list=
::head, where we'll eventually end with TMP. <br></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><br></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"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div>Also, I fail to see how introducing a second mac=
ro language (third if you count templates as a limited, type-checked, macro=
 language) makes the language less complex.</div><br></div></blockquote><di=
v>It doesn't, for sure<br>Though<br>* Macro language is a simple sed/awk se=
arch and replace.<br>* Templates were meant to generalize collections over =
arbitrary types. Personally I think that adding non-type template parameter=
s was a second billion-dollar mistake.<br></div></div></blockquote><div><br=
>Given the fruits of metaprogramming, I'd love to make that kind of "mistak=
e" ;)<br><br>Also, templates were not created for STL. They were created as=
 an alternative to macros, so that we could have a method to generalize a c=
oncept over a type, without having type-unsafe elements like macros. Instea=
d of writing and calling a macro function, you write a template function.<b=
r></div></div></blockquote><div>This says much about templates. They were j=
ust an extension to preprocessor at the beginning. <br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>Lastly, non-type t=
emplate parameters aren't a huge part of TMP. They're useful to be sure, bu=
t hardly essential for the concept.</div></div></blockquote><div>Ok, an ove=
rstatement from my side. Though the current templates spec provokes their u=
se in a way they weren't mean to be used. That's what I don't like. Several=
 layers of enable_if/decay/is_some_fancy_stuff and a few hundred lines of t=
emplate errors. And I hope we'll have concepts someday along with ability t=
o enforce their use unconditionally.<br><br>To conclude, I just don't like =
attempts to extend tool out of its normal function, making it abomination.<=
br>When I imagine CT reflection with TMP, I remember that pic with Mickey t=
earing his eyes.<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_3002_1373552974.1431166211949--
------=_Part_3001_633836642.1431166211949--

.

------=_Part_87_276383538.1431166997544
Content-Type: multipart/alternative;
 boundary="----=_Part_88_170994705.1431166997545"

------=_Part_88_170994705.1431166997545
Content-Type: text/plain; charset=UTF-8



On Saturday, May 9, 2015 at 12:34:46 PM UTC+3, hun.nem...@gmail.com wrote:
>
>
>
> Almost 3 lines, if you take comments and surrounding function
>>
>> template<typename T, typename Functor>
>> void apply(T&& t, Functor&& func)
>> {
>>   [[macro]]
>>   {
>>     for (auto m: T.members()) // enumerate all type members
>>       // check that our member isn't static and that it's a field
>>       if (!m.is_static() && m.is_field())
>>         emit ${ func(t.$m); }; // emit func invocation
>>   }
>> }
>>
>>
>>
>>
> So what you want here is that
>   [[macro]] // a block which doesn't introduce a scope and it contains
> constexprs
>   {
>      constexpr
>      for (auto m: T.members()) // enumerate all type members
>                   ^^ // this is your proposed syntax to get the ast
>       if (!m.is_static() && m.is_field())
>         emit // a block which doesn't introduce a scope and it contains
> normal statements and declarations
>         ${
>              func(t.$m);
>                     ^^ your proposed syntax to paste a token
>         };
> }
>
> So you want two new kinds of block
> 1.
>
>   [[macro]] // a block which doesn't introduce a scope and it contains
> constexprs
>   {
>   }
>
>
> 2.
>    emit
>    ${
>    }
>
> I think they should use similar syntax for example:
>
> [[constexpr]]
> {
>   for (member : typeid<T>.members())
>       if (!member.is_static() && member.is_field())
>       [[emit]]
>       {
>         func(t.$member);
>       };
> }
>
This is pretty much a concept just out of my head. So he naming is
debatable.
My idea was inspired by Nemerle language http://nemerle.org , with all
ergonomics of its macro system. They even have macro which generates PEG
parser at compile time. Not my final goal of course, but a very good
example.


>
> Interesting twist... So instead of introducing new control syntaxes it
> introduce new kind of blocks. I can also use this idea for my proposal.
> #<constexpr>
>   for (const auto& member : typeid<T>.members()) {
>     if (!member.is_static() && member.is_field()) {
>       #<emit>
>         func(t.#<id>member#</id>);
>       #</emit>
>     }
>   }
> #</constexpr>
>
The main idea is to introduce pieces of code which work as compiler's
micro-plugins, and executed at compile time. That's why there will be no
new control structures, except quas-quotation and emit keyword.


>
> And what is your  idea about AST?
> Can you take a look at this approach?
>
> https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/ast.h
>
> I think the first step is to agree an AST library.
>
Will look at it. But you must know that I have almost no experience in
compiler/language development. So I doubt I'll be of great help. I'm
looking at problem from the position of ordinary programmer.

BTW, it would be funny if some CLang-only reflector lib will emerge and
become widely used, especially with recent news of MS adding CLang support
to VS.


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

<div dir=3D"ltr"><br><br>On Saturday, May 9, 2015 at 12:34:46 PM UTC+3, hun=
..nem...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><br><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"=
><div>Almost 3 lines, if you take comments and surrounding function<br><br>=
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style=3D"color:#008">template</span><span style=3D"color:#660">&lt;</spa=
n><span style=3D"color:#008">typename</span><span style=3D"color:#000"> T</=
span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">typename</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#606">Functor</span><span style=3D"color:#660">&gt;<=
/span><span style=3D"color:#000"><br></span><span style=3D"color:#008">void=
</span><span style=3D"color:#000"> apply</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">T</span><span style=3D"color:#660">&amp;&=
amp;</span><span style=3D"color:#000"> t</span><span style=3D"color:#660">,=
</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Functo=
r</span><span style=3D"color:#660">&amp;&amp;</span><span style=3D"color:#0=
00"> func</span><span style=3D"color:#660">)</span><span style=3D"color:#00=
0"><br></span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
><br>&nbsp; </span><span style=3D"color:#660">[[</span><span style=3D"color=
:#000">macro</span><span style=3D"color:#660">]]</span><span style=3D"color=
:#000"><br>&nbsp; </span><span style=3D"color:#660">{</span><span style=3D"=
color:#000"><br>&nbsp; &nbsp; </span><span style=3D"color:#008">for</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span =
style=3D"color:#008">auto</span><span style=3D"color:#000"> m</span><span s=
tyle=3D"color:#660">:</span><span style=3D"color:#000"> T</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">members</span><span styl=
e=3D"color:#660">())</span><span style=3D"color:#000"> </span><span style=
=3D"color:#800">// enumerate all type members</span><span style=3D"color:#0=
00"><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#800">// check tha=
t our member isn't static and that it's a field</span><span style=3D"color:=
#000"><br>&nbsp; &nbsp; &nbsp; </span><span style=3D"color:#008">if</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">(!</span><span=
 style=3D"color:#000">m</span><span style=3D"color:#660">.</span><span styl=
e=3D"color:#000">is_static</span><span style=3D"color:#660">()</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">&amp;&amp;</span><s=
pan style=3D"color:#000"> m</span><span style=3D"color:#660">.</span><span =
style=3D"color:#000">is_field</span><span style=3D"color:#660">())</span><s=
pan style=3D"color:#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; emit $</span><span=
 style=3D"color:#660">{</span><span style=3D"color:#000"> func</span><span =
style=3D"color:#660">(</span><span style=3D"color:#000">t</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">$m</span><span style=3D"=
color:#660">);</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">};</span><span style=3D"color:#000"> </span><span style=3D"color:#8=
00">// emit func invocation</span><span style=3D"color:#000"><br>&nbsp; </s=
pan><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></spa=
n><span style=3D"color:#660">}</span><span style=3D"color:#000"><br><br></s=
pan></div></code></div><br>&nbsp;</div></div></blockquote><div>So what you =
want here is that<br><code>&nbsp; [[macro]] // a block which doesn't introd=
uce a scope and it contains constexprs<br>&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nb=
sp; constexpr<br>&nbsp;</code><code><code><span style=3D"color:#000">&nbsp;=
 &nbsp; </span><span style=3D"color:#008">for</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#660">(</span><span style=3D"color:#008">a=
uto</span><span style=3D"color:#000"> m</span><span style=3D"color:#660">:<=
/span><span style=3D"color:#000"> T</span><span style=3D"color:#660">.</spa=
n><span style=3D"color:#000">members</span><span style=3D"color:#660">())</=
span><span style=3D"color:#000"> </span><span style=3D"color:#800">// enume=
rate all type members</span><span style=3D"color:#000"><br>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; ^^ // this is your proposed syntax to get the ast<br></span></c=
ode></code><code><code><span style=3D"color:#000">&nbsp; &nbsp; &nbsp; </sp=
an><span style=3D"color:#008">if</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">(!</span><span style=3D"color:#000">m</span><span=
 style=3D"color:#660">.</span><span style=3D"color:#000">is_static</span><s=
pan style=3D"color:#660">()</span><span style=3D"color:#000"> </span><span =
style=3D"color:#660">&amp;&amp;</span><span style=3D"color:#000"> m</span><=
span style=3D"color:#660">.</span><span style=3D"color:#000">is_field</span=
><span style=3D"color:#660">())</span><span style=3D"color:#000"><br>&nbsp;=
 &nbsp; &nbsp; &nbsp; emit </span></code></code><code><code><span style=3D"=
color:#000"><code> // a block which doesn't introduce a scope and it contai=
ns normal statements and declarations</code><br>&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; $</span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#000"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; func</span><=
span style=3D"color:#660">(</span><span style=3D"color:#000">t</span><span =
style=3D"color:#660">.</span><span style=3D"color:#000">$m</span><span styl=
e=3D"color:#660">);</span><span style=3D"color:#000"><br>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; ^^ your proposed syntax to paste a token<br>&nbsp; &n=
bsp; &nbsp; &nbsp; </span><span style=3D"color:#660">};</span><span style=
=3D"color:#800"></span><span style=3D"color:#000"><br></span></code>}<br><b=
r>So you want two new kinds of block<br>1.<br><span style=3D"color:#660"></=
span></code><br><code>&nbsp; [[macro]] // a block which doesn't introduce a=
 scope and it contains constexprs<br>&nbsp; {<br>&nbsp; }<br><br><br>2.</co=
de><code><span style=3D"color:#000"><code><span style=3D"color:#660"></span=
><span style=3D"color:#000"></span></code><br></span></code>&nbsp; &nbsp;em=
it<br>&nbsp; &nbsp;${<br>&nbsp; &nbsp;}<br><code><code><span style=3D"color=
:#000"><br>I think they should use similar syntax for example:<br></span></=
code></code><br>[[constexpr]]<br>{<br>&nbsp; for (member : typeid&lt;T&gt;.=
members())<br>&nbsp; &nbsp; &nbsp; if (!member.is_static() &amp;&amp; membe=
r.is_field())<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [[emit]]<br>&nbsp; &nbsp; &=
nbsp; {<br>&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; func(t.$member);<br>&nbsp; &nbs=
p; &nbsp; };<br>}<br></div></div></blockquote><div>This is pretty much a co=
ncept just out of my head. So he naming is debatable.<br>My idea was inspir=
ed by Nemerle language <a href=3D"http://nemerle.org">http://nemerle.org</a=
> , with all ergonomics of its macro system. They even have macro which gen=
erates PEG parser at compile time. Not my final goal of course, but a very =
good example.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><br>Interesting twist... So instead of introducing new=
 control syntaxes it introduce new kind of blocks. I can also use this idea=
 for my proposal.<br><span style=3D"font-family:courier new,monospace">#&lt=
;constexpr&gt;<br>&nbsp; for (const auto&amp; member : typeid&lt;T&gt;.memb=
ers()) {<br>&nbsp; &nbsp; if (!member.is_static() &amp;&amp; member.is_fiel=
d()) {<br>&nbsp; &nbsp;&nbsp;&nbsp; #&lt;emit&gt;<br>&nbsp; &nbsp; &nbsp;&n=
bsp;&nbsp; func(t.#&lt;id&gt;member#&lt;/id&gt;);<br>&nbsp; &nbsp; &nbsp; #=
&lt;/emit&gt;<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp; }<br>#&lt;/constexpr&gt;<br=
></span></div></div></blockquote><div>The main idea is to introduce pieces =
of code which work as compiler's micro-plugins, and executed at compile tim=
e. That's why there will be no new control structures, except quas-quotatio=
n and emit keyword.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><span style=3D"font-family:courier new,monospac=
e"></span><br>And what is your&nbsp; idea about AST?<br>Can you take a look=
 at this approach?<br><a href=3D"https://github.com/hun-nemethpeter/cpp-ref=
lector-mini/blob/master/constexpr-ast/ast.h" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F=
%2Fgithub.com%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2Fmaster%2Fcons=
texpr-ast%2Fast.h\46sa\75D\46sntz\0751\46usg\75AFQjCNEGnz62S59pNq6soP8Uh6ex=
66RVnw';return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\=
75https%3A%2F%2Fgithub.com%2Fhun-nemethpeter%2Fcpp-reflector-mini%2Fblob%2F=
master%2Fconstexpr-ast%2Fast.h\46sa\75D\46sntz\0751\46usg\75AFQjCNEGnz62S59=
pNq6soP8Uh6ex66RVnw';return true;">https://github.com/hun-<wbr>nemethpeter/=
cpp-reflector-<wbr>mini/blob/master/constexpr-<wbr>ast/ast.h</a><br><br>I t=
hink the first step is to agree an AST library.<br></div></div></blockquote=
><div>Will look at it. But you must know that I have almost no experience i=
n compiler/language development. So I doubt I'll be of great help. I'm look=
ing at problem from the position of ordinary programmer.<br><br>BTW, it wou=
ld be funny if some CLang-only reflector lib will emerge and become widely =
used, especially with recent news of MS adding CLang support to VS.<br>&nbs=
p;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
<br>Peter<br><br></div></div></blockquote></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_88_170994705.1431166997545--
------=_Part_87_276383538.1431166997544--

.

------=_Part_1_433725574.1431290044985
Content-Type: multipart/alternative;
 boundary="----=_Part_2_1066224300.1431290044985"

------=_Part_2_1066224300.1431290044985
Content-Type: text/plain; charset=UTF-8

On Saturday, May 9, 2015 at 2:34:46 AM UTC-7, hun.nem...@gmail.com wrote:
>
>
> I think the first step is to agree an AST library.
>

There are compilers that don't even use any ASTs internally. Nothing about
compiling requires an AST. In many cases, translating to an AST just to
translate down to an IR is a huge waste of time and memory during
compilation. Heck, there are valid compilers that don't even use an IR, but
just compile directly to executable code; there's some intermediate state
needed for templates and class bodies, but far less than you might think.
Before trying to agree on an AST library, you'd have to get the people who
matter here (the compiler vendors!) to even agree on requiring an AST at
all.


Also, there's working prototypes of template instantiation debuggers that
already exist, again debunking the entire "you can't debug TMP and hence
_need_ macros" argument. The problem is with the tools implementations
(which will be just as anemic with a whole brand new feature as they are
with TMP today) and not with TMP itself.


pow(Also,2): aim for "evolution before revolution." If there's something
you dislike about TMP or constexpr like the lack of a for-each constructor
that unrolls to differently-typed inlined code, just propose small changes
to those, not an entire huge all-singing all-dancing alternative. Language
evolution (C++ or otherwise) works best when you concentrate on smaller
chunks of highly-reusable functionality rather than huge chunks of
extremely purpose-specific functionality.

Game programmers might even understand the term "emergent" as being
meaningful here. Many small mechanisms that can interact freely result in
far more capabilities than a few big self-encompassing mechanisms, simply
due to combinatorics. e.g. a for-each that supports differing types inside
its loop could be useful for all sorts of things besides introspection or
complex code-generation, like printing a tuple's values more naturally, or
collapsing all kinds of other TMP down into a more imperative style where
constexpr is not suitable. One small feature with many uses is much better
than one huge feature with only a single use.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Saturday, May 9, 2015 at 2:34:46 AM UTC-7, hun.nem...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><br>I think the first step is to agree an AST library.<br></div></di=
v></blockquote><div><br></div><div>There are compilers that don't even use =
any ASTs internally. Nothing about compiling requires an AST. In many cases=
, translating to an AST just to translate down to an IR is a huge waste of =
time and memory during compilation. Heck, there are valid compilers that do=
n't even use an IR, but just compile directly to executable code; there's s=
ome intermediate state needed for templates and class bodies, but far less =
than you might think. Before trying to agree on an AST library, you'd have =
to get the people who matter here (the compiler vendors!) to even agree on =
requiring an AST at all.</div><div><br></div><div><br></div><div>Also, ther=
e's working prototypes of template instantiation debuggers that already exi=
st, again debunking the entire "you can't debug TMP and hence _need_ macros=
" argument. The problem is with the tools implementations (which will be ju=
st as anemic with a whole brand new feature as they are with TMP today) and=
 not with TMP itself.<br></div><div><br></div><div><br></div><div>pow(Also,=
2): aim for "evolution before revolution." If there's something you dislike=
 about TMP or constexpr like the lack of a for-each constructor that unroll=
s to differently-typed inlined code, just propose small changes to those, n=
ot an entire huge all-singing all-dancing alternative. Language evolution (=
C++ or otherwise) works best when you concentrate on smaller chunks of high=
ly-reusable functionality rather than huge chunks of extremely purpose-spec=
ific functionality.</div><div><br></div><div>Game programmers might even un=
derstand the term "emergent" as being meaningful here. Many small mechanism=
s that can interact freely result in far more capabilities than a few big s=
elf-encompassing mechanisms, simply due to combinatorics. e.g. a for-each t=
hat supports differing types inside its loop could be useful for all sorts =
of things besides introspection or complex code-generation, like printing a=
 tuple's values more naturally, or collapsing all kinds of other TMP down i=
nto a more imperative style where constexpr is not suitable. One small feat=
ure with many uses is much better than one huge feature with only a single =
use.</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_2_1066224300.1431290044985--
------=_Part_1_433725574.1431290044985--

.

------=_Part_4338_772239748.1431294569519
Content-Type: multipart/alternative;
 boundary="----=_Part_4339_1789765815.1431294569519"

------=_Part_4339_1789765815.1431294569519
Content-Type: text/plain; charset=UTF-8



On Sunday, May 10, 2015 at 4:34:05 PM UTC-4, Sean Middleditch wrote:
>
> On Saturday, May 9, 2015 at 2:34:46 AM UTC-7, hun.nem...@gmail.com wrote:
>>
>>
>> I think the first step is to agree an AST library.
>>
>
> There are compilers that don't even use any ASTs internally. Nothing about
> compiling requires an AST. In many cases, translating to an AST just to
> translate down to an IR is a huge waste of time and memory during
> compilation. Heck, there are valid compilers that don't even use an IR, but
> just compile directly to executable code; there's some intermediate state
> needed for templates and class bodies, but far less than you might think.
> Before trying to agree on an AST library, you'd have to get the people who
> matter here (the compiler vendors!) to even agree on requiring an AST at
> all.
>
>
> Also, there's working prototypes of template instantiation debuggers that
> already exist, again debunking the entire "you can't debug TMP and hence
> _need_ macros" argument. The problem is with the tools implementations
> (which will be just as anemic with a whole brand new feature as they are
> with TMP today) and not with TMP itself.
>
>
> pow(Also,2): aim for "evolution before revolution." If there's something
> you dislike about TMP or constexpr like the lack of a for-each constructor
> that unrolls to differently-typed inlined code, just propose small changes
> to those, not an entire huge all-singing all-dancing alternative. Language
> evolution (C++ or otherwise) works best when you concentrate on smaller
> chunks of highly-reusable functionality rather than huge chunks of
> extremely purpose-specific functionality.
>

Not to mention the fact that small features will be championed by more
people. Using the given example of an unrolled for loop, that's something
that many people would find useful, reflection or not. Being able to easily
loop over the members of a tuple, template parameter pack, and so forth is
genuinely useful even without reflection.

Make TMP easier to use, and maybe you won't mind so much that reflection
requires it. Indeed, what would be a great idea is to look at some of the
reflection proposals (or just TMP in general), see what the common tasks
are, and try to find simple ways to make the resulting code more human
readable and human implementable.

--

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

<div dir=3D"ltr"><br><br>On Sunday, May 10, 2015 at 4:34:05 PM UTC-4, Sean =
Middleditch wrote:<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">On Saturday, May 9, 2015 at 2:34:46 AM UTC-7, <a>hun.nem...@gmail.com<=
/a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br=
>I think the first step is to agree an AST library.<br></div></div></blockq=
uote><div><br></div><div>There are compilers that don't even use any ASTs i=
nternally. Nothing about compiling requires an AST. In many cases, translat=
ing to an AST just to translate down to an IR is a huge waste of time and m=
emory during compilation. Heck, there are valid compilers that don't even u=
se an IR, but just compile directly to executable code; there's some interm=
ediate state needed for templates and class bodies, but far less than you m=
ight think. Before trying to agree on an AST library, you'd have to get the=
 people who matter here (the compiler vendors!) to even agree on requiring =
an AST at all.</div><div><br></div><div><br></div><div>Also, there's workin=
g prototypes of template instantiation debuggers that already exist, again =
debunking the entire "you can't debug TMP and hence _need_ macros" argument=
.. The problem is with the tools implementations (which will be just as anem=
ic with a whole brand new feature as they are with TMP today) and not with =
TMP itself.<br></div><div><br></div><div><br></div><div>pow(Also,2): aim fo=
r "evolution before revolution." If there's something you dislike about TMP=
 or constexpr like the lack of a for-each constructor that unrolls to diffe=
rently-typed inlined code, just propose small changes to those, not an enti=
re huge all-singing all-dancing alternative. Language evolution (C++ or oth=
erwise) works best when you concentrate on smaller chunks of highly-reusabl=
e functionality rather than huge chunks of extremely purpose-specific funct=
ionality.</div></div></blockquote><div><br>Not to mention the fact that sma=
ll features will be championed by more people. Using the given example of a=
n unrolled for loop, that's something that many people would find useful, r=
eflection or not. Being able to easily loop over the members of a tuple, te=
mplate parameter pack, and so forth is genuinely useful even without reflec=
tion.<br><br>Make TMP easier to use, and maybe you won't mind so much that =
reflection requires it. Indeed, what would be a great idea is to look at so=
me of the reflection proposals (or just TMP in general), see what the commo=
n tasks are, and try to find simple ways to make the resulting code more hu=
man readable and human implementable.</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_4339_1789765815.1431294569519--
------=_Part_4338_772239748.1431294569519--

.

------=_Part_162_1028201219.1431334640261
Content-Type: multipart/alternative;
 boundary="----=_Part_163_176980324.1431334640261"

------=_Part_163_176980324.1431334640261
Content-Type: text/plain; charset=UTF-8



On Sunday, May 10, 2015 at 10:34:05 PM UTC+2, Sean Middleditch wrote:
>
> On Saturday, May 9, 2015 at 2:34:46 AM UTC-7, hun.nem...@gmail.com wrote:
>>
>>
>> I think the first step is to agree an AST library.
>>
>
> There are compilers that don't even use any ASTs internally. Nothing about
> compiling requires an AST. In many cases, translating to an AST just to
> translate down to an IR is a huge waste of time and memory during
> compilation. Heck, there are valid compilers that don't even use an IR, but
> just compile directly to executable code; there's some intermediate state
> needed for templates and class bodies, but far less than you might think.
> Before trying to agree on an AST library, you'd have to get the people who
> matter here (the compiler vendors!) to even agree on requiring an AST at
> all.
>
I think you misunderstand my AST based solution. AST is not exported from a
compiler. In my proposal a compiler generate constructor calls to constexpr
AST classes.

In my working example (
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/test.cpp
):
 static_assert(typeid<Test>.name()  ==  "Test"); static_assert(typeid<Test>.members().size()
==  2); static_assert(typeid<Test>.members()[0].name()  ==  "member1");Compiler
will generate static constexpr ast_xxx objects during compilation with
proper constructor calls and typeid<Test> itself will be a reference to
that object.I didn't invent a proper naming scheme now for generated
ast_xxx objects but thats all.In this case no runtime info was generated. I'm
thinking on a new syntax for example typeid<*static *T> which emit the
generated object to runtime object so you can play with these object in
runtime. So
for (const auto& it : typeid<*static *Test>.members())  std::cout <<
it.name() << std::endl;
will work.

And I think for a proper C++14 constexpr implementation an AST based
approach is needed for compilers.



>
> Also, there's working prototypes of template instantiation debuggers that
> already exist, again debunking the entire "you can't debug TMP and hence
> _need_ macros" argument. The problem is with the tools implementations
> (which will be just as anemic with a whole brand new feature as they are
> with TMP today) and not with TMP itself.
>
I think the TMP debugging is not a tooling problem. Debugging a functional
style language is quite different than debugging a procedural style
language. Its an other skill set.


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

<div dir=3D"ltr"><br><br>On Sunday, May 10, 2015 at 10:34:05 PM UTC+2, Sean=
 Middleditch wrote:<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">On Saturday, May 9, 2015 at 2:34:46 AM UTC-7, <a>hun.nem...@gmail.com=
</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><b=
r>I think the first step is to agree an AST library.<br></div></div></block=
quote><div><br></div><div>There are compilers that don't even use any ASTs =
internally. Nothing about compiling requires an AST. In many cases, transla=
ting to an AST just to translate down to an IR is a huge waste of time and =
memory during compilation. Heck, there are valid compilers that don't even =
use an IR, but just compile directly to executable code; there's some inter=
mediate state needed for templates and class bodies, but far less than you =
might think. Before trying to agree on an AST library, you'd have to get th=
e people who matter here (the compiler vendors!) to even agree on requiring=
 an AST at all.</div></div></blockquote><div>I think you misunderstand my A=
ST based solution. AST is not exported from a compiler. In my proposal a co=
mpiler generate constructor calls to constexpr AST classes.</div><div><br><=
/div><div>In my working example (<a href=3D"https://github.com/hun-nemethpe=
ter/cpp-reflector-mini/blob/master/constexpr-ast/test.cpp">https://github.c=
om/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/test.cpp</a=
>):</div><div><font face=3D"courier new, monospace">&nbsp;static_assert(typ=
eid&lt;Test&gt;.name()&nbsp; =3D=3D&nbsp; "Test");</font><font face=3D"cour=
ier new, monospace">&nbsp;static_assert(typeid&lt;Test&gt;.members().size()=
&nbsp; =3D=3D&nbsp; 2);</font><font face=3D"courier new, monospace">&nbsp;s=
tatic_assert(typeid&lt;Test&gt;.members()[0].name()&nbsp; =3D=3D&nbsp; "mem=
ber1");</font>Compiler will generate static constexpr ast_xxx objects durin=
g compilation with proper constructor calls and typeid&lt;Test&gt; itself w=
ill be a reference to that object.I didn't invent a proper naming scheme no=
w for generated ast_xxx objects but thats all.In this case no runtime info =
was generated.&nbsp;<span style=3D"line-height: 18.2000007629395px;">I'm th=
inking on a new syntax for example typeid&lt;<b>static </b>T&gt; which emit=
 the generated object to runtime object so you can play with these object i=
n runtime. So</span><span style=3D"line-height: 18.2000007629395px;"><br></=
span><font face=3D"courier new, monospace"><span style=3D"line-height: 18.2=
000007629395px;">for (const auto&amp; it :&nbsp;</span>typeid&lt;<b>static =
</b>Test&gt;.members())</font><font face=3D"courier new, monospace">&nbsp; =
std::cout &lt;&lt; it.name() &lt;&lt; std::endl;</font><font face=3D"arial,=
 sans-serif"><br></font><font face=3D"arial, sans-serif">will work.</font><=
br><table class=3D"highlight tab-size-8 js-file-line-container" style=3D"bo=
x-sizing: border-box; border-collapse: collapse; tab-size: 8; color: rgb(51=
, 51, 51); line-height: 18.2000007629395px;"><tbody style=3D"box-sizing: bo=
rder-box;"></tbody><tbody style=3D"box-sizing: border-box;"> </tbody><tbody=
 style=3D"box-sizing: border-box;"> </tbody><tbody style=3D"font-family: He=
lvetica, arial, nimbussansl, liberationsans, freesans, clean, sans-serif, '=
Segoe UI Emoji', 'Segoe UI Symbol'; box-sizing: border-box;"></tbody><tbody=
 style=3D"font-family: Helvetica, arial, nimbussansl, liberationsans, frees=
ans, clean, sans-serif, 'Segoe UI Emoji', 'Segoe UI Symbol'; box-sizing: bo=
rder-box;"></tbody><tbody style=3D"font-family: Helvetica, arial, nimbussan=
sl, liberationsans, freesans, clean, sans-serif, 'Segoe UI Emoji', 'Segoe U=
I Symbol'; box-sizing: border-box;"></tbody><tbody style=3D"font-family: He=
lvetica, arial, nimbussansl, liberationsans, freesans, clean, sans-serif, '=
Segoe UI Emoji', 'Segoe UI Symbol'; box-sizing: border-box;"></tbody><tbody=
 style=3D"box-sizing: border-box;"></tbody><tbody style=3D"box-sizing: bord=
er-box;"></tbody><tbody style=3D"box-sizing: border-box;"></tbody><tbody st=
yle=3D"box-sizing: border-box;"></tbody></table><table class=3D"highlight t=
ab-size-8 js-file-line-container" style=3D"font-family: Arial, Helvetica, s=
ans-serif; border-collapse: collapse; box-sizing: border-box; tab-size: 8; =
line-height: 18.2000007629395px;"><tbody style=3D"box-sizing: border-box;">=
</tbody></table><br>And I think for a proper C++14 constexpr implementation=
 an AST based approach is needed for compilers.<br><br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div><br=
></div><div>Also, there's working prototypes of template instantiation debu=
ggers that already exist, again debunking the entire "you can't debug TMP a=
nd hence _need_ macros" argument. The problem is with the tools implementat=
ions (which will be just as anemic with a whole brand new feature as they a=
re with TMP today) and not with TMP itself.<br></div></div></blockquote><di=
v>I think the TMP debugging is not a tooling problem. Debugging a functiona=
l style language is quite different than debugging a&nbsp;procedural style =
language. Its an other skill set.</div><div><br></div><div><br></div><div>P=
eter</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_163_176980324.1431334640261--
------=_Part_162_1028201219.1431334640261--

.

On Monday 11 May 2015 01:57:20 hun.nemethpeter@gmail.com wrote:
> And I think for a proper C++14 constexpr implementation an AST based
> approach is needed for compilers.

Do you have any evidence that a non-AST compiler is unable to be compliant
with C++14?

> > Also, there's working prototypes of template instantiation debuggers that
> > already exist, again debunking the entire "you can't debug TMP and hence
> > _need_ macros" argument. The problem is with the tools implementations
> > (which will be just as anemic with a whole brand new feature as they are
> > with TMP today) and not with TMP itself.
>
> I think the TMP debugging is not a tooling problem. Debugging a functional
> style language is quite different than debugging a procedural style
> language. Its an other skill set.

And that's no different from debugging your proposed syntax. Debugging the code
generator is quite different from regular debugging of generated (compiled)
code. Your argument is that the syntax is procedural, but it leaves
unaddressed the fact that it happens at a completely different time, requiring
completely different tools, and it affects the program in completely different
ways.

Now, I will agree that figuring out why TMP code isn't compiling as expected is
difficult. Whether it is more so or less so than the proposed new syntax, it's
impossible to tell until there are mature implementations and a year or two of
experience.

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

--

---
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_438_960177345.1431350758038
Content-Type: multipart/alternative;
 boundary="----=_Part_439_400458117.1431350758038"

------=_Part_439_400458117.1431350758038
Content-Type: text/plain; charset=UTF-8



On Monday, May 11, 2015 at 11:56:35 AM UTC+2, Thiago Macieira wrote:
>
> On Monday 11 May 2015 01:57:20 hun.nem...@gmail.com <javascript:> wrote:
> > And I think for a proper C++14 constexpr implementation an AST based
> > approach is needed for compilers.
>
> Do you have any evidence that a non-AST compiler is unable to be compliant
> with C++14?
>
I can't give you a single link. This is my theory as I have some knowledge
in compiler writing. As C++14-constexpr is basically a compile time
interpreted C++ language, and such a thing is needs an intermediate
representation.

 >

> > I think the TMP debugging is not a tooling problem. Debugging a
> functional
> > style language is quite different than debugging a procedural style
> > language. Its an other skill set.
>
> And that's no different from debugging your proposed syntax. Debugging the
> code
> generator is quite different from regular debugging of generated
> (compiled)
> code. Your argument is that the syntax is procedural, but it leaves
> unaddressed the fact that it happens at a completely different time,
> requiring
> completely different tools, and it affects the program in completely
> different
> ways.
>
You are right that debugging a code generator will be a new thing. But the
code generator itself will be a regular procedural process.
I don't know how to debug such a new thing as the new thing (the code
generator) is not exists at the moment but yeah it must be a priority in
design.



>
> Now, I will agree that figuring out why TMP code isn't compiling as
> expected is
> difficult. Whether it is more so or less so than the proposed new syntax,
> it's
> impossible to tell until there are mature implementations and a year or
> two of
> experience.
>
> I think nobody want a new undebuggable code bloat.

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

<div dir=3D"ltr"><br><br>On Monday, May 11, 2015 at 11:56:35 AM UTC+2, Thia=
go Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday 11=
 May 2015 01:57:20 <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"Oyj2F4gZblMJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">hu=
n.nem...@gmail.com</a> wrote:
<br>&gt; And I think for a proper C++14 constexpr implementation an AST bas=
ed=20
<br>&gt; approach is needed for compilers.
<br>
<br>Do you have any evidence that a non-AST compiler is unable to be compli=
ant=20
<br>with C++14?
<br></blockquote><div>I can't give you a single link. This is my theory as =
I have some knowledge in compiler writing. As C++14-constexpr is basically =
a compile time interpreted C++ language, and such a thing is needs an inter=
mediate representation.</div><div><br></div><div>&nbsp;&gt;&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">&gt; I think the TMP debugging is =
not a tooling problem. Debugging a functional=20
<br>&gt; style language is quite different than debugging a procedural styl=
e=20
<br>&gt; language. Its an other skill set.
<br>
<br>And that's no different from debugging your proposed syntax. Debugging =
the code=20
<br>generator is quite different from regular debugging of generated (compi=
led)=20
<br>code. Your argument is that the syntax is procedural, but it leaves=20
<br>unaddressed the fact that it happens at a completely different time, re=
quiring=20
<br>completely different tools, and it affects the program in completely di=
fferent=20
<br>ways.
<br></blockquote><div>You are right that debugging a code generator will be=
 a new thing. But the code generator itself will be a regular procedural pr=
ocess.</div><div>I don't know how to debug such a new thing as the new thin=
g (the code generator) is not exists at the moment but yeah it must be a pr=
iority in design.</div><div><br></div><div>&nbsp;<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;">
<br>Now, I will agree that figuring out why TMP code isn't compiling as exp=
ected is=20
<br>difficult. Whether it is more so or less so than the proposed new synta=
x, it's=20
<br>impossible to tell until there are mature implementations and a year or=
 two of=20
<br>experience.
<br><br></blockquote><div>I think nobody want a new undebuggable code bloat=
..</div><div><br></div><div>Peter&nbsp;</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_439_400458117.1431350758038--
------=_Part_438_960177345.1431350758038--

.

--Apple-Mail=_C3A27319-484C-4669-BB6C-77344A162971
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9311, at 9:25 PM, hun.nemethpeter@gmail.com wrot=
e:
>=20
> You are right that debugging a code generator will be a new thing. But th=
e code generator itself will be a regular procedural process.
> I don't know how to debug such a new thing as the new thing (the code gen=
erator) is not exists at the moment but yeah it must be a priority in desig=
n.
>=20
> I think nobody want a new undebuggable code bloat.

Why are we jumping to the conclusion that creating a TMP debugger would be =
hard? Perhaps nobody has tried.

It can=E2=80=99t be that hard to show the sequence of substitutions and ove=
rload resolutions as they are performed.

Perhaps this hasn=E2=80=99t been prioritized, along with more moderate faci=
lities like printing typenames from static_assert, because not enough folks=
 are doing deep TMP, or having such trouble with it.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_C3A27319-484C-4669-BB6C-77344A162971
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9311, at 9:25 PM, <a href=3D"mailto:hun.nemethpeter@gmail.com" class=
=3D"">hun.nemethpeter@gmail.com</a> wrote:</div><br class=3D"Apple-intercha=
nge-newline"><div class=3D""><div style=3D"font-family: Helvetica; font-siz=
e: 12px; font-style: normal; font-variant: normal; font-weight: normal; let=
ter-spacing: normal; line-height: normal; orphans: auto; text-align: start;=
 text-indent: 0px; text-transform: none; white-space: normal; widows: auto;=
 word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">You are rig=
ht that debugging a code generator will be a new thing. But the code genera=
tor itself will be a regular procedural process.</div><div style=3D"font-fa=
mily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal;=
 font-weight: normal; letter-spacing: normal; line-height: normal; orphans:=
 auto; text-align: start; text-indent: 0px; text-transform: none; white-spa=
ce: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px=
;" class=3D"">I don't know how to debug such a new thing as the new thing (=
the code generator) is not exists at the moment but yeah it must be a prior=
ity in design.</div><div style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; line-height: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br class=3D""></div=
><div style=3D"font-family: Helvetica; font-size: 12px; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tran=
sform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-=
text-stroke-width: 0px;" class=3D"">I think nobody want a new undebuggable =
code bloat.</div></div></blockquote></div><br class=3D""><div class=3D"">Wh=
y are we jumping to the conclusion that creating a TMP debugger would be ha=
rd? Perhaps nobody has tried.</div><div class=3D""><br class=3D""></div><di=
v class=3D"">It can=E2=80=99t be that hard to show the sequence of substitu=
tions and overload resolutions as they are performed.</div><div class=3D"">=
<br class=3D""></div><div class=3D"">Perhaps this hasn=E2=80=99t been prior=
itized, along with more moderate facilities like printing typenames from&nb=
sp;<font face=3D"Courier" class=3D"">static_assert</font>, because not enou=
gh folks are doing deep TMP, or having such trouble with it.</div></body></=
html>

<p></p>

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

--Apple-Mail=_C3A27319-484C-4669-BB6C-77344A162971--

.

On 11 May 2015 at 17:38, David Krauss <potswa@mac.com> wrote:
>
> On 2015=E2=80=9305=E2=80=9311, at 9:25 PM, hun.nemethpeter@gmail.com wrot=
e:
>
> You are right that debugging a code generator will be a new thing. But th=
e
> code generator itself will be a regular procedural process.
> I don't know how to debug such a new thing as the new thing (the code
> generator) is not exists at the moment but yeah it must be a priority in
> design.
>
> I think nobody want a new undebuggable code bloat.
>
>
> Why are we jumping to the conclusion that creating a TMP debugger would b=
e
> hard? Perhaps nobody has tried.

Perhaps people have already tried: https://github.com/mikael-s-persson/temp=
light

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--Apple-Mail=_CED74DAB-0E90-4956-BE01-EA6283C3DFC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9311, at 10:46 PM, Ville Voutilainen <ville.vout=
ilainen@gmail.com> wrote:
>=20
> Perhaps people have already tried: https://github.com/mikael-s-persson/te=
mplight <https://github.com/mikael-s-persson/templight>

Good news! Starting 7 months ago might not count as =E2=80=9Calready=E2=80=
=9D though.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_CED74DAB-0E90-4956-BE01-EA6283C3DFC4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9311, at 10:46 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.vou=
tilainen@gmail.com" class=3D"">ville.voutilainen@gmail.com</a>&gt; wrote:</=
div><br class=3D"Apple-interchange-newline"><div class=3D"">Perhaps people =
have already tried: <a href=3D"https://github.com/mikael-s-persson/templigh=
t" class=3D"">https://github.com/mikael-s-persson/templight</a><br class=3D=
""></div></blockquote></div><br class=3D""><div class=3D"">Good news! Start=
ing 7 months ago might not count as =E2=80=9Calready=E2=80=9D though.</div>=
</body></html>

<p></p>

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

--Apple-Mail=_CED74DAB-0E90-4956-BE01-EA6283C3DFC4--

.

--001a11c204fabe42f00515d11c91
Content-Type: text/plain; charset=UTF-8

On Mon, May 11, 2015 at 6:25 AM, <hun.nemethpeter@gmail.com> wrote:

> On Monday, May 11, 2015 at 11:56:35 AM UTC+2, Thiago Macieira wrote:
>>
>> On Monday 11 May 2015 01:57:20 hun.nem...@gmail.com wrote:
>> > And I think for a proper C++14 constexpr implementation an AST based
>> > approach is needed for compilers.
>>
>> Do you have any evidence that a non-AST compiler is unable to be
>> compliant
>> with C++14?
>>
> I can't give you a single link. This is my theory as I have some knowledge
> in compiler writing. As C++14-constexpr is basically a compile time
> interpreted C++ language, and such a thing is needs an intermediate
> representation.
>

An intermediate representation is not the same thing as an AST. A compiler
that sees a constexpr function definition could store some kind of
constexpr bytecode that is not suitable for any other purpose.


>  >
>
>> > I think the TMP debugging is not a tooling problem. Debugging a
>> functional
>> > style language is quite different than debugging a procedural style
>> > language. Its an other skill set.
>>
>> And that's no different from debugging your proposed syntax. Debugging
>> the code
>> generator is quite different from regular debugging of generated
>> (compiled)
>> code. Your argument is that the syntax is procedural, but it leaves
>> unaddressed the fact that it happens at a completely different time,
>> requiring
>> completely different tools, and it affects the program in completely
>> different
>> ways.
>>
> You are right that debugging a code generator will be a new thing. But the
> code generator itself will be a regular procedural process.
> I don't know how to debug such a new thing as the new thing (the code
> generator) is not exists at the moment but yeah it must be a priority in
> design.
>
>
>
>>
>> Now, I will agree that figuring out why TMP code isn't compiling as
>> expected is
>> difficult. Whether it is more so or less so than the proposed new syntax,
>> it's
>> impossible to tell until there are mature implementations and a year or
>> two of
>> experience.
>>
>> I think nobody want a new undebuggable code bloat.
>
> 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/.
>

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, May 11, 2015 at 6:25 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:hun.n=
emethpeter@gmail.com" target=3D"_blank">hun.nemethpeter@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, =
May 11, 2015 at 11:56:35 AM UTC+2, Thiago Macieira wrote:<span class=3D""><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">On Monday 11 May 2015 01:57:20 <a re=
l=3D"nofollow">hun.nem...@gmail.com</a> wrote:
<br>&gt; And I think for a proper C++14 constexpr implementation an AST bas=
ed=20
<br>&gt; approach is needed for compilers.
<br>
<br>Do you have any evidence that a non-AST compiler is unable to be compli=
ant=20
<br>with C++14?
<br></blockquote></span><div>I can&#39;t give you a single link. This is my=
 theory as I have some knowledge in compiler writing. As C++14-constexpr is=
 basically a compile time interpreted C++ language, and such a thing is nee=
ds an intermediate representation.</div></div></blockquote><div><br></div><=
div>An intermediate representation is not the same thing as an AST. A compi=
ler that sees a constexpr function definition could store some kind of cons=
texpr bytecode that is not suitable for any other purpose.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><div=
>=C2=A0&gt;=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; I think=
 the TMP debugging is not a tooling problem. Debugging a functional=20
<br>&gt; style language is quite different than debugging a procedural styl=
e=20
<br>&gt; language. Its an other skill set.
<br>
<br>And that&#39;s no different from debugging your proposed syntax. Debugg=
ing the code=20
<br>generator is quite different from regular debugging of generated (compi=
led)=20
<br>code. Your argument is that the syntax is procedural, but it leaves=20
<br>unaddressed the fact that it happens at a completely different time, re=
quiring=20
<br>completely different tools, and it affects the program in completely di=
fferent=20
<br>ways.
<br></blockquote></span><div>You are right that debugging a code generator =
will be a new thing. But the code generator itself will be a regular proced=
ural process.</div><div>I don&#39;t know how to debug such a new thing as t=
he new thing (the code generator) is not exists at the moment but yeah it m=
ust be a priority in design.</div><span class=3D""><div><br></div><div>=C2=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>Now, I will agree that figuring out why TMP code isn&#39;t compiling as=
 expected is=20
<br>difficult. Whether it is more so or less so than the proposed new synta=
x, it&#39;s=20
<br>impossible to tell until there are mature implementations and a year or=
 two of=20
<br>experience.
<br><br></blockquote></span><div>I think nobody want a new undebuggable cod=
e bloat.</div><div><br></div><div>Peter=C2=A0</div></div><div class=3D"HOEn=
Zb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--001a11c204fabe42f00515d11c91--

.

------=_Part_642_1516541475.1431364673910
Content-Type: multipart/alternative;
 boundary="----=_Part_643_29164082.1431364673910"

------=_Part_643_29164082.1431364673910
Content-Type: text/plain; charset=UTF-8


> And I think for a proper C++14 constexpr implementation an AST based

> > approach is needed for compilers.
>>>
>>> Do you have any evidence that a non-AST compiler is unable to be
>>> compliant
>>> with C++14?
>>>
>> I can't give you a single link. This is my theory as I have some
>> knowledge in compiler writing. As C++14-constexpr is basically a compile
>> time interpreted C++ language, and such a thing is needs an intermediate
>> representation.
>>
>
> An intermediate representation is not the same thing as an AST. A compiler
> that sees a constexpr function definition could store some kind of
> constexpr bytecode that is not suitable for any other purpose.
>

Yeah, it's true, but in that case they can emit debug info for their
constexpr bytecode. On the other hand a pure bytecode approach isn't really
practical for meaningful compiler errors.

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

<div dir=3D"ltr"><br>&gt; And I think for a proper C++14 constexpr implemen=
tation an AST based=20
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><spa=
n><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">&gt; approach is needed for compi=
lers.
<br>
<br>Do you have any evidence that a non-AST compiler is unable to be compli=
ant=20
<br>with C++14?
<br></blockquote></span><div>I can't give you a single link. This is my the=
ory as I have some knowledge in compiler writing. As C++14-constexpr is bas=
ically a compile time interpreted C++ language, and such a thing is needs a=
n intermediate representation.</div></div></blockquote><div><br></div><div>=
An intermediate representation is not the same thing as an AST. A compiler =
that sees a constexpr function definition could store some kind of constexp=
r bytecode that is not suitable for any other purpose.</div></div></div></d=
iv></blockquote><br>Yeah, it's true, but in that case they can emit debug i=
nfo for their constexpr bytecode. On the other hand a pure bytecode approac=
h isn't really practical for meaningful compiler errors.<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_643_29164082.1431364673910--
------=_Part_642_1516541475.1431364673910--

.

On Monday 11 May 2015 09:45:57 Richard Smith wrote:
> On Mon, May 11, 2015 at 6:25 AM, <hun.nemethpeter@gmail.com> wrote:
> > On Monday, May 11, 2015 at 11:56:35 AM UTC+2, Thiago Macieira wrote:
> >> On Monday 11 May 2015 01:57:20 hun.nem...@gmail.com wrote:
> >> > And I think for a proper C++14 constexpr implementation an AST based
> >> > approach is needed for compilers.
> >>
> >> Do you have any evidence that a non-AST compiler is unable to be
> >> compliant
> >> with C++14?
> >
> > I can't give you a single link. This is my theory as I have some knowledge
> > in compiler writing. As C++14-constexpr is basically a compile time
> > interpreted C++ language, and such a thing is needs an intermediate
> > representation.

Also note that the standard does not require that constexpr variables result
in statically initialised, read-only data. It only requires that they be
evaluated prior to any dynamic initialisation. So it's perfectly valid for the
compiler to use exactly the same machinery as it already has for that case and
simply insert an extra initialisation pass. This includes even
static_assertions.

The one case I can think of that requires compile time evaluation is non-
evaluated contexts: the result of a constexpr function can be used in the
template's parameter list or in an array's size.

> An intermediate representation is not the same thing as an AST. A compiler
> that sees a constexpr function definition could store some kind of
> constexpr bytecode that is not suitable for any other purpose.

Or straight machine code. The compiler already knows how to do that.

So no, I see no evidence at all that constexpr implies AST sine qua non.
--
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

--

---
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_6697_335708005.1431445994998
Content-Type: multipart/alternative;
 boundary="----=_Part_6698_804899366.1431445994998"

------=_Part_6698_804899366.1431445994998
Content-Type: text/plain; charset=UTF-8

On Monday, May 11, 2015 at 10:17:54 AM UTC-7, hun.nem...@gmail.com wrote:
>
>
> Yeah, it's true, but in that case they can emit debug info for their
> constexpr bytecode. On the other hand a pure bytecode approach isn't really
> practical for meaningful compiler errors.
>

Which first off isn't true (all modern well-designed IR's can contain debug
info, and must, because the actual final executable's debug info is
provided by the IR) and second off you'll find that debug info isn't a part
of the C++ standard either; there's no requirement for a
standards-compliant compiler to produce runtime debug information (which is
why an optimizing compiler with debug info turned off is still standard
compliant).

Again, there may well be benefit to making it part of the standard, but you
have to win that battle first, then build up over a series of battles to an
"AST library."

If we're going to talk about a standardized "API" for C++, it would be
beneficial to again take a step back and stop over-concentrating on a
single feature. What about a Compiler-as-a-Service as part of standard C++?
What about being able to write embedded documentation parsers or
hand-rolled static reflection systems as part of standard C++? Static
analysis tools using only standard C++? etc. There are a ton of uses for
something like a standardized libclang that go far and beyond just having
hygienic macro support; explore all those use cases.

A good first step may be to just write a paper that doesn't actually
propose a feature but rather just outlines the myriad use cases for the
feature, gather feedback and interest from the actual committee (rather
than the mere 2-3 committee members and non-committee members commenting
here), and then _with that feedback_ start exploring how to actually
implement the feature in a way that the committee indicates they'd like.
They might hate the idea of a new macro language but love the idea of a
standardized libclang, or they might love the idea of a standardized AST
interface despite what we're saying, or they might suggest some other ideas
that nobody here is bringing up.

See papers like the following, which don't propose an actual feature or
language change, but just outline some desired use cases or problems or
even just try to educate the committee on a specific topic. Some of them
outline suggestions or ideas, but loosely and without the idea itself being
the decision point of the paper. A feature (esp. a big feature like
hygienic macros!) is going to take many, many revisions of a paper and
likely years to get through from idea to part of a released standard, so
you might as well start off just by seeing if the problem is even something
the committee wants to solve before delving anywhere near implementation
specifics.

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4110.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4176.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4376.html
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4452.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4456.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3825.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3872.pdf
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4055.html

--

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

<div dir=3D"ltr">On Monday, May 11, 2015 at 10:17:54 AM UTC-7, hun.nem...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><br>Yeah, it's true, but in that case they can emit debug info for their =
constexpr bytecode. On the other hand a pure bytecode approach isn't really=
 practical for meaningful compiler errors.<br></div></blockquote><div><br><=
/div><div>Which first off isn't true (all modern well-designed IR's can con=
tain debug info, and must, because the actual final executable's debug info=
 is provided by the IR) and second off you'll find that debug info isn't a =
part of the C++ standard either; there's no requirement for a standards-com=
pliant compiler to produce runtime debug information (which is why an optim=
izing compiler with debug info turned off is still standard compliant).</di=
v><div><br></div><div>Again, there may well be benefit to making it part of=
 the standard, but you have to win that battle first, then build up over a =
series of battles to an "AST library."</div><div><br></div><div>If we're go=
ing to talk about a standardized "API" for C++, it would be beneficial to a=
gain take a step back and stop over-concentrating on a single feature. What=
 about a Compiler-as-a-Service as part of standard C++? What about being ab=
le to write embedded documentation parsers or hand-rolled static reflection=
 systems as part of standard C++? Static analysis tools using only standard=
 C++? etc. There are a ton of uses for something like a standardized libcla=
ng that go far and beyond just having hygienic macro support; explore all t=
hose use cases.</div><div><br></div><div>A good first step may be to just w=
rite a paper that doesn't actually propose a feature but rather just outlin=
es the myriad use cases for the feature, gather feedback and interest from =
the actual committee (rather than the mere 2-3 committee members and non-co=
mmittee members commenting here), and then _with that feedback_ start explo=
ring how to actually implement the feature in a way that the committee indi=
cates they'd like. They might hate the idea of a new macro language but lov=
e the idea of a standardized libclang, or they might love the idea of a sta=
ndardized AST interface despite what we're saying, or they might suggest so=
me other ideas that nobody here is bringing up.</div><div><br></div><div>Se=
e papers like the following, which don't propose an actual feature or langu=
age change, but just outline some desired use cases or problems or even jus=
t try to educate the committee on a specific topic. Some of them outline su=
ggestions or ideas, but loosely and without the idea itself being the decis=
ion point of the paper. A feature (esp. a big feature like hygienic macros!=
) is going to take many, many revisions of a paper and likely years to get =
through from idea to part of a released standard, so you might as well star=
t off just by seeing if the problem is even something the committee wants t=
o solve before delving anywhere near implementation specifics.</div><div><b=
r></div><div>http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4110.pdf<=
br></div><div>http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4176.pdf=
<br></div><div>http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4376.ht=
ml<br></div><div>http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4452.=
pdf<br></div><div>http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4456=
..pdf<br></div><div>http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n382=
5.pdf<br></div><div>http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n38=
72.pdf<br></div><div>http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4=
055.html<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_6698_804899366.1431445994998--
------=_Part_6697_335708005.1431445994998--

.

------=_Part_6513_1485039554.1431450570248
Content-Type: multipart/alternative;
 boundary="----=_Part_6514_1004838644.1431450570249"

------=_Part_6514_1004838644.1431450570249
Content-Type: text/plain; charset=UTF-8



> Yeah, it's true, but in that case they can emit debug info for their
>> constexpr bytecode. On the other hand a pure bytecode approach isn't really
>> practical for meaningful compiler errors.
>>
>
> Which first off isn't true (all modern well-designed IR's can contain
> debug info, and must, because the actual final executable's debug info is
> provided by the IR) and second off you'll find that debug info isn't a part
> of the C++ standard either; there's no requirement for a
> standards-compliant compiler to produce runtime debug information (which is
> why an optimizing compiler with debug info turned off is still standard
> compliant).
>
At that case every info is in place so what is the problem then? What I
propose is to compile time filling AST like objects that is available for
constexpr object.

I detailed what objects are generated during compile time in this file:
https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/main.cc

and the clang implementation do the same thing.

So for
 static_assert(typeid<Test>.name() == "Test", "");

the following source is generated:
namespace std {
    namespace reflection {
        static const std::ast::ast_identifier id_member1("member1");
        static const std::ast::ast_var class_Test_var_member1(type_bool,
id_member1);
        ...
        static const std::ast::ast_var
class_Test_var_member16(type_long_double, id_member16);
        static const std::ast::ast_identifier id_Test("Test");
        static const std::ast::ast_decl *const class_Test_members[16] =
{&class_Test_var_member1, ... , &class_Test_var_member16};
        static const std::ast::ast_class class_Test(id_Test,
class_Test_members);
}

And typeid<Test> will be a reference to std::reflection::class_Test. Ok.
the naming scheme is just an ad-hoc now but that all.



> Again, there may well be benefit to making it part of the standard, but
> you have to win that battle first, then build up over a series of battles
> to an "AST library."
>
Such an AST library is ready to use. Just look at the
https://parasol.tamu.edu/pivot/ site. I just created a constexpr version
from it in my spare time.



>
> If we're going to talk about a standardized "API" for C++, it would be
> beneficial to again take a step back and stop over-concentrating on a
> single feature. What about a Compiler-as-a-Service as part of standard C++?
> What about being able to write embedded documentation parsers or
> hand-rolled static reflection systems as part of standard C++? Static
> analysis tools using only standard C++? etc. There are a ton of uses for
> something like a standardized libclang that go far and beyond just having
> hygienic macro support; explore all those use cases.
>
So if I want a feature I want more feature also and... hm... what is the
problem with this?



>
> A good first step may be to just write a paper that doesn't actually
> propose a feature but rather just outlines the myriad use cases for the
> feature, gather feedback and interest from the actual committee (rather
> than the mere 2-3 committee members and non-committee members commenting
> here), and then _with that feedback_ start exploring how to actually
> implement the feature in a way that the committee indicates they'd like.
> They might hate the idea of a new macro language but love the idea of a
> standardized libclang, or they might love the idea of a standardized AST
> interface despite what we're saying, or they might suggest some other ideas
> that nobody here is bringing up.
>
This topic started from an idea that is come from my N3883 paper which is
an answer for N3814.


>
> See papers like the following, which don't propose an actual feature or
> language change, but just outline some desired use cases or problems or
> even just try to educate the committee on a specific topic. Some of them
> outline suggestions or ideas, but loosely and without the idea itself being
> the decision point of the paper. A feature (esp. a big feature like
> hygienic macros!) is going to take many, many revisions of a paper and
> likely years to get through from idea to part of a released standard, so
> you might as well start off just by seeing if the problem is even something
> the committee wants to solve before delving anywhere near implementation
> specifics.
>
What I want is to get a descriptor object from code and inject back to the
code.


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

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Yeah, it'=
s true, but in that case they can emit debug info for their constexpr bytec=
ode. On the other hand a pure bytecode approach isn't really practical for =
meaningful compiler errors.<br></div></blockquote><div><br></div><div>Which=
 first off isn't true (all modern well-designed IR's can contain debug info=
, and must, because the actual final executable's debug info is provided by=
 the IR) and second off you'll find that debug info isn't a part of the C++=
 standard either; there's no requirement for a standards-compliant compiler=
 to produce runtime debug information (which is why an optimizing compiler =
with debug info turned off is still standard compliant).</div></div></block=
quote><div>At that case every info is in place so what is the problem then?=
 What I propose is to compile time filling AST like objects that is availab=
le for constexpr object.<br><br>I detailed what objects are generated durin=
g compile time in this file:<br><a href=3D"https://github.com/hun-nemethpet=
er/cpp-reflector-mini/blob/master/constexpr-ast/main.cc">https://github.com=
/hun-nemethpeter/cpp-reflector-mini/blob/master/constexpr-ast/main.cc<br></=
a><br>and the clang implementation do the same thing.<br><br>So for <br>&nb=
sp;static_assert(typeid&lt;Test&gt;.name() =3D=3D "Test", "");<br><br>the f=
ollowing source is generated:<br>namespace std {<br>&nbsp;&nbsp;&nbsp; name=
space reflection {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; static con=
st std::ast::ast_identifier id_member1("member1");<br>&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; static const std::ast::ast_var class_Test_var_member1=
(type_bool, id_member1);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<=
br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; static const std::ast::ast_va=
r class_Test_var_member16(type_long_double, id_member16);<br>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; static const std::ast::ast_identifier id_Test(=
"Test");<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; static const std::as=
t::ast_decl *const class_Test_members[16] =3D {&amp;class_Test_var_member1,=
 ... , &amp;class_Test_var_member16};<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; static const std::ast::ast_class class_Test(id_Test, class_Test_me=
mbers); <br>}<br><br>And typeid&lt;Test&gt; will be a reference to std::ref=
lection::class_Test. Ok. the naming scheme is just an ad-hoc now but that a=
ll.<br>&nbsp;<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div><br></div><div>Again, there may well be benefit to makin=
g it part of the standard, but you have to win that battle first, then buil=
d up over a series of battles to an "AST library."</div></div></blockquote>=
<div>Such an AST library is ready to use. Just look at the <a href=3D"https=
://parasol.tamu.edu/pivot/">https://parasol.tamu.edu/pivot/</a> site. I jus=
t created a constexpr version from it in my spare time.<br><br>&nbsp;</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></di=
v><div>If we're going to talk about a standardized "API" for C++, it would =
be beneficial to again take a step back and stop over-concentrating on a si=
ngle feature. What about a Compiler-as-a-Service as part of standard C++? W=
hat about being able to write embedded documentation parsers or hand-rolled=
 static reflection systems as part of standard C++? Static analysis tools u=
sing only standard C++? etc. There are a ton of uses for something like a s=
tandardized libclang that go far and beyond just having hygienic macro supp=
ort; explore all those use cases.</div></div></blockquote><div>So if I want=
 a feature I want more feature also and... hm... what is the problem with t=
his?<br><br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><br></div><div>A good first step may be to just write a pap=
er that doesn't actually propose a feature but rather just outlines the myr=
iad use cases for the feature, gather feedback and interest from the actual=
 committee (rather than the mere 2-3 committee members and non-committee me=
mbers commenting here), and then _with that feedback_ start exploring how t=
o actually implement the feature in a way that the committee indicates they=
'd like. They might hate the idea of a new macro language but love the idea=
 of a standardized libclang, or they might love the idea of a standardized =
AST interface despite what we're saying, or they might suggest some other i=
deas that nobody here is bringing up.</div></div></blockquote><div>This top=
ic started from an idea that is come from my N3883 paper which is an answer=
 for N3814.<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><br></div><div>See papers like the following, which =
don't propose an actual feature or language change, but just outline some d=
esired use cases or problems or even just try to educate the committee on a=
 specific topic. Some of them outline suggestions or ideas, but loosely and=
 without the idea itself being the decision point of the paper. A feature (=
esp. a big feature like hygienic macros!) is going to take many, many revis=
ions of a paper and likely years to get through from idea to part of a rele=
ased standard, so you might as well start off just by seeing if the problem=
 is even something the committee wants to solve before delving anywhere nea=
r implementation specifics.</div></div></blockquote><div>What I want is to =
get a descriptor object from code and inject back to the code.<br>&nbsp;<br=
><br></div>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_6514_1004838644.1431450570249--
------=_Part_6513_1485039554.1431450570248--

.