------=_Part_2797_6417608.1403621647549
Content-Type: text/plain; charset=UTF-8



It would be nice to have a statement expansion in C++17.

Here is an example of a switch generation based on the list of "case"
classes,
which defines mapping integer values to types.

template <class T>
void ImpFunc();

template <int Val_,class T>
struct Case
 {
  const int Val = Val_ ;

  using Type = T ;
 };

template <class ... CC>
void SwitchFunc(int key)
 {
  switch( key )
    {
     *{* case CC::Val : ImpFunc<typename CC::Type>(); break;
*}...*    }
 }

.....

int key;

.....

SwitchFunc< Case<1,T1> , Case<2,T2> , Case<3,T3> >(key);

In the given example the statement, enclosed in the brackets *{ }...* is
expanded according the given template
parameter list.

--

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

<div dir=3D"ltr"><p>It would be nice to have a statement expansion in C++17=
..</p><p>Here is an example of a switch generation based on the list of "cas=
e" classes, <br>which defines mapping integer values to types.</p><p><font =
color=3D"#0000ff" face=3D"courier new,monospace" size=3D"4">template &lt;cl=
ass T&gt;<br>void ImpFunc();</font></p><p><font color=3D"#0000ff" face=3D"c=
ourier new,monospace" size=3D"4">template &lt;int Val_,class T&gt; <br>stru=
ct Case<br>&nbsp;{<br>&nbsp; const int Val =3D Val_ ; </font></p><p><font c=
olor=3D"#0000ff" face=3D"courier new,monospace" size=3D"4">&nbsp; using Typ=
e =3D T ;<br>&nbsp;};</font></p><p><font color=3D"#0000ff" face=3D"courier =
new,monospace" size=3D"4">template &lt;class ... CC&gt;<br>void SwitchFunc(=
int key)<br>&nbsp;{ <br>&nbsp; switch( key )<br>&nbsp;&nbsp;&nbsp; {<br>&nb=
sp;&nbsp;&nbsp;&nbsp; <strong>{</strong> case CC::Val : ImpFunc&lt;typename=
 CC::Type&gt;(); break; <strong>}...<br></strong>&nbsp;&nbsp;&nbsp; }<br>&n=
bsp;}</font></p><p><font color=3D"#0000ff" face=3D"courier new,monospace" s=
ize=3D"4">....</font></p><p><font color=3D"#0000ff" face=3D"courier new,mon=
ospace" size=3D"4">int key;</font></p><p><font color=3D"#0000ff" face=3D"co=
urier new,monospace" size=3D"4">....</font></p><p><font color=3D"#0000ff" f=
ace=3D"courier new,monospace" size=3D"4">SwitchFunc&lt; Case&lt;1,T1&gt; , =
Case&lt;2,T2&gt; , Case&lt;3,T3&gt; &gt;(key);</font></p><p>In the given ex=
ample the statement, enclosed in the brackets <strong>{ }...</strong> is ex=
panded according the given template<br>parameter list.<br></p></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_2797_6417608.1403621647549--

.

How about declarations?

(For example, template<typename...Base> struct Thing : Base... { using
Base::foo;... }; to have 'using Base::foo;' for every Base.)

2014-06-24 16:54 GMT+02:00  <sshimnick@hotmail.com>:
> It would be nice to have a statement expansion in C++17.
>
> Here is an example of a switch generation based on the list of "case"
> classes,
> which defines mapping integer values to types.
>
> template <class T>
> void ImpFunc();
>
> template <int Val_,class T>
> struct Case
>  {
>   const int Val = Val_ ;
>
>   using Type = T ;
>  };
>
> template <class ... CC>
> void SwitchFunc(int key)
>  {
>   switch( key )
>     {
>      { case CC::Val : ImpFunc<typename CC::Type>(); break; }...
>     }
>  }
>
> ....
>
> int key;
>
> ....
>
> SwitchFunc< Case<1,T1> , Case<2,T2> , Case<3,T3> >(key);
>
> In the given example the statement, enclosed in the brackets { }... is
> expanded according the given template
> parameter list.
>
> --
>
> ---
> 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/.

.

On 24 June 2014 21:20, Maurice Bos <m-ou.se@m-ou.se> wrote:
> How about declarations?
>
> (For example, template<typename...Base> struct Thing : Base... { using
> Base::foo;... }; to have 'using Base::foo;' for every Base.)

This one is old news, http://cplusplus.github.io/EWG/ewg-active.html#102
is supported by EWG and will proceed further.

There's currently no accepted proposal/idea for statement expansions, but
there is ongoing for for expression expansions.

--

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

.

If i remember correctly, the support was for "using Pack...;" (by
allowing "using A, B, C;"), not for "using Pack;..." (which would mean
"using A; using B; using C;", and would work for other declarations
too).

2014-06-24 20:22 GMT+02:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 24 June 2014 21:20, Maurice Bos <m-ou.se@m-ou.se> wrote:
>> How about declarations?
>>
>> (For example, template<typename...Base> struct Thing : Base... { using
>> Base::foo;... }; to have 'using Base::foo;' for every Base.)
>
> This one is old news, http://cplusplus.github.io/EWG/ewg-active.html#102
> is supported by EWG and will proceed further.
>
> There's currently no accepted proposal/idea for statement expansions, but
> there is ongoing for for expression expansions.
>
> --
>
> ---
> 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/.

.

--Apple-Mail=_0E72FA00-F632-4EFF-B1DC-7BC8B443F9FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-25, at 2:22 AM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> There's currently no accepted proposal/idea for statement expansions, but
> there is ongoing for for expression expansions.

Where? A quick scan of EWG issues and paper titles only turns up using-decl=
aration and pack accessor extensions.

I recall discussion of expression expansions on this list, but it didn't go=
 anywhere as nobody could make a strong case for a particular meaning -- it=
's half a solution, in search of a problem.

The one meaning which would be clear is the comma operator, but that's bett=
er covered by the semicolon as in this proposal.

To the OP and anyone else in favor: Please exclude labeled-statements from =
pattern compound-statements.

{ case N: blah(); } ... // OK (N is a pack).
case N: { blah(); } ... // Error: unexpanded pack, ellipsis expands nothing=
..
case some_constant: { blah(); } ... // Error: repeated label.

This will perhaps result from natural grammatical specification, but the di=
stinction deserves mention in the proposal. The case with no unexpanded pac=
k in the label should be diagnosed at parse time, not only when the expansi=
on produces an ill-formed duplicate label.

Also, I thought I'd posted this earlier, but I don't see it now: Please don=
't include declarations in this proposal, because the semantics are unclear=
.. Adding a crazy element to a clear and obvious proposal will only sink the=
 good part.

The requirement of braces, or a compound-expression, nicely prevents pack-g=
enerated declarations from leaking into the enclosing scope. I prefer this =
to simply forbidding declaration-statements. For example, you wouldn't want=
 the ellipsis to transform a declaration into an expression by the ambiguit=
y rule.

--=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=_0E72FA00-F632-4EFF-B1DC-7BC8B443F9FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;25, at 2:22 AM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">There's cur=
rently no accepted proposal/idea for statement expansions, but<br>there is =
ongoing for for expression expansions.<br></blockquote></div><br><div>Where=
? A quick scan of EWG issues and paper titles only turns up using-declarati=
on and pack accessor extensions.</div><div><br></div><div>I recall discussi=
on of expression expansions on this list, but it didn&rsquo;t go anywhere a=
s nobody could make a strong case for a particular meaning &mdash; it&rsquo=
;s half a solution, in search of a problem.</div><div><br></div><div>The on=
e meaning which would be clear is the comma operator, but that&rsquo;s bett=
er covered by the semicolon as in this proposal.</div><div><br></div><div>T=
o the OP and anyone else in favor: Please exclude labeled-statements from p=
attern compound-statements.</div><div><br></div><div><font face=3D"Courier"=
>{ case N: blah(); } ... // OK (N is a pack).</font></div><div><font face=
=3D"Courier">case N: { blah(); } ... // Error: unexpanded pack, ellipsis ex=
pands nothing.</font></div><div><font face=3D"Courier">case some_constant: =
{ blah(); } ... // Error: repeated label.</font></div><div><br></div><div>T=
his will perhaps result from natural grammatical specification, but the dis=
tinction deserves mention in the proposal. The case with no unexpanded pack=
 in the label should be diagnosed at parse time, not only when the expansio=
n produces an ill-formed duplicate label.</div><div><br></div><div>Also, I =
thought I&rsquo;d posted this earlier, but I don&rsquo;t see it now: Please=
 don&rsquo;t&nbsp;include declarations in this proposal, because the semant=
ics are unclear. Adding a crazy element to a clear and obvious proposal wil=
l only sink the good part.</div><div><br></div><div>The requirement of brac=
es, or a compound-expression, nicely prevents pack-generated declarations f=
rom leaking into the enclosing scope. I prefer this to simply forbidding de=
claration-statements. For example, you wouldn&rsquo;t want the ellipsis to =
transform a declaration into an expression by the ambiguity rule.</div><div=
><br></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=_0E72FA00-F632-4EFF-B1DC-7BC8B443F9FC--

.

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



On Friday, June 27, 2014 7:00:33 AM UTC+4, David Krauss wrote:
>
>
> To the OP and anyone else in favor: *Please exclude labeled-statements=20
> from pattern compound-statements.*
>
> { case N: blah(); } ... // OK (N is a pack).
> case N: { blah(); } ... // Error: unexpanded pack, ellipsis expands=20
> nothing.
> case some_constant: { blah(); } ... // Error: repeated label.
>
> *This will perhaps result from natural grammatical specification, but the=
=20
> distinction deserves mention in the proposal.* The case with no=20
> unexpanded pack in the label should be diagnosed at parse time, not only=
=20
> when the expansion produces an ill-formed duplicate label.
>
> Also, I thought I=E2=80=99d posted this earlier, but I don=E2=80=99t see =
it now: *Please=20
> don=E2=80=99t include declarations in this proposal, because the semantic=
s are=20
> unclear.* Adding a crazy element to a clear and obvious proposal will=20
> only sink the good part.
>
> The requirement of braces, or a compound-expression, nicely prevents=20
> pack-generated declarations from leaking into the enclosing scope. I pref=
er=20
> this to simply forbidding declaration-statements. For example, you wouldn=
=E2=80=99t=20
> want the ellipsis to transform a declaration into an expression by the=20
> ambiguity rule.
>
> =20
Good points.

=20

--=20

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

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

<br><br>On Friday, June 27, 2014 7:00:33 AM UTC+4, David Krauss wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;"><div style=3D"-ms-word-wrap: break-word;"><br><div>=
To the OP and anyone else in favor: <strong>Please exclude labeled-statemen=
ts from pattern compound-statements.</strong></div><div><br></div><div><fon=
t face=3D"Courier">{ case N: blah(); } ... // OK (N is a pack).</font></div=
><div><font face=3D"Courier">case N: { blah(); } ... // Error: unexpanded p=
ack, ellipsis expands nothing.</font></div><div><font face=3D"Courier">case=
 some_constant: { blah(); } ... // Error: repeated label.</font></div><div>=
<br></div><div><strong>This will perhaps result from natural grammatical sp=
ecification, but the distinction deserves mention in the proposal.</strong>=
 The case with no unexpanded pack in the label should be diagnosed at parse=
 time, not only when the expansion produces an ill-formed duplicate label.<=
/div><div><br></div><div>Also, I thought I=E2=80=99d posted this earlier, b=
ut I don=E2=80=99t see it now: <strong>Please don=E2=80=99t&nbsp;include de=
clarations in this proposal, because the semantics are unclear.</strong> Ad=
ding a crazy element to a clear and obvious proposal will only sink the goo=
d part.</div><div><br></div><div>The requirement of braces, or a compound-e=
xpression, nicely prevents pack-generated declarations from leaking into th=
e enclosing scope. I prefer this to simply forbidding declaration-statement=
s. For example, you wouldn=E2=80=99t want the ellipsis to transform a decla=
ration into an expression by the ambiguity rule.</div><div><br></div></div>=
</blockquote><div>&nbsp;</div><div>Good points.</div><div><br></div><div>&n=
bsp;</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_911_7285596.1403933395400--

.

--Apple-Mail=_7BEEC912-F3A9-4ABA-9989-6FAA91E15794
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-28, at 1:29 PM, sshimnick@hotmail.com wrote:

> On Friday, June 27, 2014 7:00:33 AM UTC+4, David Krauss wrote:
>
> case some_constant: { blah(); } ... // Error: repeated label.
>
> Good points.

Whoops, that line is missing a pack, if you're going to recycle this example it should be

case some_constant: { N; } ...

--

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

--Apple-Mail=_7BEEC912-F3A9-4ABA-9989-6FAA91E15794
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;28, at 1:29 PM, <a href=3D"mailto:sshimnick@hotmail.com">ssh=
imnick@hotmail.com</a> wrote:</div><br><blockquote type=3D"cite">On Friday,=
 June 27, 2014 7:00:33 AM UTC+4, David Krauss wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid; position: static; z-index: auto;"><div style=3D"-ms-word-wrap: break-w=
ord;"><br><div><span style=3D"font-family: Courier;">case some_constant: { =
blah(); } ... // Error: repeated label.</span></div><div>&nbsp;</div></div>=
</blockquote><div>Good points.</div></blockquote><br></div><div>Whoops, tha=
t line is missing a pack, if you&rsquo;re going to recycle this example it =
should be&nbsp;</div><div><br></div><div><font face=3D"Courier">case some_c=
onstant: { N; } ...</font></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=_7BEEC912-F3A9-4ABA-9989-6FAA91E15794--

.

On 06/26/2014 10:00 PM, David Krauss wrote:
[snip]

 > Please don=E2=80=99t include declarations in this proposal,
 > because the semantics are unclear. Adding a crazy element
 > to a clear and obvious proposal will only sink the good
 > part.

 > The requirement of braces, or a compound-expression, nicely
 > prevents pack-generated declarations from leaking into the
 > enclosing scope. I prefer this to simply forbidding
 > declaration-statements. For example, you wouldn=E2=80=99t want the
 > ellipsis to transform a declaration into an expression by
 > the ambiguity rule.
 >
[snip]

David, could you provide an example where declaration
expansion semantics are unclear.  I curious because there is
one use case where declaration expansion into the enclosing
scope would be useful.  The BOOST_SPIRIT_DEFINE_ and
BOOST_SPIRIT_DEFINE macros here:

https://github.com/boostorg/spirit/blob/x3-devel/include/boost/spirit/home/=
x3/nonterminal/rule.hpp#L159

"expand" several overloaded parse_rule
declaration/definitions into the enclosing scope.  The
BOOST_SPIRIT_DEFINE macro use is shown here:

https://github.com/boostorg/spirit/blob/x3-devel/example/x3/calc4c/grammar.=
cpp#L36

which expands into:

   template<typename Iterator, typename Context>
   inline bool parse_rule
     ( x3::rule<class expression, ast::program> rule_
     , ...){...}
   template<typename Iterator, typename Context>
   inline bool parse_rule
     ( x3::rule<class term, ast::program> rule_
     , ...){...}
   template<typename Iterator, typename Context>
   inline bool parse_rule
     ( x3::rule<class factor, ast::operand> rule_
     , ...){...}

(For those curious about the reasons why overloaded
parse_rule functions are needed, the vastly simplified
code here:

https://gist.github.com/cppljevans/3d3bec54be8f3d0c4d8b94af84a6e529

and in particular, the comments around BOOST_SPIRIT_DEFINE_
on line 198 should, hopefully, make the reasons clear.
)

Now, in order to replace the BOOST_SPIRIT_DEFINE* macros
with some new "statement expansion" syntax, I guess
something like the following (where namespace keyword is
"re-used" with a new context dependent meaning) would work:

   template<typename... T>
   namespace my_stmt_exp(T... arg)
   {
     stmt_to_exp[T|arg]...
   }

where stmt_to_exp[T|arg] means some statements, including
possibly declarations, with occurrences of T and|or args.
This would inject the stmt_to_exp[T|arg]... into the current
scope.

With something like this, the BOOST_SPIRIT_DEFINE macro
definition could be replaced with:

   template<typename... RuleDef>
   namespace boost_spirit_define(RuleDef... def)
   {
     template <typename Iterator, typename Context, typename Attribute>=20

     inline bool parse_rule(=20

         decltype(def)::lhs_type rule_=20

       , Iterator& first, Iterator const& last=20

       , Context const& context, Attribute& attr)=20

     {=20

         using boost::spirit::x3::unused;=20

         auto const& def_ =3D (def);=20

         return def_.parse(first, last, context, unused, attr);=20

     }...  //expand parse_rule overloads into enclosing scope.
   }

which would allow replacement of the BOOST_SPIRIT_DEFINE
macro use here:

https://github.com/boostorg/spirit/blob/x3-devel/example/x3/calc4c/grammar.=
cpp#L36

with:

   boost_spirit_define(
             expression =3D
                 term
                 >> *(   (char_('+') >> term)
                     |   (char_('-') >> term)
                     )
                 ,

             term =3D
                 factor
                 >> *(   (char_('*') >> factor)
                     |   (char_('/') >> factor)
                     )
                 ,

             factor =3D
                     uint_
                 |   '(' >> expression >> ')'
                 |   (char_('-') >> factor)
                 |   (char_('+') >> factor)
         );

Are there any problems with that?

-regards,
Larry


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

.