------=_Part_317_388735170.1535647375557
Content-Type: multipart/alternative;
 boundary="----=_Part_318_1238977075.1535647375558"

------=_Part_318_1238977075.1535647375558
Content-Type: text/plain; charset="UTF-8"

Here is a write up for a language feature that I would like to have
considered:

https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb

I'm attempting to implement it in Clang, but I would like to get some early
feedback.

I've already received some feedback from Louis Dionne and he encouraged me
to post it here.


Thanks!



# Parametric Expression

The primary purpose here is to improve compile-time performance by
providing a tool that augments existing
metaprogramming features in C++. It involves the transformation of
expressions.

Essentially this feature is meant to combine the power of function
templates with the performance of type
aliases. Function templates as we have them now are loaded with features
such as overloading, constraints,
type deduction, SFINAE, ect.. When called not only do we get an expensive
template instantiation but also
potentially large symbols and extraneous code generation all for functions
we wouldn't call otherwise
unless we expected the optimizer to inline them out anyways. With this tool
we want to give programmers
the ability to allow this inlining at an earlier stage, but the solution is
elegant enough to provide a
few additional bonus features.

Consider the following declaration syntax:

```cpp
using add(auto a, auto b) {
  return a + b;
}
```

Here is a function-like declaration where the domain and codomain are
expressions.

Invoking it merely transforms the expression in the context of the site of
invocation.

```cpp
int main() {
  return add(40, 2);
}

// the same as

int main() {
  return 40 + 2;
}
```

This ability to transform expressions has the same power as type aliases,
but here we can work with
constructs that have run-time effects as seen in Fusion/Hana style
metaprogramming. Additionally,
since this is a language feature, we could pontentially see the same
compile-time performance that
Kvasir.Mpl has without the difficult continuation interface (and it works
on expressions!).


## Additional Bonus Features

Since the expressions maintain the context of the site of invocation we
also get constexpr parameters.

```cpp
using to_integral_constant(auto x) {
  return std::integral_constant<int, x>{};
}

int main() {
  constexpr int x = 0;
  static_assert(std::is_same_v<std::integral_constant<int, 0>,
decltype(to_integral_constant(x)));
}
```

We also get arrays and string literals that do not decay.

```cpp
using id(auto x) {
  return x;
}

int main() {
  char const* foo = id("foo");
}

// the same as

int main() {
  char const* foo = "foo";
}
```

To top it off, we also get a clean syntax for Perfect Forwarding

  * This assumes that the input expression casts to an rvalue
  * See the rules below for information on how value categories are handled

```cpp
template <typename F, typename X, typename Y>
decltype(auto) flip(F&& f, X&& x, y&& y) {
  return std::forward<F>(f)(std::forward<Y>(y), std::forward<X>(x));
}

// becomes

using flip(auto f, auto x, auto y) {
  return f(y, x);
}
```

## As a Member of a Class

Parametric expressions can be used as a member in conjunction with operator
overloading to create an
invocable object:

```cpp
  struct id_fn {
    using operator()(auto x) {
      return x;
    }
  };

  id_fn{}(42);

  static_assert(std::is_invocable<id_fn, int>::value);
```


## The Rules

1. The input parameter list may contain only one parameter pack in any
position.
    * This is afforded since we don't do type deduction

2. The input parameters may be unexpanded parameter packs.
    * This adds a bit more power for working with lists.
    * see [Multicategory][1]

3. The output expression must NOT contain any unexpanded parameter packs
    * This would prevent pack expansion ambiguity at the call site

4. Input parameter type specifiers must be completely unconstrained and
never have type qualifiers.
    * We could possibly apply constraints to the type in the future via
Concepts

5. The definition is a compound statement where the final statement must
either be a return statement
   or a constexpr if/else statement where each branch follows this same
rule.
    * There can be only one return statement which yields the output
expression

6. Recursion is not allowed
    * Not sure if recursion would be feasible, but we could at least use
Odin Holmes' recursive
      alias pattern

7. Input parameters are expression aliases which follow different rules
with regard to the evaluated
   type's value category and reference type:
    1. Prvalue constant-expressions are simply pasted wherever it is used
in the definition.
        * This affords constexpr parameters and literals
    2. Unexpanded parameter packs are pasted where the parameter is used in
the expression.
        * Again note that they must be expanded wherever they are used in
the definition
    2. Everything else is bound to an lvalue reference within the compound
statement implicitly.
    3. Expressions evaluating to an rvalue have the last evaluated use in
the definition cast to an
       rvalue.
        * The compiler should be able to determine this internally even for
cases where order of
          evaluation is unspecified.
        * This also implies that this could be used to detect order of
evaluation of a function call.
        * This is similar to how Rust handles implicit moves!

8. Input expressions that are not constant-expressions will be evaluated
immediately from left to right
   as specified in the parameter list.
    * Note that unexpanded packs are not included in this

9. The output is a generated compound statement evaluated as an expression
that is specified using
   the return statement in the definition body of the parametric expression.


I see this as potentially having a huge impact on the ability to implement
ranges, expression templates,
metaprogramming libraries, and my own pet case of nesting continuations for
various purposes. It would be
really cool to get this in C++20 if it is not too late.


Thanks for looking at this!

Jason Rice

[1]: https://en.wikipedia.org/wiki/Multicategory

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40isocpp.org.

------=_Part_318_1238977075.1535647375558
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Here is a write up for a language feature that I would lik=
e to have considered: <br><br><a href=3D"https://gist.github.com/ricejasonf=
/84c11ac6bb093c1ea8c380a9a466d8cb">https://gist.github.com/ricejasonf/84c11=
ac6bb093c1ea8c380a9a466d8cb</a><br><div><br></div><div>I&#39;m attempting t=
o implement it in Clang, but I would like to get some early feedback.<br><b=
r>I&#39;ve already received some feedback from Louis Dionne and he encourag=
ed me to post it here.<br><br><br></div>Thanks!<br><br><br><br># Parametric=
 Expression<br><br>The primary purpose here is to improve compile-time perf=
ormance by providing a tool that augments existing<br>metaprogramming featu=
res in C++. It involves the transformation of expressions.<br><br>Essential=
ly this feature is meant to combine the power of function templates with th=
e performance of type<br>aliases. Function templates as we have them now ar=
e loaded with features such as overloading, constraints,<br>type deduction,=
 SFINAE, ect.. When called not only do we get an expensive template instant=
iation but also <br>potentially large symbols and extraneous code generatio=
n all for functions we wouldn&#39;t call otherwise<br>unless we expected th=
e optimizer to inline them out anyways. With this tool we want to give prog=
rammers<br>the ability to allow this inlining at an earlier stage, but the =
solution is elegant enough to provide a<br>few additional bonus features.<b=
r><br>Consider the following declaration syntax:<br><br>```cpp<br>using add=
(auto a, auto b) {<br>=C2=A0 return a + b;<br>}<br>```<br><br>Here is a fun=
ction-like declaration where the domain and codomain are expressions.<br><b=
r>Invoking it merely transforms the expression in the context of the site o=
f invocation.<br><br>```cpp<br>int main() {<br>=C2=A0 return add(40, 2);<br=
>}<br><br>// the same as<br><br>int main() {<br>=C2=A0 return 40 + 2;<br>}<=
br>```<br><br>This ability to transform expressions has the same power as t=
ype aliases, but here we can work with<br>constructs that have run-time eff=
ects as seen in Fusion/Hana style metaprogramming. Additionally,<br>since t=
his is a language feature, we could pontentially see the same compile-time =
performance that<br>Kvasir.Mpl has without the difficult continuation inter=
face (and it works on expressions!).<br><br><br>## Additional Bonus Feature=
s<br><br>Since the expressions maintain the context of the site of invocati=
on we also get constexpr parameters.<br><br>```cpp<br>using to_integral_con=
stant(auto x) {<br>=C2=A0 return std::integral_constant&lt;int, x&gt;{};<br=
>}<br><br>int main() {<br>=C2=A0 constexpr int x =3D 0;<br>=C2=A0 static_as=
sert(std::is_same_v&lt;std::integral_constant&lt;int, 0&gt;, decltype(to_in=
tegral_constant(x)));<br>}<br>```<br><br>We also get arrays and string lite=
rals that do not decay.<br><br>```cpp<br>using id(auto x) {<br>=C2=A0 retur=
n x;<br>}<br><br>int main() {<br>=C2=A0 char const* foo =3D id(&quot;foo&qu=
ot;);<br>}<br><br>// the same as<br><br>int main() {<br>=C2=A0 char const* =
foo =3D &quot;foo&quot;;<br>}<br>```<br><br>To top it off, we also get a cl=
ean syntax for Perfect Forwarding<br>=C2=A0=C2=A0=C2=A0 <br>=C2=A0 * This a=
ssumes that the input expression casts to an rvalue<br>=C2=A0 * See the rul=
es below for information on how value categories are handled<br><br>```cpp<=
br>template &lt;typename F, typename X, typename Y&gt;<br>decltype(auto) fl=
ip(F&amp;&amp; f, X&amp;&amp; x, y&amp;&amp; y) {<br>=C2=A0 return std::for=
ward&lt;F&gt;(f)(std::forward&lt;Y&gt;(y), std::forward&lt;X&gt;(x));<br>}<=
br><br>// becomes<br><br>using flip(auto f, auto x, auto y) {<br>=C2=A0 ret=
urn f(y, x);<br>}<br>```<br><br>## As a Member of a Class<br><br>Parametric=
 expressions can be used as a member in conjunction with operator overloadi=
ng to create an<br>invocable object:<br><br>```cpp<br>=C2=A0 struct id_fn {=
<br>=C2=A0=C2=A0=C2=A0 using operator()(auto x) {<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 return x;<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0 };<br><br>=C2=A0 id_f=
n{}(42);<br><br>=C2=A0 static_assert(std::is_invocable&lt;id_fn, int&gt;::v=
alue);<br>```<br><br><br>## The Rules<br><br>1. The input parameter list ma=
y contain only one parameter pack in any position.<br>=C2=A0=C2=A0=C2=A0 * =
This is afforded since we don&#39;t do type deduction<br><br>2. The input p=
arameters may be unexpanded parameter packs.<br>=C2=A0=C2=A0=C2=A0 * This a=
dds a bit more power for working with lists.<br>=C2=A0=C2=A0=C2=A0 * see [M=
ulticategory][1]<br>=C2=A0<br>3. The output expression must NOT contain any=
 unexpanded parameter packs<br>=C2=A0=C2=A0=C2=A0 * This would prevent pack=
 expansion ambiguity at the call site<br><br>4. Input parameter type specif=
iers must be completely unconstrained and never have type qualifiers.<br>=
=C2=A0=C2=A0=C2=A0 * We could possibly apply constraints to the type in the=
 future via Concepts<br><br>5. The definition is a compound statement where=
 the final statement must either be a return statement<br>=C2=A0=C2=A0 or a=
 constexpr if/else statement where each branch follows this same rule.<br>=
=C2=A0=C2=A0=C2=A0 * There can be only one return statement which yields th=
e output expression<br><br>6. Recursion is not allowed<br>=C2=A0=C2=A0=C2=
=A0 * Not sure if recursion would be feasible, but we could at least use Od=
in Holmes&#39; recursive<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 alias pattern<br=
><br>7. Input parameters are expression aliases which follow different rule=
s with regard to the evaluated<br>=C2=A0=C2=A0 type&#39;s value category an=
d reference type:<br>=C2=A0=C2=A0=C2=A0 1. Prvalue constant-expressions are=
 simply pasted wherever it is used in the definition.<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 * This affords constexpr parameters and literals<b=
r>=C2=A0=C2=A0=C2=A0 2. Unexpanded parameter packs are pasted where the par=
ameter is used in the expression.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 * Again note that they must be expanded wherever they are used in th=
e definition<br>=C2=A0=C2=A0=C2=A0 2. Everything else is bound to an lvalue=
 reference within the compound statement implicitly.<br>=C2=A0=C2=A0=C2=A0 =
3. Expressions evaluating to an rvalue have the last evaluated use in the d=
efinition cast to an<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rvalue.<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * The compiler should be able to de=
termine this internally even for cases where order of<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 evaluation is unspecified.<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This also implies that this could be=
 used to detect order of evaluation of a function call.<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This is similar to how Rust handles implicit =
moves!<br><br>8. Input expressions that are not constant-expressions will b=
e evaluated immediately from left to right<br>=C2=A0=C2=A0 as specified in =
the parameter list.<br>=C2=A0=C2=A0=C2=A0 * Note that unexpanded packs are =
not included in this<br><br>9. The output is a generated compound statement=
 evaluated as an expression that is specified using<br>=C2=A0=C2=A0 the ret=
urn statement in the definition body of the parametric expression.<br><br><=
br>I see this as potentially having a huge impact on the ability to impleme=
nt ranges, expression templates,<br>metaprogramming libraries, and my own p=
et case of nesting continuations for various purposes. It would be<br>reall=
y cool to get this in C++20 if it is not too late.<br><br><br>Thanks for lo=
oking at this!<br><br>Jason Rice<br><br>[1]: https://en.wikipedia.org/wiki/=
Multicategory<br><br></div>

<p></p>

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

------=_Part_318_1238977075.1535647375558--

------=_Part_317_388735170.1535647375557--

.

--000000000000a8320e0574ae379d
Content-Type: text/plain; charset="UTF-8"

I'd worry a little about such a facility being overused where people really
just want a function with a strong "inline this please" hint (but then
again, any feature can be misused). But this seems like an interesting way
to address a collection of cases where people currently use macros.

The paper would benefit from a collection of realistic usage examples.

"Expressions evaluating to an rvalue have the last evaluated use in the
definition cast to an rvalue.
The compiler should be able to determine this internally even for cases
where order of evaluation is unspecified."

Can the body of the alias contain control flow constructs? I don't think
the compiler can determine this in general. It's also unfortunate that you
don't support (guaranteed) copy elision for rvalue parameters under any
circumstances.

On Thu, 30 Aug 2018 at 09:42, Jason Rice <ricejasonf@gmail.com> wrote:

> Here is a write up for a language feature that I would like to have
> considered:
>
> https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb
>
> I'm attempting to implement it in Clang, but I would like to get some
> early feedback.
>
> I've already received some feedback from Louis Dionne and he encouraged me
> to post it here.
>
>
> Thanks!
>
>
>
> # Parametric Expression
>
> The primary purpose here is to improve compile-time performance by
> providing a tool that augments existing
> metaprogramming features in C++. It involves the transformation of
> expressions.
>
> Essentially this feature is meant to combine the power of function
> templates with the performance of type
> aliases. Function templates as we have them now are loaded with features
> such as overloading, constraints,
> type deduction, SFINAE, ect.. When called not only do we get an expensive
> template instantiation but also
> potentially large symbols and extraneous code generation all for functions
> we wouldn't call otherwise
> unless we expected the optimizer to inline them out anyways. With this
> tool we want to give programmers
> the ability to allow this inlining at an earlier stage, but the solution
> is elegant enough to provide a
> few additional bonus features.
>
> Consider the following declaration syntax:
>
> ```cpp
> using add(auto a, auto b) {
>   return a + b;
> }
> ```
>
> Here is a function-like declaration where the domain and codomain are
> expressions.
>
> Invoking it merely transforms the expression in the context of the site of
> invocation.
>
> ```cpp
> int main() {
>   return add(40, 2);
> }
>
> // the same as
>
> int main() {
>   return 40 + 2;
> }
> ```
>
> This ability to transform expressions has the same power as type aliases,
> but here we can work with
> constructs that have run-time effects as seen in Fusion/Hana style
> metaprogramming. Additionally,
> since this is a language feature, we could pontentially see the same
> compile-time performance that
> Kvasir.Mpl has without the difficult continuation interface (and it works
> on expressions!).
>
>
> ## Additional Bonus Features
>
> Since the expressions maintain the context of the site of invocation we
> also get constexpr parameters.
>
> ```cpp
> using to_integral_constant(auto x) {
>   return std::integral_constant<int, x>{};
> }
>
> int main() {
>   constexpr int x = 0;
>   static_assert(std::is_same_v<std::integral_constant<int, 0>,
> decltype(to_integral_constant(x)));
> }
> ```
>
> We also get arrays and string literals that do not decay.
>
> ```cpp
> using id(auto x) {
>   return x;
> }
>
> int main() {
>   char const* foo = id("foo");
> }
>
> // the same as
>
> int main() {
>   char const* foo = "foo";
> }
> ```
>
> To top it off, we also get a clean syntax for Perfect Forwarding
>
>   * This assumes that the input expression casts to an rvalue
>   * See the rules below for information on how value categories are handled
>
> ```cpp
> template <typename F, typename X, typename Y>
> decltype(auto) flip(F&& f, X&& x, y&& y) {
>   return std::forward<F>(f)(std::forward<Y>(y), std::forward<X>(x));
> }
>
> // becomes
>
> using flip(auto f, auto x, auto y) {
>   return f(y, x);
> }
> ```
>
> ## As a Member of a Class
>
> Parametric expressions can be used as a member in conjunction with
> operator overloading to create an
> invocable object:
>
> ```cpp
>   struct id_fn {
>     using operator()(auto x) {
>       return x;
>     }
>   };
>
>   id_fn{}(42);
>
>   static_assert(std::is_invocable<id_fn, int>::value);
> ```
>
>
> ## The Rules
>
> 1. The input parameter list may contain only one parameter pack in any
> position.
>     * This is afforded since we don't do type deduction
>
> 2. The input parameters may be unexpanded parameter packs.
>     * This adds a bit more power for working with lists.
>     * see [Multicategory][1]
>
> 3. The output expression must NOT contain any unexpanded parameter packs
>     * This would prevent pack expansion ambiguity at the call site
>
> 4. Input parameter type specifiers must be completely unconstrained and
> never have type qualifiers.
>     * We could possibly apply constraints to the type in the future via
> Concepts
>
> 5. The definition is a compound statement where the final statement must
> either be a return statement
>    or a constexpr if/else statement where each branch follows this same
> rule.
>     * There can be only one return statement which yields the output
> expression
>
> 6. Recursion is not allowed
>     * Not sure if recursion would be feasible, but we could at least use
> Odin Holmes' recursive
>       alias pattern
>
> 7. Input parameters are expression aliases which follow different rules
> with regard to the evaluated
>    type's value category and reference type:
>     1. Prvalue constant-expressions are simply pasted wherever it is used
> in the definition.
>         * This affords constexpr parameters and literals
>     2. Unexpanded parameter packs are pasted where the parameter is used
> in the expression.
>         * Again note that they must be expanded wherever they are used in
> the definition
>     2. Everything else is bound to an lvalue reference within the compound
> statement implicitly.
>     3. Expressions evaluating to an rvalue have the last evaluated use in
> the definition cast to an
>        rvalue.
>         * The compiler should be able to determine this internally even
> for cases where order of
>           evaluation is unspecified.
>         * This also implies that this could be used to detect order of
> evaluation of a function call.
>         * This is similar to how Rust handles implicit moves!
>
> 8. Input expressions that are not constant-expressions will be evaluated
> immediately from left to right
>    as specified in the parameter list.
>     * Note that unexpanded packs are not included in this
>
> 9. The output is a generated compound statement evaluated as an expression
> that is specified using
>    the return statement in the definition body of the parametric
> expression.
>
>
> I see this as potentially having a huge impact on the ability to implement
> ranges, expression templates,
> metaprogramming libraries, and my own pet case of nesting continuations
> for various purposes. It would be
> really cool to get this in C++20 if it is not too late.
>
>
> Thanks for looking at this!
>
> Jason Rice
>
> [1]: https://en.wikipedia.org/wiki/Multicategory
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

--000000000000a8320e0574ae379d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;d worry a little about such a facility being ov=
erused where people really just want a function with a strong &quot;inline =
this please&quot; hint (but then again, any feature can be misused). But th=
is seems like an interesting way to address a collection of cases where peo=
ple currently use macros.</div><div><br></div><div>The paper would benefit =
from a collection of realistic usage examples.</div><div><br></div>&quot;Ex=
pressions evaluating to an rvalue have the last evaluated use in the defini=
tion cast to an rvalue.<div>The compiler should be able to determine this i=
nternally even for cases where order of evaluation is unspecified.&quot;</d=
iv><div><br></div><div>Can the body of the alias contain control flow const=
ructs? I don&#39;t think the compiler can determine this in general. It&#39=
;s also unfortunate that you don&#39;t support (guaranteed) copy elision fo=
r rvalue parameters under any circumstances.</div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr">On Thu, 30 Aug 2018 at 09:42, Jason Rice &lt;<=
a href=3D"mailto:ricejasonf@gmail.com">ricejasonf@gmail.com</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Here is a write up=
 for a language feature that I would like to have considered: <br><br><a hr=
ef=3D"https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb" =
target=3D"_blank">https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380=
a9a466d8cb</a><br><div><br></div><div>I&#39;m attempting to implement it in=
 Clang, but I would like to get some early feedback.<br><br>I&#39;ve alread=
y received some feedback from Louis Dionne and he encouraged me to post it =
here.<br><br><br></div>Thanks!<br><br><br><br># Parametric Expression<br><b=
r>The primary purpose here is to improve compile-time performance by provid=
ing a tool that augments existing<br>metaprogramming features in C++. It in=
volves the transformation of expressions.<br><br>Essentially this feature i=
s meant to combine the power of function templates with the performance of =
type<br>aliases. Function templates as we have them now are loaded with fea=
tures such as overloading, constraints,<br>type deduction, SFINAE, ect.. Wh=
en called not only do we get an expensive template instantiation but also <=
br>potentially large symbols and extraneous code generation all for functio=
ns we wouldn&#39;t call otherwise<br>unless we expected the optimizer to in=
line them out anyways. With this tool we want to give programmers<br>the ab=
ility to allow this inlining at an earlier stage, but the solution is elega=
nt enough to provide a<br>few additional bonus features.<br><br>Consider th=
e following declaration syntax:<br><br>```cpp<br>using add(auto a, auto b) =
{<br>=C2=A0 return a + b;<br>}<br>```<br><br>Here is a function-like declar=
ation where the domain and codomain are expressions.<br><br>Invoking it mer=
ely transforms the expression in the context of the site of invocation.<br>=
<br>```cpp<br>int main() {<br>=C2=A0 return add(40, 2);<br>}<br><br>// the =
same as<br><br>int main() {<br>=C2=A0 return 40 + 2;<br>}<br>```<br><br>Thi=
s ability to transform expressions has the same power as type aliases, but =
here we can work with<br>constructs that have run-time effects as seen in F=
usion/Hana style metaprogramming. Additionally,<br>since this is a language=
 feature, we could pontentially see the same compile-time performance that<=
br>Kvasir.Mpl has without the difficult continuation interface (and it work=
s on expressions!).<br><br><br>## Additional Bonus Features<br><br>Since th=
e expressions maintain the context of the site of invocation we also get co=
nstexpr parameters.<br><br>```cpp<br>using to_integral_constant(auto x) {<b=
r>=C2=A0 return std::integral_constant&lt;int, x&gt;{};<br>}<br><br>int mai=
n() {<br>=C2=A0 constexpr int x =3D 0;<br>=C2=A0 static_assert(std::is_same=
_v&lt;std::integral_constant&lt;int, 0&gt;, decltype(to_integral_constant(x=
)));<br>}<br>```<br><br>We also get arrays and string literals that do not =
decay.<br><br>```cpp<br>using id(auto x) {<br>=C2=A0 return x;<br>}<br><br>=
int main() {<br>=C2=A0 char const* foo =3D id(&quot;foo&quot;);<br>}<br><br=
>// the same as<br><br>int main() {<br>=C2=A0 char const* foo =3D &quot;foo=
&quot;;<br>}<br>```<br><br>To top it off, we also get a clean syntax for Pe=
rfect Forwarding<br>=C2=A0=C2=A0=C2=A0 <br>=C2=A0 * This assumes that the i=
nput expression casts to an rvalue<br>=C2=A0 * See the rules below for info=
rmation on how value categories are handled<br><br>```cpp<br>template &lt;t=
ypename F, typename X, typename Y&gt;<br>decltype(auto) flip(F&amp;&amp; f,=
 X&amp;&amp; x, y&amp;&amp; y) {<br>=C2=A0 return std::forward&lt;F&gt;(f)(=
std::forward&lt;Y&gt;(y), std::forward&lt;X&gt;(x));<br>}<br><br>// becomes=
<br><br>using flip(auto f, auto x, auto y) {<br>=C2=A0 return f(y, x);<br>}=
<br>```<br><br>## As a Member of a Class<br><br>Parametric expressions can =
be used as a member in conjunction with operator overloading to create an<b=
r>invocable object:<br><br>```cpp<br>=C2=A0 struct id_fn {<br>=C2=A0=C2=A0=
=C2=A0 using operator()(auto x) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return =
x;<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0 };<br><br>=C2=A0 id_fn{}(42);<br><br>=
=C2=A0 static_assert(std::is_invocable&lt;id_fn, int&gt;::value);<br>```<br=
><br><br>## The Rules<br><br>1. The input parameter list may contain only o=
ne parameter pack in any position.<br>=C2=A0=C2=A0=C2=A0 * This is afforded=
 since we don&#39;t do type deduction<br><br>2. The input parameters may be=
 unexpanded parameter packs.<br>=C2=A0=C2=A0=C2=A0 * This adds a bit more p=
ower for working with lists.<br>=C2=A0=C2=A0=C2=A0 * see [Multicategory][1]=
<br>=C2=A0<br>3. The output expression must NOT contain any unexpanded para=
meter packs<br>=C2=A0=C2=A0=C2=A0 * This would prevent pack expansion ambig=
uity at the call site<br><br>4. Input parameter type specifiers must be com=
pletely unconstrained and never have type qualifiers.<br>=C2=A0=C2=A0=C2=A0=
 * We could possibly apply constraints to the type in the future via Concep=
ts<br><br>5. The definition is a compound statement where the final stateme=
nt must either be a return statement<br>=C2=A0=C2=A0 or a constexpr if/else=
 statement where each branch follows this same rule.<br>=C2=A0=C2=A0=C2=A0 =
* There can be only one return statement which yields the output expression=
<br><br>6. Recursion is not allowed<br>=C2=A0=C2=A0=C2=A0 * Not sure if rec=
ursion would be feasible, but we could at least use Odin Holmes&#39; recurs=
ive<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 alias pattern<br><br>7. Input paramet=
ers are expression aliases which follow different rules with regard to the =
evaluated<br>=C2=A0=C2=A0 type&#39;s value category and reference type:<br>=
=C2=A0=C2=A0=C2=A0 1. Prvalue constant-expressions are simply pasted wherev=
er it is used in the definition.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 * This affords constexpr parameters and literals<br>=C2=A0=C2=A0=C2=A0 =
2. Unexpanded parameter packs are pasted where the parameter is used in the=
 expression.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Again note tha=
t they must be expanded wherever they are used in the definition<br>=C2=A0=
=C2=A0=C2=A0 2. Everything else is bound to an lvalue reference within the =
compound statement implicitly.<br>=C2=A0=C2=A0=C2=A0 3. Expressions evaluat=
ing to an rvalue have the last evaluated use in the definition cast to an<b=
r>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rvalue.<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 * The compiler should be able to determine this internal=
ly even for cases where order of<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 evaluation is unspecified.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 * This also implies that this could be used to detect order=
 of evaluation of a function call.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 * This is similar to how Rust handles implicit moves!<br><br>8. Inpu=
t expressions that are not constant-expressions will be evaluated immediate=
ly from left to right<br>=C2=A0=C2=A0 as specified in the parameter list.<b=
r>=C2=A0=C2=A0=C2=A0 * Note that unexpanded packs are not included in this<=
br><br>9. The output is a generated compound statement evaluated as an expr=
ession that is specified using<br>=C2=A0=C2=A0 the return statement in the =
definition body of the parametric expression.<br><br><br>I see this as pote=
ntially having a huge impact on the ability to implement ranges, expression=
 templates,<br>metaprogramming libraries, and my own pet case of nesting co=
ntinuations for various purposes. It would be<br>really cool to get this in=
 C++20 if it is not too late.<br><br><br>Thanks for looking at this!<br><br=
>Jason Rice<br><br>[1]: <a href=3D"https://en.wikipedia.org/wiki/Multicateg=
ory" target=3D"_blank">https://en.wikipedia.org/wiki/Multicategory</a><br><=
br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-=
4121-aa5f-69edf040d5b5%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

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

--000000000000a8320e0574ae379d--

.

------=_Part_524_1847894600.1535671276111
Content-Type: multipart/alternative;
 boundary="----=_Part_525_885314025.1535671276112"

------=_Part_525_885314025.1535671276112
Content-Type: text/plain; charset="UTF-8"


>
> Can the body of the alias contain control flow constructs?
>

If you mean like if/else statements then I would say yes along with side
effects and what not. It generates a compound statement that yields as an
expression determined by the return statement.

I don't think the compiler can determine this in general. It's also
> unfortunate that you don't support (guaranteed) copy elision for rvalue
> parameters under any circumstances.
>

The parameters are aliases to expressions so there isn't any copying going
on so I don't know that specifying copy elision is necessary.

In the case where the expression param is used only once we could just
paste the expression, but that would definitely make the order of
evaluation thing right out. I'm fine with that.

For the case where the param is used multiple times we substitute with a
reference to the result of the expression by generating a statement within
the compound statement.

I'm still thinking that implicit recast to rvalue is possible except in
cases where it is used that the order of evaluation is undefined. If that
is too difficult, we can rip it out as it is tertiary anyways.

I will work on getting some realistic usage examples up. Thanks!

On Thursday, August 30, 2018 at 3:01:36 PM UTC-7, Richard Smith wrote:

> I'd worry a little about such a facility being overused where people
> really just want a function with a strong "inline this please" hint (but
> then again, any feature can be misused). But this seems like an interesting
> way to address a collection of cases where people currently use macros.
>
> The paper would benefit from a collection of realistic usage examples.
>
> "Expressions evaluating to an rvalue have the last evaluated use in the
> definition cast to an rvalue.
> The compiler should be able to determine this internally even for cases
> where order of evaluation is unspecified."
>
> Can the body of the alias contain control flow constructs? I don't think
> the compiler can determine this in general. It's also unfortunate that you
> don't support (guaranteed) copy elision for rvalue parameters under any
> circumstances.
>
> On Thu, 30 Aug 2018 at 09:42, Jason Rice <ricej...@gmail.com <javascript:>>
> wrote:
>
>> Here is a write up for a language feature that I would like to have
>> considered:
>>
>> https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb
>>
>> I'm attempting to implement it in Clang, but I would like to get some
>> early feedback.
>>
>> I've already received some feedback from Louis Dionne and he encouraged
>> me to post it here.
>>
>>
>> Thanks!
>>
>>
>>
>> # Parametric Expression
>>
>> The primary purpose here is to improve compile-time performance by
>> providing a tool that augments existing
>> metaprogramming features in C++. It involves the transformation of
>> expressions.
>>
>> Essentially this feature is meant to combine the power of function
>> templates with the performance of type
>> aliases. Function templates as we have them now are loaded with features
>> such as overloading, constraints,
>> type deduction, SFINAE, ect.. When called not only do we get an expensive
>> template instantiation but also
>> potentially large symbols and extraneous code generation all for
>> functions we wouldn't call otherwise
>> unless we expected the optimizer to inline them out anyways. With this
>> tool we want to give programmers
>> the ability to allow this inlining at an earlier stage, but the solution
>> is elegant enough to provide a
>> few additional bonus features.
>>
>> Consider the following declaration syntax:
>>
>> ```cpp
>> using add(auto a, auto b) {
>>   return a + b;
>> }
>> ```
>>
>> Here is a function-like declaration where the domain and codomain are
>> expressions.
>>
>> Invoking it merely transforms the expression in the context of the site
>> of invocation.
>>
>> ```cpp
>> int main() {
>>   return add(40, 2);
>> }
>>
>> // the same as
>>
>> int main() {
>>   return 40 + 2;
>> }
>> ```
>>
>> This ability to transform expressions has the same power as type aliases,
>> but here we can work with
>> constructs that have run-time effects as seen in Fusion/Hana style
>> metaprogramming. Additionally,
>> since this is a language feature, we could pontentially see the same
>> compile-time performance that
>> Kvasir.Mpl has without the difficult continuation interface (and it works
>> on expressions!).
>>
>>
>> ## Additional Bonus Features
>>
>> Since the expressions maintain the context of the site of invocation we
>> also get constexpr parameters.
>>
>> ```cpp
>> using to_integral_constant(auto x) {
>>   return std::integral_constant<int, x>{};
>> }
>>
>> int main() {
>>   constexpr int x = 0;
>>   static_assert(std::is_same_v<std::integral_constant<int, 0>,
>> decltype(to_integral_constant(x)));
>> }
>> ```
>>
>> We also get arrays and string literals that do not decay.
>>
>> ```cpp
>> using id(auto x) {
>>   return x;
>> }
>>
>> int main() {
>>   char const* foo = id("foo");
>> }
>>
>> // the same as
>>
>> int main() {
>>   char const* foo = "foo";
>> }
>> ```
>>
>> To top it off, we also get a clean syntax for Perfect Forwarding
>>
>>   * This assumes that the input expression casts to an rvalue
>>   * See the rules below for information on how value categories are
>> handled
>>
>> ```cpp
>> template <typename F, typename X, typename Y>
>> decltype(auto) flip(F&& f, X&& x, y&& y) {
>>   return std::forward<F>(f)(std::forward<Y>(y), std::forward<X>(x));
>> }
>>
>> // becomes
>>
>> using flip(auto f, auto x, auto y) {
>>   return f(y, x);
>> }
>> ```
>>
>> ## As a Member of a Class
>>
>> Parametric expressions can be used as a member in conjunction with
>> operator overloading to create an
>> invocable object:
>>
>> ```cpp
>>   struct id_fn {
>>     using operator()(auto x) {
>>       return x;
>>     }
>>   };
>>
>>   id_fn{}(42);
>>
>>   static_assert(std::is_invocable<id_fn, int>::value);
>> ```
>>
>>
>> ## The Rules
>>
>> 1. The input parameter list may contain only one parameter pack in any
>> position.
>>     * This is afforded since we don't do type deduction
>>
>> 2. The input parameters may be unexpanded parameter packs.
>>     * This adds a bit more power for working with lists.
>>     * see [Multicategory][1]
>>
>> 3. The output expression must NOT contain any unexpanded parameter packs
>>     * This would prevent pack expansion ambiguity at the call site
>>
>> 4. Input parameter type specifiers must be completely unconstrained and
>> never have type qualifiers.
>>     * We could possibly apply constraints to the type in the future via
>> Concepts
>>
>> 5. The definition is a compound statement where the final statement must
>> either be a return statement
>>    or a constexpr if/else statement where each branch follows this same
>> rule.
>>     * There can be only one return statement which yields the output
>> expression
>>
>> 6. Recursion is not allowed
>>     * Not sure if recursion would be feasible, but we could at least use
>> Odin Holmes' recursive
>>       alias pattern
>>
>> 7. Input parameters are expression aliases which follow different rules
>> with regard to the evaluated
>>    type's value category and reference type:
>>     1. Prvalue constant-expressions are simply pasted wherever it is used
>> in the definition.
>>         * This affords constexpr parameters and literals
>>     2. Unexpanded parameter packs are pasted where the parameter is used
>> in the expression.
>>         * Again note that they must be expanded wherever they are used in
>> the definition
>>     2. Everything else is bound to an lvalue reference within the
>> compound statement implicitly.
>>     3. Expressions evaluating to an rvalue have the last evaluated use in
>> the definition cast to an
>>        rvalue.
>>         * The compiler should be able to determine this internally even
>> for cases where order of
>>           evaluation is unspecified.
>>         * This also implies that this could be used to detect order of
>> evaluation of a function call.
>>         * This is similar to how Rust handles implicit moves!
>>
>> 8. Input expressions that are not constant-expressions will be evaluated
>> immediately from left to right
>>    as specified in the parameter list.
>>     * Note that unexpanded packs are not included in this
>>
>> 9. The output is a generated compound statement evaluated as an
>> expression that is specified using
>>    the return statement in the definition body of the parametric
>> expression.
>>
>>
>> I see this as potentially having a huge impact on the ability to
>> implement ranges, expression templates,
>> metaprogramming libraries, and my own pet case of nesting continuations
>> for various purposes. It would be
>> really cool to get this in C++20 if it is not too late.
>>
>>
>> Thanks for looking at this!
>>
>> Jason Rice
>>
>> [1]: https://en.wikipedia.org/wiki/Multicategory
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06d2d0a6-dcf0-4365-8f64-bc4603804a58%40isocpp.org.

------=_Part_525_885314025.1535671276112
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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;">=
Can the body of the alias contain control flow constructs?<br></blockquote>=
<div><br></div><div>If you mean like if/else statements then I would say ye=
s along with side effects and what not. It generates a compound statement t=
hat yields as an expression determined by the return statement.<br><br><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I don&#39;t think th=
e compiler can determine this in general. It&#39;s also unfortunate that yo=
u don&#39;t support (guaranteed) copy elision for rvalue parameters under a=
ny circumstances.<br></blockquote></div><div><br>The parameters are aliases=
 to expressions so there isn&#39;t any copying going on so I don&#39;t know=
 that specifying copy elision is necessary.<br><br>In the case where the ex=
pression param is used only once we could just paste the expression, but th=
at would definitely make the order of evaluation thing right out. I&#39;m f=
ine with that.<br><br>For the case where the param is used multiple times w=
e substitute with a reference to the result of the expression by generating=
 a statement within the compound statement.<br><br>I&#39;m still thinking t=
hat implicit recast to rvalue is possible except in cases where it is used =
that the order of evaluation is undefined. If that is too difficult, we can=
 rip it out as it is tertiary anyways.<br><br>I will work on getting some r=
ealistic usage examples up. Thanks!<br><br>On Thursday, August 30, 2018 at =
3:01:36 PM UTC-7, Richard Smith wrote:</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>I&#39;d worry a little about such a fac=
ility being overused where people really just want a function with a strong=
 &quot;inline this please&quot; hint (but then again, any feature can be mi=
sused). But this seems like an interesting way to address a collection of c=
ases where people currently use macros.</div><div><br></div><div>The paper =
would benefit from a collection of realistic usage examples.</div><div><br>=
</div>&quot;Expressions evaluating to an rvalue have the last evaluated use=
 in the definition cast to an rvalue.<div>The compiler should be able to de=
termine this internally even for cases where order of evaluation is unspeci=
fied.&quot;</div><div><br></div><div>Can the body of the alias contain cont=
rol flow constructs? I don&#39;t think the compiler can determine this in g=
eneral. It&#39;s also unfortunate that you don&#39;t support (guaranteed) c=
opy elision for rvalue parameters under any circumstances.</div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 30 Aug 2018 at 09:42, Ja=
son Rice &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"2Oe3UI1oAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">ricej...@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">Here is a write up for a language feature that I wo=
uld like to have considered: <br><br><a href=3D"https://gist.github.com/ric=
ejasonf/84c11ac6bb093c1ea8c380a9a466d8cb" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%=
2F%2Fgist.github.com%2Fricejasonf%2F84c11ac6bb093c1ea8c380a9a466d8cb\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFV8-r36DHcSGyAmbxuQ8QTHwHKcA&#39;;return =
true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fgist.github.com%2Fricejasonf%2F84c11ac6bb093c1ea8c380a9a466d8cb\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFV8-r36DHcSGyAmbxuQ8QTHwHKcA&#39;;return=
 true;">https://gist.github.com/<wbr>ricejasonf/<wbr>84c11ac6bb093c1ea8c380=
a9a466d8<wbr>cb</a><br><div><br></div><div>I&#39;m attempting to implement =
it in Clang, but I would like to get some early feedback.<br><br>I&#39;ve a=
lready received some feedback from Louis Dionne and he encouraged me to pos=
t it here.<br><br><br></div>Thanks!<br><br><br><br># Parametric Expression<=
br><br>The primary purpose here is to improve compile-time performance by p=
roviding a tool that augments existing<br>metaprogramming features in C++. =
It involves the transformation of expressions.<br><br>Essentially this feat=
ure is meant to combine the power of function templates with the performanc=
e of type<br>aliases. Function templates as we have them now are loaded wit=
h features such as overloading, constraints,<br>type deduction, SFINAE, ect=
... When called not only do we get an expensive template instantiation but a=
lso <br>potentially large symbols and extraneous code generation all for fu=
nctions we wouldn&#39;t call otherwise<br>unless we expected the optimizer =
to inline them out anyways. With this tool we want to give programmers<br>t=
he ability to allow this inlining at an earlier stage, but the solution is =
elegant enough to provide a<br>few additional bonus features.<br><br>Consid=
er the following declaration syntax:<br><br>```cpp<br>using add(auto a, aut=
o b) {<br>=C2=A0 return a + b;<br>}<br>```<br><br>Here is a function-like d=
eclaration where the domain and codomain are expressions.<br><br>Invoking i=
t merely transforms the expression in the context of the site of invocation=
..<br><br>```cpp<br>int main() {<br>=C2=A0 return add(40, 2);<br>}<br><br>//=
 the same as<br><br>int main() {<br>=C2=A0 return 40 + 2;<br>}<br>```<br><b=
r>This ability to transform expressions has the same power as type aliases,=
 but here we can work with<br>constructs that have run-time effects as seen=
 in Fusion/Hana style metaprogramming. Additionally,<br>since this is a lan=
guage feature, we could pontentially see the same compile-time performance =
that<br>Kvasir.Mpl has without the difficult continuation interface (and it=
 works on expressions!).<br><br><br>## Additional Bonus Features<br><br>Sin=
ce the expressions maintain the context of the site of invocation we also g=
et constexpr parameters.<br><br>```cpp<br>using to_integral_constant(auto x=
) {<br>=C2=A0 return std::integral_constant&lt;int, x&gt;{};<br>}<br><br>in=
t main() {<br>=C2=A0 constexpr int x =3D 0;<br>=C2=A0 static_assert(std::is=
_same_v&lt;<wbr>std::integral_constant&lt;int, 0&gt;, decltype(to_integral_=
constant(<wbr>x)));<br>}<br>```<br><br>We also get arrays and string litera=
ls that do not decay.<br><br>```cpp<br>using id(auto x) {<br>=C2=A0 return =
x;<br>}<br><br>int main() {<br>=C2=A0 char const* foo =3D id(&quot;foo&quot=
;);<br>}<br><br>// the same as<br><br>int main() {<br>=C2=A0 char const* fo=
o =3D &quot;foo&quot;;<br>}<br>```<br><br>To top it off, we also get a clea=
n syntax for Perfect Forwarding<br>=C2=A0=C2=A0=C2=A0 <br>=C2=A0 * This ass=
umes that the input expression casts to an rvalue<br>=C2=A0 * See the rules=
 below for information on how value categories are handled<br><br>```cpp<br=
>template &lt;typename F, typename X, typename Y&gt;<br>decltype(auto) flip=
(F&amp;&amp; f, X&amp;&amp; x, y&amp;&amp; y) {<br>=C2=A0 return std::forwa=
rd&lt;F&gt;(f)(std::<wbr>forward&lt;Y&gt;(y), std::forward&lt;X&gt;(x));<br=
>}<br><br>// becomes<br><br>using flip(auto f, auto x, auto y) {<br>=C2=A0 =
return f(y, x);<br>}<br>```<br><br>## As a Member of a Class<br><br>Paramet=
ric expressions can be used as a member in conjunction with operator overlo=
ading to create an<br>invocable object:<br><br>```cpp<br>=C2=A0 struct id_f=
n {<br>=C2=A0=C2=A0=C2=A0 using operator()(auto x) {<br>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 return x;<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0 };<br><br>=C2=A0 i=
d_fn{}(42);<br><br>=C2=A0 static_assert(std::is_<wbr>invocable&lt;id_fn, in=
t&gt;::value);<br>```<br><br><br>## The Rules<br><br>1. The input parameter=
 list may contain only one parameter pack in any position.<br>=C2=A0=C2=A0=
=C2=A0 * This is afforded since we don&#39;t do type deduction<br><br>2. Th=
e input parameters may be unexpanded parameter packs.<br>=C2=A0=C2=A0=C2=A0=
 * This adds a bit more power for working with lists.<br>=C2=A0=C2=A0=C2=A0=
 * see [Multicategory][1]<br>=C2=A0<br>3. The output expression must NOT co=
ntain any unexpanded parameter packs<br>=C2=A0=C2=A0=C2=A0 * This would pre=
vent pack expansion ambiguity at the call site<br><br>4. Input parameter ty=
pe specifiers must be completely unconstrained and never have type qualifie=
rs.<br>=C2=A0=C2=A0=C2=A0 * We could possibly apply constraints to the type=
 in the future via Concepts<br><br>5. The definition is a compound statemen=
t where the final statement must either be a return statement<br>=C2=A0=C2=
=A0 or a constexpr if/else statement where each branch follows this same ru=
le.<br>=C2=A0=C2=A0=C2=A0 * There can be only one return statement which yi=
elds the output expression<br><br>6. Recursion is not allowed<br>=C2=A0=C2=
=A0=C2=A0 * Not sure if recursion would be feasible, but we could at least =
use Odin Holmes&#39; recursive<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 alias patt=
ern<br><br>7. Input parameters are expression aliases which follow differen=
t rules with regard to the evaluated<br>=C2=A0=C2=A0 type&#39;s value categ=
ory and reference type:<br>=C2=A0=C2=A0=C2=A0 1. Prvalue constant-expressio=
ns are simply pasted wherever it is used in the definition.<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This affords constexpr parameters and lite=
rals<br>=C2=A0=C2=A0=C2=A0 2. Unexpanded parameter packs are pasted where t=
he parameter is used in the expression.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 * Again note that they must be expanded wherever they are used=
 in the definition<br>=C2=A0=C2=A0=C2=A0 2. Everything else is bound to an =
lvalue reference within the compound statement implicitly.<br>=C2=A0=C2=A0=
=C2=A0 3. Expressions evaluating to an rvalue have the last evaluated use i=
n the definition cast to an<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 rvalue.=
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * The compiler should be abl=
e to determine this internally even for cases where order of<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 evaluation is unspecified.<br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This also implies that this c=
ould be used to detect order of evaluation of a function call.<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This is similar to how Rust handles imp=
licit moves!<br><br>8. Input expressions that are not constant-expressions =
will be evaluated immediately from left to right<br>=C2=A0=C2=A0 as specifi=
ed in the parameter list.<br>=C2=A0=C2=A0=C2=A0 * Note that unexpanded pack=
s are not included in this<br><br>9. The output is a generated compound sta=
tement evaluated as an expression that is specified using<br>=C2=A0=C2=A0 t=
he return statement in the definition body of the parametric expression.<br=
><br><br>I see this as potentially having a huge impact on the ability to i=
mplement ranges, expression templates,<br>metaprogramming libraries, and my=
 own pet case of nesting continuations for various purposes. It would be<br=
>really cool to get this in C++20 if it is not too late.<br><br><br>Thanks =
for looking at this!<br><br>Jason Rice<br><br>[1]: <a href=3D"https://en.wi=
kipedia.org/wiki/Multicategory" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wi=
kipedia.org%2Fwiki%2FMulticategory\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
FnaEscI4zk6QrTRVSKmBUI7F4ljg&#39;;return true;" onclick=3D"this.href=3D&#39=
;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMu=
lticategory\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFnaEscI4zk6QrTRVSKmBUI7=
F4ljg&#39;;return true;">https://en.wikipedia.org/wiki/<wbr>Multicategory</=
a><br><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
2Oe3UI1oAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"2Oe3UI1oAAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/95ae303b-329c-4121-<wbr>aa5f-=
69edf040d5b5%40isocpp.org</a><wbr>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

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

------=_Part_525_885314025.1535671276112--

------=_Part_524_1847894600.1535671276111--

.

------=_Part_547_1533519190.1535672089873
Content-Type: multipart/alternative;
 boundary="----=_Part_548_1632834600.1535672089873"

------=_Part_548_1632834600.1535672089873
Content-Type: text/plain; charset="UTF-8"

Here is what I have so far for implementation:
https://github.com/ricejasonf/clang/commits/f_alias

If you or anyone can offer any guidance or mentorship on this it would be
greatly appreciated.


On Thursday, August 30, 2018 at 3:01:36 PM UTC-7, Richard Smith wrote:
>
> I'd worry a little about such a facility being overused where people
> really just want a function with a strong "inline this please" hint (but
> then again, any feature can be misused). But this seems like an interesting
> way to address a collection of cases where people currently use macros.
>
> The paper would benefit from a collection of realistic usage examples.
>
> "Expressions evaluating to an rvalue have the last evaluated use in the
> definition cast to an rvalue.
> The compiler should be able to determine this internally even for cases
> where order of evaluation is unspecified."
>
> Can the body of the alias contain control flow constructs? I don't think
> the compiler can determine this in general. It's also unfortunate that you
> don't support (guaranteed) copy elision for rvalue parameters under any
> circumstances.
>
> On Thu, 30 Aug 2018 at 09:42, Jason Rice <ricej...@gmail.com <javascript:>>
> wrote:
>
>> Here is a write up for a language feature that I would like to have
>> considered:
>>
>> https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb
>>
>> I'm attempting to implement it in Clang, but I would like to get some
>> early feedback.
>>
>> I've already received some feedback from Louis Dionne and he encouraged
>> me to post it here.
>>
>>
>> Thanks!
>>
>>
>>
>> # Parametric Expression
>>
>> The primary purpose here is to improve compile-time performance by
>> providing a tool that augments existing
>> metaprogramming features in C++. It involves the transformation of
>> expressions.
>>
>> Essentially this feature is meant to combine the power of function
>> templates with the performance of type
>> aliases. Function templates as we have them now are loaded with features
>> such as overloading, constraints,
>> type deduction, SFINAE, ect.. When called not only do we get an expensive
>> template instantiation but also
>> potentially large symbols and extraneous code generation all for
>> functions we wouldn't call otherwise
>> unless we expected the optimizer to inline them out anyways. With this
>> tool we want to give programmers
>> the ability to allow this inlining at an earlier stage, but the solution
>> is elegant enough to provide a
>> few additional bonus features.
>>
>> Consider the following declaration syntax:
>>
>> ```cpp
>> using add(auto a, auto b) {
>>   return a + b;
>> }
>> ```
>>
>> Here is a function-like declaration where the domain and codomain are
>> expressions.
>>
>> Invoking it merely transforms the expression in the context of the site
>> of invocation.
>>
>> ```cpp
>> int main() {
>>   return add(40, 2);
>> }
>>
>> // the same as
>>
>> int main() {
>>   return 40 + 2;
>> }
>> ```
>>
>> This ability to transform expressions has the same power as type aliases,
>> but here we can work with
>> constructs that have run-time effects as seen in Fusion/Hana style
>> metaprogramming. Additionally,
>> since this is a language feature, we could pontentially see the same
>> compile-time performance that
>> Kvasir.Mpl has without the difficult continuation interface (and it works
>> on expressions!).
>>
>>
>> ## Additional Bonus Features
>>
>> Since the expressions maintain the context of the site of invocation we
>> also get constexpr parameters.
>>
>> ```cpp
>> using to_integral_constant(auto x) {
>>   return std::integral_constant<int, x>{};
>> }
>>
>> int main() {
>>   constexpr int x = 0;
>>   static_assert(std::is_same_v<std::integral_constant<int, 0>,
>> decltype(to_integral_constant(x)));
>> }
>> ```
>>
>> We also get arrays and string literals that do not decay.
>>
>> ```cpp
>> using id(auto x) {
>>   return x;
>> }
>>
>> int main() {
>>   char const* foo = id("foo");
>> }
>>
>> // the same as
>>
>> int main() {
>>   char const* foo = "foo";
>> }
>> ```
>>
>> To top it off, we also get a clean syntax for Perfect Forwarding
>>
>>   * This assumes that the input expression casts to an rvalue
>>   * See the rules below for information on how value categories are
>> handled
>>
>> ```cpp
>> template <typename F, typename X, typename Y>
>> decltype(auto) flip(F&& f, X&& x, y&& y) {
>>   return std::forward<F>(f)(std::forward<Y>(y), std::forward<X>(x));
>> }
>>
>> // becomes
>>
>> using flip(auto f, auto x, auto y) {
>>   return f(y, x);
>> }
>> ```
>>
>> ## As a Member of a Class
>>
>> Parametric expressions can be used as a member in conjunction with
>> operator overloading to create an
>> invocable object:
>>
>> ```cpp
>>   struct id_fn {
>>     using operator()(auto x) {
>>       return x;
>>     }
>>   };
>>
>>   id_fn{}(42);
>>
>>   static_assert(std::is_invocable<id_fn, int>::value);
>> ```
>>
>>
>> ## The Rules
>>
>> 1. The input parameter list may contain only one parameter pack in any
>> position.
>>     * This is afforded since we don't do type deduction
>>
>> 2. The input parameters may be unexpanded parameter packs.
>>     * This adds a bit more power for working with lists.
>>     * see [Multicategory][1]
>>
>> 3. The output expression must NOT contain any unexpanded parameter packs
>>     * This would prevent pack expansion ambiguity at the call site
>>
>> 4. Input parameter type specifiers must be completely unconstrained and
>> never have type qualifiers.
>>     * We could possibly apply constraints to the type in the future via
>> Concepts
>>
>> 5. The definition is a compound statement where the final statement must
>> either be a return statement
>>    or a constexpr if/else statement where each branch follows this same
>> rule.
>>     * There can be only one return statement which yields the output
>> expression
>>
>> 6. Recursion is not allowed
>>     * Not sure if recursion would be feasible, but we could at least use
>> Odin Holmes' recursive
>>       alias pattern
>>
>> 7. Input parameters are expression aliases which follow different rules
>> with regard to the evaluated
>>    type's value category and reference type:
>>     1. Prvalue constant-expressions are simply pasted wherever it is used
>> in the definition.
>>         * This affords constexpr parameters and literals
>>     2. Unexpanded parameter packs are pasted where the parameter is used
>> in the expression.
>>         * Again note that they must be expanded wherever they are used in
>> the definition
>>     2. Everything else is bound to an lvalue reference within the
>> compound statement implicitly.
>>     3. Expressions evaluating to an rvalue have the last evaluated use in
>> the definition cast to an
>>        rvalue.
>>         * The compiler should be able to determine this internally even
>> for cases where order of
>>           evaluation is unspecified.
>>         * This also implies that this could be used to detect order of
>> evaluation of a function call.
>>         * This is similar to how Rust handles implicit moves!
>>
>> 8. Input expressions that are not constant-expressions will be evaluated
>> immediately from left to right
>>    as specified in the parameter list.
>>     * Note that unexpanded packs are not included in this
>>
>> 9. The output is a generated compound statement evaluated as an
>> expression that is specified using
>>    the return statement in the definition body of the parametric
>> expression.
>>
>>
>> I see this as potentially having a huge impact on the ability to
>> implement ranges, expression templates,
>> metaprogramming libraries, and my own pet case of nesting continuations
>> for various purposes. It would be
>> really cool to get this in C++20 if it is not too late.
>>
>>
>> Thanks for looking at this!
>>
>> Jason Rice
>>
>> [1]: https://en.wikipedia.org/wiki/Multicategory
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1254f645-d799-42d3-af1d-90c1b24e5ee7%40isocpp.org.

------=_Part_548_1632834600.1535672089873
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Here is what I have so far for implementation: <a href=3D"=
https://github.com/ricejasonf/clang/commits/f_alias">https://github.com/ric=
ejasonf/clang/commits/f_alias<br></a><br>If you or anyone can offer any gui=
dance or mentorship on this it would be greatly appreciated.<br><br><br>On =
Thursday, August 30, 2018 at 3:01:36 PM UTC-7, Richard Smith wrote:<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>I&#39;d worry a =
little about such a facility being overused where people really just want a=
 function with a strong &quot;inline this please&quot; hint (but then again=
, any feature can be misused). But this seems like an interesting way to ad=
dress a collection of cases where people currently use macros.</div><div><b=
r></div><div>The paper would benefit from a collection of realistic usage e=
xamples.</div><div><br></div>&quot;Expressions evaluating to an rvalue have=
 the last evaluated use in the definition cast to an rvalue.<div>The compil=
er should be able to determine this internally even for cases where order o=
f evaluation is unspecified.&quot;</div><div><br></div><div>Can the body of=
 the alias contain control flow constructs? I don&#39;t think the compiler =
can determine this in general. It&#39;s also unfortunate that you don&#39;t=
 support (guaranteed) copy elision for rvalue parameters under any circumst=
ances.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 3=
0 Aug 2018 at 09:42, Jason Rice &lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"2Oe3UI1oAAAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">ricej...@gmail.com</a>&gt; wrote:<br></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">Here is a write up for a lan=
guage feature that I would like to have considered: <br><br><a href=3D"http=
s://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Fricejasonf%2F84c11ac6bb093c1e=
a8c380a9a466d8cb\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFV8-r36DHcSGyAmbxu=
Q8QTHwHKcA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.googl=
e.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Fricejasonf%2F84c11ac6bb093c1=
ea8c380a9a466d8cb\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFV8-r36DHcSGyAmbx=
uQ8QTHwHKcA&#39;;return true;">https://gist.github.com/<wbr>ricejasonf/<wbr=
>84c11ac6bb093c1ea8c380a9a466d8<wbr>cb</a><br><div><br></div><div>I&#39;m a=
ttempting to implement it in Clang, but I would like to get some early feed=
back.<br><br>I&#39;ve already received some feedback from Louis Dionne and =
he encouraged me to post it here.<br><br><br></div>Thanks!<br><br><br><br>#=
 Parametric Expression<br><br>The primary purpose here is to improve compil=
e-time performance by providing a tool that augments existing<br>metaprogra=
mming features in C++. It involves the transformation of expressions.<br><b=
r>Essentially this feature is meant to combine the power of function templa=
tes with the performance of type<br>aliases. Function templates as we have =
them now are loaded with features such as overloading, constraints,<br>type=
 deduction, SFINAE, ect.. When called not only do we get an expensive templ=
ate instantiation but also <br>potentially large symbols and extraneous cod=
e generation all for functions we wouldn&#39;t call otherwise<br>unless we =
expected the optimizer to inline them out anyways. With this tool we want t=
o give programmers<br>the ability to allow this inlining at an earlier stag=
e, but the solution is elegant enough to provide a<br>few additional bonus =
features.<br><br>Consider the following declaration syntax:<br><br>```cpp<b=
r>using add(auto a, auto b) {<br>=C2=A0 return a + b;<br>}<br>```<br><br>He=
re is a function-like declaration where the domain and codomain are express=
ions.<br><br>Invoking it merely transforms the expression in the context of=
 the site of invocation.<br><br>```cpp<br>int main() {<br>=C2=A0 return add=
(40, 2);<br>}<br><br>// the same as<br><br>int main() {<br>=C2=A0 return 40=
 + 2;<br>}<br>```<br><br>This ability to transform expressions has the same=
 power as type aliases, but here we can work with<br>constructs that have r=
un-time effects as seen in Fusion/Hana style metaprogramming. Additionally,=
<br>since this is a language feature, we could pontentially see the same co=
mpile-time performance that<br>Kvasir.Mpl has without the difficult continu=
ation interface (and it works on expressions!).<br><br><br>## Additional Bo=
nus Features<br><br>Since the expressions maintain the context of the site =
of invocation we also get constexpr parameters.<br><br>```cpp<br>using to_i=
ntegral_constant(auto x) {<br>=C2=A0 return std::integral_constant&lt;int, =
x&gt;{};<br>}<br><br>int main() {<br>=C2=A0 constexpr int x =3D 0;<br>=C2=
=A0 static_assert(std::is_same_v&lt;<wbr>std::integral_constant&lt;int, 0&g=
t;, decltype(to_integral_constant(<wbr>x)));<br>}<br>```<br><br>We also get=
 arrays and string literals that do not decay.<br><br>```cpp<br>using id(au=
to x) {<br>=C2=A0 return x;<br>}<br><br>int main() {<br>=C2=A0 char const* =
foo =3D id(&quot;foo&quot;);<br>}<br><br>// the same as<br><br>int main() {=
<br>=C2=A0 char const* foo =3D &quot;foo&quot;;<br>}<br>```<br><br>To top i=
t off, we also get a clean syntax for Perfect Forwarding<br>=C2=A0=C2=A0=C2=
=A0 <br>=C2=A0 * This assumes that the input expression casts to an rvalue<=
br>=C2=A0 * See the rules below for information on how value categories are=
 handled<br><br>```cpp<br>template &lt;typename F, typename X, typename Y&g=
t;<br>decltype(auto) flip(F&amp;&amp; f, X&amp;&amp; x, y&amp;&amp; y) {<br=
>=C2=A0 return std::forward&lt;F&gt;(f)(std::<wbr>forward&lt;Y&gt;(y), std:=
:forward&lt;X&gt;(x));<br>}<br><br>// becomes<br><br>using flip(auto f, aut=
o x, auto y) {<br>=C2=A0 return f(y, x);<br>}<br>```<br><br>## As a Member =
of a Class<br><br>Parametric expressions can be used as a member in conjunc=
tion with operator overloading to create an<br>invocable object:<br><br>```=
cpp<br>=C2=A0 struct id_fn {<br>=C2=A0=C2=A0=C2=A0 using operator()(auto x)=
 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return x;<br>=C2=A0=C2=A0=C2=A0 }<br>=
=C2=A0 };<br><br>=C2=A0 id_fn{}(42);<br><br>=C2=A0 static_assert(std::is_<w=
br>invocable&lt;id_fn, int&gt;::value);<br>```<br><br><br>## The Rules<br><=
br>1. The input parameter list may contain only one parameter pack in any p=
osition.<br>=C2=A0=C2=A0=C2=A0 * This is afforded since we don&#39;t do typ=
e deduction<br><br>2. The input parameters may be unexpanded parameter pack=
s.<br>=C2=A0=C2=A0=C2=A0 * This adds a bit more power for working with list=
s.<br>=C2=A0=C2=A0=C2=A0 * see [Multicategory][1]<br>=C2=A0<br>3. The outpu=
t expression must NOT contain any unexpanded parameter packs<br>=C2=A0=C2=
=A0=C2=A0 * This would prevent pack expansion ambiguity at the call site<br=
><br>4. Input parameter type specifiers must be completely unconstrained an=
d never have type qualifiers.<br>=C2=A0=C2=A0=C2=A0 * We could possibly app=
ly constraints to the type in the future via Concepts<br><br>5. The definit=
ion is a compound statement where the final statement must either be a retu=
rn statement<br>=C2=A0=C2=A0 or a constexpr if/else statement where each br=
anch follows this same rule.<br>=C2=A0=C2=A0=C2=A0 * There can be only one =
return statement which yields the output expression<br><br>6. Recursion is =
not allowed<br>=C2=A0=C2=A0=C2=A0 * Not sure if recursion would be feasible=
, but we could at least use Odin Holmes&#39; recursive<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 alias pattern<br><br>7. Input parameters are expression ali=
ases which follow different rules with regard to the evaluated<br>=C2=A0=C2=
=A0 type&#39;s value category and reference type:<br>=C2=A0=C2=A0=C2=A0 1. =
Prvalue constant-expressions are simply pasted wherever it is used in the d=
efinition.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This affords con=
stexpr parameters and literals<br>=C2=A0=C2=A0=C2=A0 2. Unexpanded paramete=
r packs are pasted where the parameter is used in the expression.<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Again note that they must be expande=
d wherever they are used in the definition<br>=C2=A0=C2=A0=C2=A0 2. Everyth=
ing else is bound to an lvalue reference within the compound statement impl=
icitly.<br>=C2=A0=C2=A0=C2=A0 3. Expressions evaluating to an rvalue have t=
he last evaluated use in the definition cast to an<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 rvalue.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * The=
 compiler should be able to determine this internally even for cases where =
order of<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 evaluati=
on is unspecified.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This als=
o implies that this could be used to detect order of evaluation of a functi=
on call.<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * This is similar to=
 how Rust handles implicit moves!<br><br>8. Input expressions that are not =
constant-expressions will be evaluated immediately from left to right<br>=
=C2=A0=C2=A0 as specified in the parameter list.<br>=C2=A0=C2=A0=C2=A0 * No=
te that unexpanded packs are not included in this<br><br>9. The output is a=
 generated compound statement evaluated as an expression that is specified =
using<br>=C2=A0=C2=A0 the return statement in the definition body of the pa=
rametric expression.<br><br><br>I see this as potentially having a huge imp=
act on the ability to implement ranges, expression templates,<br>metaprogra=
mming libraries, and my own pet case of nesting continuations for various p=
urposes. It would be<br>really cool to get this in C++20 if it is not too l=
ate.<br><br><br>Thanks for looking at this!<br><br>Jason Rice<br><br>[1]: <=
a href=3D"https://en.wikipedia.org/wiki/Multicategory" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q=
\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMulticategory\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNFnaEscI4zk6QrTRVSKmBUI7F4ljg&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wi=
kipedia.org%2Fwiki%2FMulticategory\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
FnaEscI4zk6QrTRVSKmBUI7F4ljg&#39;;return true;">https://en.wikipedia.org/wi=
ki/<wbr>Multicategory</a><br><br></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
2Oe3UI1oAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"2Oe3UI1oAAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/95ae303b-329c-4121-aa5f-69edf040d5b5%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/95ae303b-329c-4121-<wbr>aa5f-=
69edf040d5b5%40isocpp.org</a><wbr>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

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

------=_Part_548_1632834600.1535672089873--

------=_Part_547_1533519190.1535672089873--

.

------=_Part_520_2074341922.1535675656539
Content-Type: text/plain; charset="UTF-8"

Can I pass one of these things into a function template? For instance:

std::vector v{1, 2  3};
auto sum = std::accumulate(v.begin(), v.end(), 0, add);

Does that work? How?

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

------=_Part_520_2074341922.1535675656539--

.

--000000000000b07a3f0574b08be3
Content-Type: text/plain; charset="UTF-8"

>
> Can I pass one of these things into a function template?
>

No, not directly, but you could make it the member of a class to make an
invokable object.

Something like:

```
struct add {
  using operator()(auto x, auto y) { return x + y; }
};
```

I should probably add a note about an implicit `this` and possibly an
optional const qualifier for when it is a member. (or mutable?)

On Thu, Aug 30, 2018 at 5:34 PM Barry Revzin <barry.revzin@gmail.com> wrote:

> Can I pass one of these things into a function template? For instance:
>
> std::vector v{1, 2  3};
> auto sum = std::accumulate(v.begin(), v.end(), 0, add);
>
> Does that work? How?
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6398037-049e-427e-8351-abf12acb60d4%40isocpp.org
> .
>

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

--000000000000b07a3f0574b08be3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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">Can I pa=
ss one of these things into a function template?<br></blockquote><div><br><=
/div><div>No, not directly, but you could make it the member of a class to =
make an invokable object.<br><br></div><div>Something like:<br><br>```<br><=
/div><div>struct add {<br></div><div>=C2=A0 using operator()(auto x, auto y=
) { return x + y; }<br>};<br></div><div>```<br><br></div><div>I should prob=
ably add a note about an implicit `this` and possibly an optional const qua=
lifier for when it is a member. (or mutable?)<br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Thu, Aug 30, 2018 at 5:34 PM Barry Rev=
zin &lt;<a href=3D"mailto:barry.revzin@gmail.com">barry.revzin@gmail.com</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can I pass one of thes=
e things into a function template? For instance:<br>
<br>
std::vector v{1, 2=C2=A0 3};<br>
auto sum =3D std::accumulate(v.begin(), v.end(), 0, add);<br>
<br>
Does that work? How?<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%2Bunsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f6398037-049e-427e-8351-abf12acb60d4%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/f6398037-049e-427e-8351-abf12acb60d4%4=
0isocpp.org</a>.<br>
</blockquote></div>

<p></p>

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

--000000000000b07a3f0574b08be3--

.

------=_Part_567_1667938558.1535691289488
Content-Type: text/plain; charset="UTF-8"

I faail to understand how this differs from doing the same but replacing the using with auto. If you worry about compile times there is nothing that hinders current clmpikers from taking a shortcut if all parameter types are plain auto...

Please provide an example of code that can be written using this feature but not with auto return type. Preferably understandable without requiring too much knowledge of higher math.

To me it would be more interesting if we could replace a larger subset of macros, maybe 'using' as a parameter type which substitutes in the body at an early parsing phase or something like that...

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/53248610-d4ed-4a28-b5f8-bf7c61247eb9%40isocpp.org.

------=_Part_567_1667938558.1535691289488--

.

--0000000000001efe020574b6962d
Content-Type: text/plain; charset="UTF-8"

Admittedly, compile time performance is the main motivation here. Think of
this as having the same utility that a type alias template has over using a
class template.

However, there are a couple of things that this can do that normal
functions cannot because we are just generating AST in the same
context/scope as where it is invoked.

Here is an example of constexpr parameters:

```
#include <type_traits>

template <bool>
struct unpack_string_t;

template <>
struct unpack_string_t<false> {
  using operator()(auto str, auto ...chars, auto fn) {
    if constexpr(str[sizeof...(chars)] == 0) {
      return fn(chars...);
    }
    else {
      return unpack_string<sizeof...(chars) > 9000>{}(str, chars...,

str[sizeof...(chars)], fn);
    }
  }
};

inline constexpr unpack_string_t unpack_string;

template <char...>
struct ct_string { };

struct make_ct_string_t {
  using operator()(auto ...chars) {
    return ct_string<chars...>{};
  }
};

inline constexpr make_ct_string_t make_ct_string;


int main() {
  ct_string<'f', 'o', 'o'> x = unpack_string("foo", make_ct_string);
}
```

To me it would be more interesting if we could replace a larger subset of
> macros, maybe 'using' as a parameter type which substitutes in the body at
> an early parsing phase or something like that...


I'm not sure what you mean by "replace a larger subset of macros".

Having any parameter in a normal function have the ability to be a "using"
parameter sounds interesting, but function scope is isolated so arbitrary
expressions would be out. If "using" parameters were just constexpr values
then that function would have a different type for every value it was
invoked with.

On Thu, Aug 30, 2018 at 9:54 PM Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> I faail to understand how this differs from doing the same but replacing
> the using with auto. If you worry about compile times there is nothing that
> hinders current clmpikers from taking a shortcut if all parameter types are
> plain auto...
>
> Please provide an example of code that can be written using this feature
> but not with auto return type. Preferably understandable without requiring
> too much knowledge of higher math.
>
> To me it would be more interesting if we could replace a larger subset of
> macros, maybe 'using' as a parameter type which substitutes in the body at
> an early parsing phase or something like that...
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/53248610-d4ed-4a28-b5f8-bf7c61247eb9%40isocpp.org
> .
>

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

--0000000000001efe020574b6962d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Admittedly, compile time performance is t=
he main motivation here. Think of this as having the same utility that a ty=
pe alias template has over using a class template.<br><br>However, there ar=
e a couple of things that this can do that normal functions cannot because =
we are just generating AST in the same context/scope as where it is invoked=
..<br><br>Here is an example of constexpr parameters:<br><br>```<br>#include=
 &lt;type_traits&gt;<br><br>template &lt;bool&gt;<br>struct unpack_string_t=
;<br><br>template &lt;&gt;<br>struct unpack_string_t&lt;false&gt; {<br>=C2=
=A0 using operator()(auto str, auto ...chars, auto fn) {<br>=C2=A0=C2=A0=C2=
=A0 if constexpr(str[sizeof...(chars)] =3D=3D 0) {<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 return fn(chars...);<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0=C2=A0=C2=
=A0 else {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return unpack_string&lt;sizeof=
....(chars) &gt; 9000&gt;{}(str, chars...,<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 str[sizeof.=
...(chars)], fn);<br>=C2=A0=C2=A0=C2=A0 }<br>=C2=A0 }<br>};<br><br>inline co=
nstexpr unpack_string_t unpack_string;<br><br>template &lt;char...&gt;<br>s=
truct ct_string { };<br><br>struct make_ct_string_t {<br>=C2=A0 using opera=
tor()(auto ...chars) {<br>=C2=A0=C2=A0=C2=A0 return ct_string&lt;chars...&g=
t;{};<br>=C2=A0 }<br>};<br><br>inline constexpr make_ct_string_t make_ct_st=
ring;<br><br><br>int main() {<br>=C2=A0 ct_string&lt;&#39;f&#39;, &#39;o&#3=
9;, &#39;o&#39;&gt; x =3D unpack_string(&quot;foo&quot;, make_ct_string);<b=
r>}<br>```<br><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">To me i=
t would be more interesting if we could replace a larger subset=20
of macros, maybe &#39;using&#39; as a parameter type which substitutes in t=
he=20
body at an early parsing phase or something like that... </blockquote><div>=
<br>I&#39;m not sure what you mean by &quot;replace a larger subset of macr=
os&quot;.<br><br></div><div>Having any parameter in a normal function have =
the ability to be a &quot;using&quot; parameter sounds interesting, but fun=
ction scope is isolated so arbitrary expressions would be out. If &quot;usi=
ng&quot; parameters were just constexpr values then that function would hav=
e a different type for every value it was invoked with.<br></div></div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Aug 30, 2018 at 9=
:54 PM Bengt Gustafsson &lt;<a href=3D"mailto:bengt.gustafsson@beamways.com=
">bengt.gustafsson@beamways.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">I faail to understand how this differs from doing the same bu=
t replacing the using with auto. If you worry about compile times there is =
nothing that hinders current clmpikers from taking a shortcut if all parame=
ter types are plain auto...<br>
<br>
Please provide an example of code that can be written using this feature bu=
t not with auto return type. Preferably understandable without requiring to=
o much knowledge of higher math.<br>
<br>
To me it would be more interesting if we could replace a larger subset of m=
acros, maybe &#39;using&#39; as a parameter type which substitutes in the b=
ody at an early parsing phase or something like that... <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%2Bunsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/53248610-d4ed-4a28-b5f8-bf7c61247eb9%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/53248610-d4ed-4a28-b5f8-bf7c61247eb9%4=
0isocpp.org</a>.<br>
</blockquote></div>

<p></p>

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

--0000000000001efe020574b6962d--

.

------=_Part_721_1153808537.1535725354127
Content-Type: text/plain; charset="UTF-8"

would the following work:

using forward(auto x) { return std::forward<decltype(x)&&>(x); }

using lazy(auto x) { return[]{return x;};  }
auto x = lazy(func());
x(); //calls func()

if so maybe allowing those to be used as custom type conversion could be interesting :

lazy x = func();
void f(lazy{} x);
f(func());

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1cc9f0c3-058a-4063-91c5-1b19107cae79%40isocpp.org.

------=_Part_721_1153808537.1535725354127--

.

--0000000000005efb930574bc0d4c
Content-Type: text/plain; charset="UTF-8"

On Fri, 31 Aug 2018 at 16:22, <swac31@gmail.com> wrote:

> would the following work:
>
> using forward(auto x) { return std::forward<decltype(x)&&>(x); }
>

I think this is brilliant. It's essentially namespace-scoped macros, but
better. It solves the problem of the unfriendly std::forward without
changing the language or polluting the global namespace.


>
> using lazy(auto x) { return[]{return x;};  }
> auto x = lazy(func());
> x(); //calls func()


> if so maybe allowing those to be used as custom type conversion could be
> interesting :
>
> lazy x = func();
> void f(lazy{} x);
> f(func());
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1cc9f0c3-058a-4063-91c5-1b19107cae79%40isocpp.org
> .
>

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

--0000000000005efb930574bc0d4c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri=
, 31 Aug 2018 at 16:22, &lt;<a href=3D"mailto:swac31@gmail.com">swac31@gmai=
l.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">would the foll=
owing work:<br>
<br>
using forward(auto x) { return std::forward&lt;decltype(x)&amp;&amp;&gt;(x)=
; }<br></blockquote><div><br></div><div>I think this is brilliant. It&#39;s=
 essentially namespace-scoped macros, but better. It solves the problem of =
the unfriendly std::forward without changing the language or polluting the =
global namespace.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
using lazy(auto x) { return[]{return x;};=C2=A0 }<br>
auto x =3D lazy(func());<br>
x(); //calls func()</blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
if so maybe allowing those to be used as custom type conversion could be in=
teresting :<br>
<br>
lazy x =3D func();<br>
void f(lazy{} x);<br>
f(func()); <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%2Bunsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1cc9f0c3-058a-4063-91c5-1b19107cae79%=
40isocpp.org" rel=3D"noreferrer" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/d/msgid/std-proposals/1cc9f0c3-058a-4063-91c5-1b19107cae79%4=
0isocpp.org</a>.<br>
</blockquote></div></div>

<p></p>

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

--0000000000005efb930574bc0d4c--

.

------=_Part_731_510942925.1535730207858
Content-Type: multipart/alternative;
 boundary="----=_Part_732_1017373408.1535730207858"

------=_Part_732_1017373408.1535730207858
Content-Type: text/plain; charset="UTF-8"


>
> auto x = lazy(func());
>

So here is the problem with pasting the expression when it can contain side
effects. Intuitively, the user expects `func()` to be evaluated immediately.
This is the reason the rules as they are written now only allow pasting the
expression if it evaluates to a prvalue contstant-expression.

So, unless we are willing to throw inhibition to the wind, I don't know
that is a good idea to paste expressions that could contain side effects
(contradictory to what I said earlier).

That does seem very powerful though.

On Friday, August 31, 2018 at 7:22:34 AM UTC-7, swa...@gmail.com wrote:
>
> would the following work:
>
> using forward(auto x) { return std::forward<decltype(x)&&>(x); }
>
> using lazy(auto x) { return[]{return x;};  }
> auto x = lazy(func());
> x(); //calls func()
>
> if so maybe allowing those to be used as custom type conversion could be
> interesting :
>
> lazy x = func();
> void f(lazy{} x);
> f(func());
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a186bc7f-81ea-4430-8e63-56ae706dee3f%40isocpp.org.

------=_Part_732_1017373408.1535730207858
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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;">=
auto x =3D lazy(func());<br></blockquote><div><br></div><div>So here is the=
 problem with pasting the expression when it can contain side effects. Intu=
itively, the user expects `func()` to be evaluated immediately.<br>This is =
the reason the rules as they are written now only allow pasting the express=
ion if it evaluates to a prvalue contstant-expression.<br></div><div><br>So=
, unless we are willing to throw inhibition to the wind, I don&#39;t know t=
hat is a good idea to paste expressions that could contain side effects (co=
ntradictory to what I said earlier).<br><br>That does seem very powerful th=
ough.<br><br></div>On Friday, August 31, 2018 at 7:22:34 AM UTC-7, swa...@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;">would the follo=
wing work:<p>using forward(auto x) { return std::forward&lt;decltype(x)&amp=
;&amp;&gt;(x)<wbr>; }</p><p>using lazy(auto x) { return[]{return x;}; =C2=
=A0}<br>auto x =3D lazy(func());<br>x(); //calls func()</p><p>if so maybe a=
llowing those to be used as custom type conversion could be interesting :</=
p><p>lazy x =3D func();<br>void f(lazy{} x);<br>f(func()); </p><p></p><p></=
p><p></p></blockquote></div>

<p></p>

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

------=_Part_732_1017373408.1535730207858--

------=_Part_731_510942925.1535730207858--

.

------=_Part_822_1325606780.1535732264898
Content-Type: text/plain; charset="UTF-8"

On the abuse of inlining I believe that implementations could create hidden fuctions if inlining is too colstly as long as it doesn't impact semantics.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/80215dcb-875f-42c0-8f7f-e8030c2145e7%40isocpp.org.

------=_Part_822_1325606780.1535732264898--

.

------=_Part_1267_410580970.1536610433948
Content-Type: multipart/alternative;
 boundary="----=_Part_1268_2019707358.1536610433948"

------=_Part_1268_2019707358.1536610433948
Content-Type: text/plain; charset="UTF-8"

The feedback on this so far has been greatly appreciated.

I added a couple of examples and refactored the rules to address some of
the concerns that were brought up.

https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb

On Friday, August 31, 2018 at 9:17:44 AM UTC-7, swa...@gmail.com wrote:
>
> On the abuse of inlining I believe that implementations could create
> hidden fuctions if inlining is too colstly as long as it doesn't impact
> semantics.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ab3a09d5-6c45-43d1-9666-9749dbf7051c%40isocpp.org.

------=_Part_1268_2019707358.1536610433948
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The feedback on this so far has been greatly appreciated.<=
br><br>I added a couple of examples and refactored the rules to address som=
e of the concerns that were brought up.<br><br><a href=3D"https://gist.gith=
ub.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb">https://gist.github.com=
/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb</a><br><br>On Friday, August 3=
1, 2018 at 9:17:44 AM UTC-7, swa...@gmail.com wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">On the abuse of inlining I believe that implementatio=
ns could create hidden fuctions if inlining is too colstly as long as it do=
esn&#39;t impact semantics. </blockquote></div>

<p></p>

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

------=_Part_1268_2019707358.1536610433948--

------=_Part_1267_410580970.1536610433948--

.

Hi Jason,

On Mon, Sep 10, 2018 at 10:13 PM, Jason Rice <ricejasonf@gmail.com> wrote:
> The feedback on this so far has been greatly appreciated.
>
> I added a couple of examples and refactored the rules to address some of the
> concerns that were brought up.
>
> https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb


We had a quick discussion a few months ago [1] on how to implement
something that would allow you to write things like:

    x = x || new int;

In other words, an operator|| with short-circuit semantics. There were
suggestions on changing the language (the topic starter), on
standardizing language extensions (the binary ?: GNU operator) and on
doing some tricks with a macro and a lambda, e.g:

    #define LAZY(x) [](){ return (x); }

    template <typename T, typename E>
    T operator||(T p, E e)
    {
        if (p)
            return p;
        return e();
    }

    x = x || LAZY(new int);

Half-jokingly, I suggested working with expressions instead would look
very nice and would allow to implement these things directly in the
language, e.g.:

    template <typename T, expression E>
    T operator||(T p, E e)
    {
        if (p)
            return p;
        return e;
    }

    x = x || new int;

How would your add() example look using this "expression" syntax?
Maybe something like:

    template <typename T, expression E>
    E add(T a, T b)
    {
        return a + b;
    }

Now, the other way around, let's take a look at the operator||()
example using your "using" syntax:

    using operator||(auto p, ???) {
        if (p)
            return p;
        return ???;
    }

Almost there! I am sure you are seeing what I am getting at here. If
we are going to get almost-macro-like entities, we are basically
talking about manipulating (or rather, being able to express)
expressions. Your approach, if I interpreted it correctly, allows to
return a C++ expression given a function-like call, but does not allow
to pick expressions themselves as parameters --- which would allow to
implement things like those short-circuit operators and replace even
more macros.

We could implement operators already existing in the language in terms
of the language itself:

    using myOwnTernary(auto c, expression t, expression f) {
        if (c)
            return t;
        return f;
    }

    // foo() only called if the condition is true
    int x = myOwnTernary(something, 1, foo());

Inexpensive logging is another place where it is useful (to avoid
evaluating parameters, e.g. Boost's LOG_WARNING):

    using logWarning(expression... es) {
        if (level >= warning)
            doLog(es...);
    }

Think about it!

Cheers,
Miguel

[1] https://groups.google.com/a/isocpp.org/d/msg/std-proposals/jB5TIcRZeic/qZqxtxSDAQAJ

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

.

------=_Part_30_1636544197.1536775534432
Content-Type: multipart/alternative;
 boundary="----=_Part_31_2043154518.1536775534432"

------=_Part_31_2043154518.1536775534432
Content-Type: text/plain; charset="UTF-8"

Perhaps we should consider adding provisions for those specific operators
(ie operator&& operator||) because that would be very useful. I can only
imagine they lose their short-circuiting properties when overloaded because
of the legacy of normal functions.

All of the parameters to this "using" function are expressions, but in
cases where that would be a pitfall, we are substituting it with an lvalue
to the result of the expression. This is tentative, and some have suggested
it behave more like a function and always treat the params as lvalues. For
me personally, the issue is tertiary to having something like a function
that doesn't produce a type. (constexpr params are high up there too though)

As it stands now this feature guarantees the operands are evaluated exactly
once, but I will consider adding provisional items to address short circuit
evaluation for those specific operators. (somehow)

A special class of parameter that would allow the omission of evaluation is
something that is possible to add separately so I will leave it out for
this initial feature request.

Thanks!

On Wednesday, September 12, 2018 at 9:26:40 AM UTC-7, Miguel Ojeda wrote:
>
> Hi Jason,
>
> On Mon, Sep 10, 2018 at 10:13 PM, Jason Rice <ricej...@gmail.com
> <javascript:>> wrote:
> > The feedback on this so far has been greatly appreciated.
> >
> > I added a couple of examples and refactored the rules to address some of
> the
> > concerns that were brought up.
> >
> > https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb
>
>
> We had a quick discussion a few months ago [1] on how to implement
> something that would allow you to write things like:
>
>     x = x || new int;
>
> In other words, an operator|| with short-circuit semantics. There were
> suggestions on changing the language (the topic starter), on
> standardizing language extensions (the binary ?: GNU operator) and on
> doing some tricks with a macro and a lambda, e.g:
>
>     #define LAZY(x) [](){ return (x); }
>
>     template <typename T, typename E>
>     T operator||(T p, E e)
>     {
>         if (p)
>             return p;
>         return e();
>     }
>
>     x = x || LAZY(new int);
>
> Half-jokingly, I suggested working with expressions instead would look
> very nice and would allow to implement these things directly in the
> language, e.g.:
>
>     template <typename T, expression E>
>     T operator||(T p, E e)
>     {
>         if (p)
>             return p;
>         return e;
>     }
>
>     x = x || new int;
>
> How would your add() example look using this "expression" syntax?
> Maybe something like:
>
>     template <typename T, expression E>
>     E add(T a, T b)
>     {
>         return a + b;
>     }
>
> Now, the other way around, let's take a look at the operator||()
> example using your "using" syntax:
>
>     using operator||(auto p, ???) {
>         if (p)
>             return p;
>         return ???;
>     }
>
> Almost there! I am sure you are seeing what I am getting at here. If
> we are going to get almost-macro-like entities, we are basically
> talking about manipulating (or rather, being able to express)
> expressions. Your approach, if I interpreted it correctly, allows to
> return a C++ expression given a function-like call, but does not allow
> to pick expressions themselves as parameters --- which would allow to
> implement things like those short-circuit operators and replace even
> more macros.
>
> We could implement operators already existing in the language in terms
> of the language itself:
>
>     using myOwnTernary(auto c, expression t, expression f) {
>         if (c)
>             return t;
>         return f;
>     }
>
>     // foo() only called if the condition is true
>     int x = myOwnTernary(something, 1, foo());
>
> Inexpensive logging is another place where it is useful (to avoid
> evaluating parameters, e.g. Boost's LOG_WARNING):
>
>     using logWarning(expression... es) {
>         if (level >= warning)
>             doLog(es...);
>     }
>
> Think about it!
>
> Cheers,
> Miguel
>
> [1]
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/jB5TIcRZeic/qZqxtxSDAQAJ
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b0b395d6-a221-41a7-8ec6-08b83576cda0%40isocpp.org.

------=_Part_31_2043154518.1536775534432
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Perhaps we should consider adding provisions for those spe=
cific operators (ie operator&amp;&amp; operator||) because that would be ve=
ry useful. I can only imagine they lose their short-circuiting properties w=
hen overloaded because of the legacy of normal functions.<br><br><div>All o=
f the parameters to this &quot;using&quot; function are expressions, but in=
 cases where that would be a pitfall, we are substituting it with an lvalue=
 to the result of the expression. This is tentative, and some have suggeste=
d it behave more like a function and always treat the params as lvalues. Fo=
r me personally, the issue is tertiary to having something like a function =
that doesn&#39;t produce a type. (constexpr params are high up there too th=
ough)<br></div><div><br></div><div>As it stands now this feature guarantees=
 the operands are evaluated exactly once, but I will consider adding provis=
ional items to address short circuit evaluation for those specific operator=
s. (somehow)<br></div><div><br>A special class of parameter that would allo=
w the omission of evaluation is something that is possible to add separatel=
y so I will leave it out for this initial feature request.<br><br></div><di=
v>Thanks!<br></div><br>On Wednesday, September 12, 2018 at 9:26:40 AM UTC-7=
, Miguel Ojeda wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi Jason,
<br>
<br>On Mon, Sep 10, 2018 at 10:13 PM, Jason Rice &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"y6iFvtQUBwAJ" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">ricej...@gmail.com</a>&gt; =
wrote:
<br>&gt; The feedback on this so far has been greatly appreciated.
<br>&gt;
<br>&gt; I added a couple of examples and refactored the rules to address s=
ome of the
<br>&gt; concerns that were brought up.
<br>&gt;
<br>&gt; <a href=3D"https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c3=
80a9a466d8cb" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Fric=
ejasonf%2F84c11ac6bb093c1ea8c380a9a466d8cb\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNFV8-r36DHcSGyAmbxuQ8QTHwHKcA&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Fri=
cejasonf%2F84c11ac6bb093c1ea8c380a9a466d8cb\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNFV8-r36DHcSGyAmbxuQ8QTHwHKcA&#39;;return true;">https://gist.githu=
b.com/<wbr>ricejasonf/<wbr>84c11ac6bb093c1ea8c380a9a466d8<wbr>cb</a>
<br>
<br>
<br>We had a quick discussion a few months ago [1] on how to implement
<br>something that would allow you to write things like:
<br>
<br>=C2=A0 =C2=A0 x =3D x || new int;
<br>
<br>In other words, an operator|| with short-circuit semantics. There were
<br>suggestions on changing the language (the topic starter), on
<br>standardizing language extensions (the binary ?: GNU operator) and on
<br>doing some tricks with a macro and a lambda, e.g:
<br>
<br>=C2=A0 =C2=A0 #define LAZY(x) [](){ return (x); }
<br>
<br>=C2=A0 =C2=A0 template &lt;typename T, typename E&gt;
<br>=C2=A0 =C2=A0 T operator||(T p, E e)
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (p)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return p;
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return e();
<br>=C2=A0 =C2=A0 }
<br>
<br>=C2=A0 =C2=A0 x =3D x || LAZY(new int);
<br>
<br>Half-jokingly, I suggested working with expressions instead would look
<br>very nice and would allow to implement these things directly in the
<br>language, e.g.:
<br>
<br>=C2=A0 =C2=A0 template &lt;typename T, expression E&gt;
<br>=C2=A0 =C2=A0 T operator||(T p, E e)
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (p)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return p;
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return e;
<br>=C2=A0 =C2=A0 }
<br>
<br>=C2=A0 =C2=A0 x =3D x || new int;
<br>
<br>How would your add() example look using this &quot;expression&quot; syn=
tax?
<br>Maybe something like:
<br>
<br>=C2=A0 =C2=A0 template &lt;typename T, expression E&gt;
<br>=C2=A0 =C2=A0 E add(T a, T b)
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return a + b;
<br>=C2=A0 =C2=A0 }
<br>
<br>Now, the other way around, let&#39;s take a look at the operator||()
<br>example using your &quot;using&quot; syntax:
<br>
<br>=C2=A0 =C2=A0 using operator||(auto p, ???) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (p)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return p;
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return ???;
<br>=C2=A0 =C2=A0 }
<br>
<br>Almost there! I am sure you are seeing what I am getting at here. If
<br>we are going to get almost-macro-like entities, we are basically
<br>talking about manipulating (or rather, being able to express)
<br>expressions. Your approach, if I interpreted it correctly, allows to
<br>return a C++ expression given a function-like call, but does not allow
<br>to pick expressions themselves as parameters --- which would allow to
<br>implement things like those short-circuit operators and replace even
<br>more macros.
<br>
<br>We could implement operators already existing in the language in terms
<br>of the language itself:
<br>
<br>=C2=A0 =C2=A0 using myOwnTernary(auto c, expression t, expression f) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (c)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return t;
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return f;
<br>=C2=A0 =C2=A0 }
<br>
<br>=C2=A0 =C2=A0 // foo() only called if the condition is true
<br>=C2=A0 =C2=A0 int x =3D myOwnTernary(something, 1, foo());
<br>
<br>Inexpensive logging is another place where it is useful (to avoid
<br>evaluating parameters, e.g. Boost&#39;s LOG_WARNING):
<br>
<br>=C2=A0 =C2=A0 using logWarning(expression... es) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (level &gt;=3D warning)
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 doLog(es...);
<br>=C2=A0 =C2=A0 }
<br>
<br>Think about it!
<br>
<br>Cheers,
<br>Miguel
<br>
<br>[1] <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposa=
ls/jB5TIcRZeic/qZqxtxSDAQAJ" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/std-propo=
sals/jB5TIcRZeic/qZqxtxSDAQAJ&#39;;return true;" onclick=3D"this.href=3D&#3=
9;https://groups.google.com/a/isocpp.org/d/msg/std-proposals/jB5TIcRZeic/qZ=
qxtxSDAQAJ&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/d=
/msg/std-<wbr>proposals/jB5TIcRZeic/<wbr>qZqxtxSDAQAJ</a>
<br></blockquote></div>

<p></p>

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

------=_Part_31_2043154518.1536775534432--

------=_Part_30_1636544197.1536775534432--

.

Hi Jason,

On Wed, Sep 12, 2018 at 8:05 PM, Jason Rice <ricejasonf@gmail.com> wrote:
> Perhaps we should consider adding provisions for those specific operators
> (ie operator&& operator||) because that would be very useful. I can only
> imagine they lose their short-circuiting properties when overloaded because
> of the legacy of normal functions.

I think the interesting part is trying to do this general enough so
that it can be done for any call. Doing it for just a hardcoded set of
operators as a special case like we have now is not buying us much.

>
> All of the parameters to this "using" function are expressions, but in cases
> where that would be a pitfall, we are substituting it with an lvalue to the
> result of the expression. This is tentative, and some have suggested it
> behave more like a function and always treat the params as lvalues. For me

I see. That would kill many of the interesting use cases, sadly.

> personally, the issue is tertiary to having something like a function that
> doesn't produce a type. (constexpr params are high up there too though)
>
> As it stands now this feature guarantees the operands are evaluated exactly
> once, but I will consider adding provisional items to address short circuit
> evaluation for those specific operators. (somehow)

You mean in the case you always substitute them by an lvalue?
Otherwise, if they are expressions, I would say they might not be
evaluated at all in some cases, and in other cases more than once ---
which is what is interesting about this kind of proposals and what
makes them a usable, safer replacement to macros.

Thanks for your work on this proposal!

Cheers,
Miguel

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

.

------=_Part_99_2001173680.1536784521132
Content-Type: multipart/alternative;
 boundary="----=_Part_100_1497444628.1536784521132"

------=_Part_100_1497444628.1536784521132
Content-Type: text/plain; charset="UTF-8"


>
> I think the interesting part is trying to do this general enough so
> that it can be done for any call. Doing it for just a hardcoded set of
> operators as a special case like we have now is not buying us much.
>

You're right. The special class of parameter that is opt-in and does what
you're suggesting is probably the way to go though. I'm definitely chewing
on this.

Perhaps it could look something like this:

using foo(auto expr1, using auto expr2) {
  // expr1 is evaluated and treated as an lvalue
  // expr2 is pasted anywhere and not necessarily evaluated
}




On Wednesday, September 12, 2018 at 1:03:38 PM UTC-7, Miguel Ojeda wrote:
>
> Hi Jason,
>
> On Wed, Sep 12, 2018 at 8:05 PM, Jason Rice <ricej...@gmail.com
> <javascript:>> wrote:
> > Perhaps we should consider adding provisions for those specific
> operators
> > (ie operator&& operator||) because that would be very useful. I can only
> > imagine they lose their short-circuiting properties when overloaded
> because
> > of the legacy of normal functions.
>
> I think the interesting part is trying to do this general enough so
> that it can be done for any call. Doing it for just a hardcoded set of
> operators as a special case like we have now is not buying us much.
>
> >
> > All of the parameters to this "using" function are expressions, but in
> cases
> > where that would be a pitfall, we are substituting it with an lvalue to
> the
> > result of the expression. This is tentative, and some have suggested it
> > behave more like a function and always treat the params as lvalues. For
> me
>
> I see. That would kill many of the interesting use cases, sadly.
>
> > personally, the issue is tertiary to having something like a function
> that
> > doesn't produce a type. (constexpr params are high up there too though)
> >
> > As it stands now this feature guarantees the operands are evaluated
> exactly
> > once, but I will consider adding provisional items to address short
> circuit
> > evaluation for those specific operators. (somehow)
>
> You mean in the case you always substitute them by an lvalue?
> Otherwise, if they are expressions, I would say they might not be
> evaluated at all in some cases, and in other cases more than once ---
> which is what is interesting about this kind of proposals and what
> makes them a usable, safer replacement to macros.
>
> Thanks for your work on this proposal!
>
> Cheers,
> Miguel
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ee86c093-0fc8-43c8-bcaa-011a22f745b5%40isocpp.org.

------=_Part_100_1497444628.1536784521132
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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;">=
I think the interesting part is trying to do this general enough so
<br>that it can be done for any call. Doing it for just a hardcoded set of
<br>operators as a special case like we have now is not buying us much.
<br></blockquote><div><br>You&#39;re right. The special class of parameter =
that is opt-in and does what you&#39;re suggesting is probably the way to g=
o though. I&#39;m definitely chewing on this.<br><br>Perhaps it could look =
something like this:<br><br><div style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">using</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> expr1=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> expr2</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
 expr1 is evaluated and treated as an lvalue</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #=
800;" class=3D"styled-by-prettify">// expr2 is pasted anywhere and not nece=
ssarily evaluated</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span></div></code></div><br><br><br><br></div>On Wednesday, September 1=
2, 2018 at 1:03:38 PM UTC-7, Miguel Ojeda wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">Hi Jason,
<br>
<br>On Wed, Sep 12, 2018 at 8:05 PM, Jason Rice &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"QLJukasgBwAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">ricej...@gmail.com</a>&gt; w=
rote:
<br>&gt; Perhaps we should consider adding provisions for those specific op=
erators
<br>&gt; (ie operator&amp;&amp; operator||) because that would be very usef=
ul. I can only
<br>&gt; imagine they lose their short-circuiting properties when overloade=
d because
<br>&gt; of the legacy of normal functions.
<br>
<br>I think the interesting part is trying to do this general enough so
<br>that it can be done for any call. Doing it for just a hardcoded set of
<br>operators as a special case like we have now is not buying us much.
<br>
<br>&gt;
<br>&gt; All of the parameters to this &quot;using&quot; function are expre=
ssions, but in cases
<br>&gt; where that would be a pitfall, we are substituting it with an lval=
ue to the
<br>&gt; result of the expression. This is tentative, and some have suggest=
ed it
<br>&gt; behave more like a function and always treat the params as lvalues=
.. For me
<br>
<br>I see. That would kill many of the interesting use cases, sadly.
<br>
<br>&gt; personally, the issue is tertiary to having something like a funct=
ion that
<br>&gt; doesn&#39;t produce a type. (constexpr params are high up there to=
o though)
<br>&gt;
<br>&gt; As it stands now this feature guarantees the operands are evaluate=
d exactly
<br>&gt; once, but I will consider adding provisional items to address shor=
t circuit
<br>&gt; evaluation for those specific operators. (somehow)
<br>
<br>You mean in the case you always substitute them by an lvalue?
<br>Otherwise, if they are expressions, I would say they might not be
<br>evaluated at all in some cases, and in other cases more than once ---
<br>which is what is interesting about this kind of proposals and what
<br>makes them a usable, safer replacement to macros.
<br>
<br>Thanks for your work on this proposal!
<br>
<br>Cheers,
<br>Miguel
<br></blockquote></div>

<p></p>

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

------=_Part_100_1497444628.1536784521132--

------=_Part_99_2001173680.1536784521132--

.

------=_Part_97_190342853.1536787455183
Content-Type: multipart/alternative;
 boundary="----=_Part_98_1407201957.1536787455184"

------=_Part_98_1407201957.1536787455184
Content-Type: text/plain; charset="UTF-8"



On Wednesday, September 12, 2018 at 10:35:21 PM UTC+2, Jason Rice wrote:
>
> I think the interesting part is trying to do this general enough so
>> that it can be done for any call. Doing it for just a hardcoded set of
>> operators as a special case like we have now is not buying us much.
>>
>
> You're right. The special class of parameter that is opt-in and does what
> you're suggesting is probably the way to go though. I'm definitely chewing
> on this.
>
> Perhaps it could look something like this:
>
> using foo(auto expr1, using auto expr2) {
>   // expr1 is evaluated and treated as an lvalue
>   // expr2 is pasted anywhere and not necessarily evaluated
> }
>
> I've though about it and isn't the using idea somewhat similar to the
metaclasses proposal but applied to expressions instead of type
declarations ?
Might be a long shot but why not leveraging reflection instead yet new *RULES
*?

using foo(auto expr, auto expr2) {... } //any use of expr or expr2 is
replace with unreflexpr of the argument

foo(something, somethingelse); // foo(reflexpr(something),
reflexpr(somethingelse));

//or just the following if the above is too much
using foo(auto expr, reflexpr expr2 /*implicit conversion*/) {...}

This would allow non typed expressions to be passed to delay the resolution
of the type.
For instance, overload set => lambda:

using overloadset(reflexpr fnid)
{
    return [/*?*/]<class... Args>(Args&&... args)
        noexcept(noexcept(unreflexpr(fnid)(std::forward<Args>(args)...)))
        -> decltype(auto) {
             return unreflexpr(fnid)(std::forward<Args>(args)...);
    };
}

void func();
void func(int);

aut ox = overloadset(func);








>
>
> On Wednesday, September 12, 2018 at 1:03:38 PM UTC-7, Miguel Ojeda wrote:
>>
>> Hi Jason,
>>
>> On Wed, Sep 12, 2018 at 8:05 PM, Jason Rice <ricej...@gmail.com> wrote:
>> > Perhaps we should consider adding provisions for those specific
>> operators
>> > (ie operator&& operator||) because that would be very useful. I can
>> only
>> > imagine they lose their short-circuiting properties when overloaded
>> because
>> > of the legacy of normal functions.
>>
>> I think the interesting part is trying to do this general enough so
>> that it can be done for any call. Doing it for just a hardcoded set of
>> operators as a special case like we have now is not buying us much.
>>
>> >
>> > All of the parameters to this "using" function are expressions, but in
>> cases
>> > where that would be a pitfall, we are substituting it with an lvalue to
>> the
>> > result of the expression. This is tentative, and some have suggested it
>> > behave more like a function and always treat the params as lvalues. For
>> me
>>
>> I see. That would kill many of the interesting use cases, sadly.
>>
>> > personally, the issue is tertiary to having something like a function
>> that
>> > doesn't produce a type. (constexpr params are high up there too though)
>> >
>> > As it stands now this feature guarantees the operands are evaluated
>> exactly
>> > once, but I will consider adding provisional items to address short
>> circuit
>> > evaluation for those specific operators. (somehow)
>>
>> You mean in the case you always substitute them by an lvalue?
>> Otherwise, if they are expressions, I would say they might not be
>> evaluated at all in some cases, and in other cases more than once ---
>> which is what is interesting about this kind of proposals and what
>> makes them a usable, safer replacement to macros.
>>
>> Thanks for your work on this proposal!
>>
>> Cheers,
>> Miguel
>>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/aeb79646-ba53-49af-8777-8655a6655ede%40isocpp.org.

------=_Part_98_1407201957.1536787455184
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, September 12, 2018 at 10:35:21 PM UT=
C+2, Jason Rice 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"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think the inte=
resting part is trying to do this general enough so
<br>that it can be done for any call. Doing it for just a hardcoded set of
<br>operators as a special case like we have now is not buying us much.
<br></blockquote><div><br>You&#39;re right. The special class of parameter =
that is opt-in and does what you&#39;re suggesting is probably the way to g=
o though. I&#39;m definitely chewing on this.<br><br>Perhaps it could look =
something like this:<br><br><div style=3D"background-color:rgb(250,250,250)=
;border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><=
div><span style=3D"color:#008">using</span><span style=3D"color:#000"> foo<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#008">auto</s=
pan><span style=3D"color:#000"> expr1</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">using</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">auto</span=
><span style=3D"color:#000"> expr2</span><span style=3D"color:#660">)</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><spa=
n style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">// expr=
1 is evaluated and treated as an lvalue</span><span style=3D"color:#000"><b=
r>=C2=A0 </span><span style=3D"color:#800">// expr2 is pasted anywhere and =
not necessarily evaluated</span><span style=3D"color:#000"><br></span><span=
 style=3D"color:#660">}</span></div></code></div><br></div></div></blockquo=
te><div>I&#39;ve though about it and isn&#39;t the using idea somewhat simi=
lar to the metaclasses proposal but applied to expressions instead of type =
declarations ?</div><div>Might be a long shot but why not leveraging reflec=
tion instead yet new <b><i>RULES </i></b>?<br></div><div><br></div><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
 break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">auto</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"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 expr2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><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"> </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: #800;" class=3D"=
styled-by-prettify">//any use of expr or expr2 is replace with unreflexpr o=
f the argument</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br><br>foo</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">some=
thing</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> somethingelse=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify">// foo(reflexpr(something),=
 reflexpr(somethingelse));</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br><br></span><span style=3D"color: #800;" class=3D"styled=
-by-prettify">//or just the following if the above is too much</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><font color=3D"#666600"><=
span style=3D"color: #000;" class=3D"styled-by-prettify">foo</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">auto</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=
"styled-by-prettify"> reflexpr expr2 </span><span style=3D"color: #800;" cl=
ass=3D"styled-by-prettify">/*implicit conversion*/</span><span style=3D"col=
or: #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">{...}</span></font></div></code></div><div><br></di=
v><div>This would allow non typed expressions to be passed to delay the res=
olution of the type.</div><div>For instance, overload set =3D&gt; lambda:</=
div><div><br></div><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">using</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> overloadset</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">refle=
xpr fnid</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 sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">return</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: #=
800;" class=3D"styled-by-prettify">/*?*/</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">]&lt;</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">class</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: #606;" class=3D"styled-by-pretti=
fy">Args</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Args</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;...=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> args</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>=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 noexcept</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">noe=
xcept</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">unreflexpr</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">fnid</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)(</span><span style=3D"colo=
r: #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-prettify">forward</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Args</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">args</span><span style=3D"color: #660;" class=3D"styled-by-prettify">).=
...)))</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">decltype</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</s=
pan><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">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
unreflexpr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">fnid</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)(</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"colo=
r: #000;" class=3D"styled-by-prettify">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"s=
tyled-by-prettify">args</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)...);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> func</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span sty=
le=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"> func</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br>aut ox </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> overloadset</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
func</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span></div>=
</code></div><div><br></div><div><br></div><div><br></div><div><br></div><d=
iv><br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><br><br></div>On Wednesday, September =
12, 2018 at 1:03:38 PM UTC-7, Miguel Ojeda wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Hi Jason,
<br>
<br>On Wed, Sep 12, 2018 at 8:05 PM, Jason Rice &lt;<a rel=3D"nofollow">ric=
ej...@gmail.com</a>&gt; wrote:
<br>&gt; Perhaps we should consider adding provisions for those specific op=
erators
<br>&gt; (ie operator&amp;&amp; operator||) because that would be very usef=
ul. I can only
<br>&gt; imagine they lose their short-circuiting properties when overloade=
d because
<br>&gt; of the legacy of normal functions.
<br>
<br>I think the interesting part is trying to do this general enough so
<br>that it can be done for any call. Doing it for just a hardcoded set of
<br>operators as a special case like we have now is not buying us much.
<br>
<br>&gt;
<br>&gt; All of the parameters to this &quot;using&quot; function are expre=
ssions, but in cases
<br>&gt; where that would be a pitfall, we are substituting it with an lval=
ue to the
<br>&gt; result of the expression. This is tentative, and some have suggest=
ed it
<br>&gt; behave more like a function and always treat the params as lvalues=
.. For me
<br>
<br>I see. That would kill many of the interesting use cases, sadly.
<br>
<br>&gt; personally, the issue is tertiary to having something like a funct=
ion that
<br>&gt; doesn&#39;t produce a type. (constexpr params are high up there to=
o though)
<br>&gt;
<br>&gt; As it stands now this feature guarantees the operands are evaluate=
d exactly
<br>&gt; once, but I will consider adding provisional items to address shor=
t circuit
<br>&gt; evaluation for those specific operators. (somehow)
<br>
<br>You mean in the case you always substitute them by an lvalue?
<br>Otherwise, if they are expressions, I would say they might not be
<br>evaluated at all in some cases, and in other cases more than once ---
<br>which is what is interesting about this kind of proposals and what
<br>makes them a usable, safer replacement to macros.
<br>
<br>Thanks for your work on this proposal!
<br>
<br>Cheers,
<br>Miguel
<br></blockquote></div></blockquote></div>

<p></p>

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

------=_Part_98_1407201957.1536787455184--

------=_Part_97_190342853.1536787455183--

.

------=_Part_131_1322882337.1536789094769
Content-Type: multipart/alternative;
 boundary="----=_Part_132_147032883.1536789094770"

------=_Part_132_147032883.1536789094770
Content-Type: text/plain; charset="UTF-8"

My limited understanding of `reflexpr` and `unreflexpr` is that they yield
types which doesn't fit what this feature is trying to accomplish. (unless
I am misunderstanding something)

On Wednesday, September 12, 2018 at 2:24:15 PM UTC-7, bastie...@gmail.com
wrote:
>
>
>
> On Wednesday, September 12, 2018 at 10:35:21 PM UTC+2, Jason Rice wrote:
>>
>> I think the interesting part is trying to do this general enough so
>>> that it can be done for any call. Doing it for just a hardcoded set of
>>> operators as a special case like we have now is not buying us much.
>>>
>>
>> You're right. The special class of parameter that is opt-in and does what
>> you're suggesting is probably the way to go though. I'm definitely chewing
>> on this.
>>
>> Perhaps it could look something like this:
>>
>> using foo(auto expr1, using auto expr2) {
>>   // expr1 is evaluated and treated as an lvalue
>>   // expr2 is pasted anywhere and not necessarily evaluated
>> }
>>
>> I've though about it and isn't the using idea somewhat similar to the
> metaclasses proposal but applied to expressions instead of type
> declarations ?
> Might be a long shot but why not leveraging reflection instead yet new *RULES
> *?
>
> using foo(auto expr, auto expr2) {... } //any use of expr or expr2 is
> replace with unreflexpr of the argument
>
> foo(something, somethingelse); // foo(reflexpr(something),
> reflexpr(somethingelse));
>
> //or just the following if the above is too much
> using foo(auto expr, reflexpr expr2 /*implicit conversion*/) {...}
>
> This would allow non typed expressions to be passed to delay the
> resolution of the type.
> For instance, overload set => lambda:
>
> using overloadset(reflexpr fnid)
> {
>     return [/*?*/]<class... Args>(Args&&... args)
>         noexcept(noexcept(unreflexpr(fnid)(std::forward<Args>(args)...)))
>         -> decltype(auto) {
>              return unreflexpr(fnid)(std::forward<Args>(args)...);
>     };
> }
>
> void func();
> void func(int);
>
> aut ox = overloadset(func);
>
>
>
>
>
>
>
>
>>
>>
>> On Wednesday, September 12, 2018 at 1:03:38 PM UTC-7, Miguel Ojeda wrote:
>>>
>>> Hi Jason,
>>>
>>> On Wed, Sep 12, 2018 at 8:05 PM, Jason Rice <ricej...@gmail.com> wrote:
>>> > Perhaps we should consider adding provisions for those specific
>>> operators
>>> > (ie operator&& operator||) because that would be very useful. I can
>>> only
>>> > imagine they lose their short-circuiting properties when overloaded
>>> because
>>> > of the legacy of normal functions.
>>>
>>> I think the interesting part is trying to do this general enough so
>>> that it can be done for any call. Doing it for just a hardcoded set of
>>> operators as a special case like we have now is not buying us much.
>>>
>>> >
>>> > All of the parameters to this "using" function are expressions, but in
>>> cases
>>> > where that would be a pitfall, we are substituting it with an lvalue
>>> to the
>>> > result of the expression. This is tentative, and some have suggested
>>> it
>>> > behave more like a function and always treat the params as lvalues.
>>> For me
>>>
>>> I see. That would kill many of the interesting use cases, sadly.
>>>
>>> > personally, the issue is tertiary to having something like a function
>>> that
>>> > doesn't produce a type. (constexpr params are high up there too
>>> though)
>>> >
>>> > As it stands now this feature guarantees the operands are evaluated
>>> exactly
>>> > once, but I will consider adding provisional items to address short
>>> circuit
>>> > evaluation for those specific operators. (somehow)
>>>
>>> You mean in the case you always substitute them by an lvalue?
>>> Otherwise, if they are expressions, I would say they might not be
>>> evaluated at all in some cases, and in other cases more than once ---
>>> which is what is interesting about this kind of proposals and what
>>> makes them a usable, safer replacement to macros.
>>>
>>> Thanks for your work on this proposal!
>>>
>>> Cheers,
>>> Miguel
>>>
>>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2847af1-df7d-433b-9d98-9df6706e6bc5%40isocpp.org.

------=_Part_132_147032883.1536789094770
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My limited understanding of `reflexpr` and `unreflexpr` is=
 that they yield types which doesn&#39;t fit what this feature is trying to=
 accomplish. (unless I am misunderstanding something)<br><br>On Wednesday, =
September 12, 2018 at 2:24:15 PM UTC-7, bastie...@gmail.com wrote:<blockquo=
te 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><br>On Wednesday, =
September 12, 2018 at 10:35:21 PM UTC+2, Jason Rice 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"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">I think the interesting part is trying to do this general en=
ough so
<br>that it can be done for any call. Doing it for just a hardcoded set of
<br>operators as a special case like we have now is not buying us much.
<br></blockquote><div><br>You&#39;re right. The special class of parameter =
that is opt-in and does what you&#39;re suggesting is probably the way to g=
o though. I&#39;m definitely chewing on this.<br><br>Perhaps it could look =
something like this:<br><br><div style=3D"background-color:rgb(250,250,250)=
;border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><=
div><span style=3D"color:#008">using</span><span style=3D"color:#000"> foo<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#008">auto</s=
pan><span style=3D"color:#000"> expr1</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">using</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">auto</span=
><span style=3D"color:#000"> expr2</span><span style=3D"color:#660">)</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><spa=
n style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#800">// expr=
1 is evaluated and treated as an lvalue</span><span style=3D"color:#000"><b=
r>=C2=A0 </span><span style=3D"color:#800">// expr2 is pasted anywhere and =
not necessarily evaluated</span><span style=3D"color:#000"><br></span><span=
 style=3D"color:#660">}</span></div></code></div><br></div></div></blockquo=
te><div>I&#39;ve though about it and isn&#39;t the using idea somewhat simi=
lar to the metaclasses proposal but applied to expressions instead of type =
declarations ?</div><div>Might be a long shot but why not leveraging reflec=
tion instead yet new <b><i>RULES </i></b>?<br></div><div><br></div><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#008">using</span><span style=3D"color:#000"> foo</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> expr</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> expr2</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{...</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">}</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#800">//any use of expr or expr2 is=
 replace with unreflexpr of the argument</span><span style=3D"color:#000"><=
br><br>foo</span><span style=3D"color:#660">(</span><span style=3D"color:#0=
00">something</span><span style=3D"color:#660">,</span><span style=3D"color=
:#000"> somethingelse</span><span style=3D"color:#660">);</span><span style=
=3D"color:#000"> </span><span style=3D"color:#800">// foo(reflexpr(somethin=
g), reflexpr(somethingelse));</span><span style=3D"color:#000"><br><br></sp=
an><span style=3D"color:#800">//or just the following if the above is too m=
uch</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">=
using</span><span style=3D"color:#000"> </span><font color=3D"#666600"><spa=
n style=3D"color:#000">foo</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#008">auto</span><span style=3D"color:#000"> expr</span><span=
 style=3D"color:#660">,</span><span style=3D"color:#000"> reflexpr expr2 </=
span><span style=3D"color:#800">/*implicit conversion*/</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">{...}</span></font></div></code></div><div><br></div><div>This w=
ould allow non typed expressions to be passed to delay the resolution of th=
e type.</div><div>For instance, overload set =3D&gt; lambda:</div><div><br>=
</div><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><d=
iv><span style=3D"color:#008">using</span><span style=3D"color:#000"> overl=
oadset</span><span style=3D"color:#660">(</span><span style=3D"color:#000">=
reflexpr fnid</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>=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#660">[</span><span styl=
e=3D"color:#800">/*?*/</span><span style=3D"color:#660">]&lt;</span><span s=
tyle=3D"color:#008">class</span><span style=3D"color:#660">...</span><span =
style=3D"color:#000"> </span><span style=3D"color:#606">Args</span><span st=
yle=3D"color:#660">&gt;(</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><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 noexcept</span><span style=3D"color:#660">(</span>=
<span style=3D"color:#000">noexcept</span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#000">unreflexpr</span><span style=3D"color:#660">(<=
/span><span style=3D"color:#000">f<wbr>nid</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:#606">Args</span><span style=3D"color:#660=
">&gt;(</span><span style=3D"color:#000">args</span><span style=3D"color:#6=
60">).<wbr>..)))</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color:#660">-&gt;</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">decltype</span><span style=3D"color=
:#660">(</span><span style=3D"color:#008">auto</span><span style=3D"color:#=
660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0</span><span style=3D"color:#008">return</span><span style=3D"=
color:#000"> unreflexpr</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#000">fnid</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 s=
tyle=3D"color:#606"><wbr>Args</span><span style=3D"color:#660">&gt;(</span>=
<span style=3D"color:#000">args</span><span style=3D"color:#660">)...);</sp=
an><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </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><br></span><span style=3D"colo=
r:#008">void</span><span style=3D"color:#000"> func</span><span style=3D"co=
lor:#660">();</span><span style=3D"color:#000"><br></span><span style=3D"co=
lor:#008">void</span><span style=3D"color:#000"> func</span><span style=3D"=
color:#660">(</span><span style=3D"color:#008">int</span><span style=3D"col=
or:#660">);</span><span style=3D"color:#000"><br><br>aut ox </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> overloadset</span>=
<span style=3D"color:#660">(</span><span style=3D"color:#000">func</span><s=
pan style=3D"color:#660">);</span><span style=3D"color:#000"> </span></div>=
</code></div><div><br></div><div><br></div><div><br></div><div><br></div><d=
iv><br></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><br><br></div>On Wednesday, September 12, 2=
018 at 1:03:38 PM UTC-7, Miguel Ojeda wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">Hi Jason,
<br>
<br>On Wed, Sep 12, 2018 at 8:05 PM, Jason Rice &lt;<a rel=3D"nofollow">ric=
ej...@gmail.com</a>&gt; wrote:
<br>&gt; Perhaps we should consider adding provisions for those specific op=
erators
<br>&gt; (ie operator&amp;&amp; operator||) because that would be very usef=
ul. I can only
<br>&gt; imagine they lose their short-circuiting properties when overloade=
d because
<br>&gt; of the legacy of normal functions.
<br>
<br>I think the interesting part is trying to do this general enough so
<br>that it can be done for any call. Doing it for just a hardcoded set of
<br>operators as a special case like we have now is not buying us much.
<br>
<br>&gt;
<br>&gt; All of the parameters to this &quot;using&quot; function are expre=
ssions, but in cases
<br>&gt; where that would be a pitfall, we are substituting it with an lval=
ue to the
<br>&gt; result of the expression. This is tentative, and some have suggest=
ed it
<br>&gt; behave more like a function and always treat the params as lvalues=
.. For me
<br>
<br>I see. That would kill many of the interesting use cases, sadly.
<br>
<br>&gt; personally, the issue is tertiary to having something like a funct=
ion that
<br>&gt; doesn&#39;t produce a type. (constexpr params are high up there to=
o though)
<br>&gt;
<br>&gt; As it stands now this feature guarantees the operands are evaluate=
d exactly
<br>&gt; once, but I will consider adding provisional items to address shor=
t circuit
<br>&gt; evaluation for those specific operators. (somehow)
<br>
<br>You mean in the case you always substitute them by an lvalue?
<br>Otherwise, if they are expressions, I would say they might not be
<br>evaluated at all in some cases, and in other cases more than once ---
<br>which is what is interesting about this kind of proposals and what
<br>makes them a usable, safer replacement to macros.
<br>
<br>Thanks for your work on this proposal!
<br>
<br>Cheers,
<br>Miguel
<br></blockquote></div></blockquote></div></blockquote></div>

<p></p>

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

------=_Part_132_147032883.1536789094770--

------=_Part_131_1322882337.1536789094769--

.

On Wed, Sep 12, 2018 at 10:35 PM, Jason Rice <ricejasonf@gmail.com> wrote:
>> I think the interesting part is trying to do this general enough so
>> that it can be done for any call. Doing it for just a hardcoded set of
>> operators as a special case like we have now is not buying us much.
>
>
> You're right. The special class of parameter that is opt-in and does what
> you're suggesting is probably the way to go though. I'm definitely chewing
> on this.
>
> Perhaps it could look something like this:
>
> using foo(auto expr1, using auto expr2) {
>   // expr1 is evaluated and treated as an lvalue
>   // expr2 is pasted anywhere and not necessarily evaluated
> }

Actually that syntax does not look bad at all! If expr1 is always
"evaluated" (like in function calls) and expr2 is always "pasted",
then possibly the second auto should be skipped (since an expression
might be of any type). It would even make the relation "using keyword"
<=> "expressions" (i.e. both introducing a parametric expression and
the expression-parameters).

By the way, this is also related to the Statements in Expressions GNU
C extension (https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs).

Another example of this syntax: the common setdefault() for Python
dicts, but we get it with laziness included:

    using setdefault(auto key, using default_value) {
        auto it = find(key);
        if (it != end())
            return *it;
        return *insert(key, default_value);
    }

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

.

------=_Part_1037_793374212.1536950350348
Content-Type: multipart/alternative;
 boundary="----=_Part_1038_779713260.1536950350349"

------=_Part_1038_779713260.1536950350349
Content-Type: text/plain; charset="UTF-8"


>
> By the way, this is also related to the Statements in Expressions GNU
> C extension (
> https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs
> <https://www.google.com/url?q=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&sa=D&sntz=1&usg=AFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg>).
>
>

Yes, I was advised not to mention these, but I think it may be unavoidable.

I'm going to include the "macro-parameters" and just simplify the rules for
normal ones to be treated as lvalues. I'm also going to eliminate the
return-statement as it needlessly redefines what a return-statement is. (It
was also high impact in the implementation)

On Thursday, September 13, 2018 at 6:08:52 PM UTC-7, Miguel Ojeda wrote:
>
> On Wed, Sep 12, 2018 at 10:35 PM, Jason Rice <ricej...@gmail.com
> <javascript:>> wrote:
> >> I think the interesting part is trying to do this general enough so
> >> that it can be done for any call. Doing it for just a hardcoded set of
> >> operators as a special case like we have now is not buying us much.
> >
> >
> > You're right. The special class of parameter that is opt-in and does
> what
> > you're suggesting is probably the way to go though. I'm definitely
> chewing
> > on this.
> >
> > Perhaps it could look something like this:
> >
> > using foo(auto expr1, using auto expr2) {
> >   // expr1 is evaluated and treated as an lvalue
> >   // expr2 is pasted anywhere and not necessarily evaluated
> > }
>
> Actually that syntax does not look bad at all! If expr1 is always
> "evaluated" (like in function calls) and expr2 is always "pasted",
> then possibly the second auto should be skipped (since an expression
> might be of any type). It would even make the relation "using keyword"
> <=> "expressions" (i.e. both introducing a parametric expression and
> the expression-parameters).
>
> By the way, this is also related to the Statements in Expressions GNU
> C extension (
> https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs
> <https://www.google.com/url?q=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&sa=D&sntz=1&usg=AFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg>).
>
>
> Another example of this syntax: the common setdefault() for Python
> dicts, but we get it with laziness included:
>
>     using setdefault(auto key, using default_value) {
>         auto it = find(key);
>         if (it != end())
>             return *it;
>         return *insert(key, default_value);
>     }
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7980e9a-1d9d-4843-88dd-6908c3a445b9%40isocpp.org.

------=_Part_1038_779713260.1536950350349
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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;">=
By the way, this is also related to the Statements in Expressions GNU
<br>C extension (<a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgc=
c.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&amp;s=
a=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg" target=3D"=
_blank" rel=3D"nofollow">https://gcc.gnu.org/<wbr>onlinedocs/gcc/Statement-=
<wbr>Exprs.html#Statement-Exprs</a>).
<br></blockquote><br>Yes, I was advised not to mention these, but I think i=
t may be unavoidable.<br><br>I&#39;m going to include the &quot;macro-param=
eters&quot; and just simplify the rules for normal ones to be treated as lv=
alues. I&#39;m also going to eliminate the return-statement as it needlessl=
y redefines what a return-statement is. (It was also high impact in the imp=
lementation)<br><br>On Thursday, September 13, 2018 at 6:08:52 PM UTC-7, Mi=
guel Ojeda wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Sep 1=
2, 2018 at 10:35 PM, Jason Rice &lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"zp7mNuh_BwAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">ricej...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; I think the interesting part is trying to do this general enou=
gh so
<br>&gt;&gt; that it can be done for any call. Doing it for just a hardcode=
d set of
<br>&gt;&gt; operators as a special case like we have now is not buying us =
much.
<br>&gt;
<br>&gt;
<br>&gt; You&#39;re right. The special class of parameter that is opt-in an=
d does what
<br>&gt; you&#39;re suggesting is probably the way to go though. I&#39;m de=
finitely chewing
<br>&gt; on this.
<br>&gt;
<br>&gt; Perhaps it could look something like this:
<br>&gt;
<br>&gt; using foo(auto expr1, using auto expr2) {
<br>&gt; =C2=A0 // expr1 is evaluated and treated as an lvalue
<br>&gt; =C2=A0 // expr2 is pasted anywhere and not necessarily evaluated
<br>&gt; }
<br>
<br>Actually that syntax does not look bad at all! If expr1 is always
<br>&quot;evaluated&quot; (like in function calls) and expr2 is always &quo=
t;pasted&quot;,
<br>then possibly the second auto should be skipped (since an expression
<br>might be of any type). It would even make the relation &quot;using keyw=
ord&quot;
<br>&lt;=3D&gt; &quot;expressions&quot; (i.e. both introducing a parametric=
 expression and
<br>the expression-parameters).
<br>
<br>By the way, this is also related to the Statements in Expressions GNU
<br>C extension (<a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgc=
c.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&amp;s=
a=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Expr=
s.html%23Statement-Exprs\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFbAbvivdBh=
BrF8GCjuHKHsPZFazg&#39;;return true;" onclick=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FState=
ment-Exprs.html%23Statement-Exprs\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
bAbvivdBhBrF8GCjuHKHsPZFazg&#39;;return true;">https://gcc.gnu.org/<wbr>onl=
inedocs/gcc/Statement-<wbr>Exprs.html#Statement-Exprs</a>).
<br>
<br>Another example of this syntax: the common setdefault() for Python
<br>dicts, but we get it with laziness included:
<br>
<br>=C2=A0 =C2=A0 using setdefault(auto key, using default_value) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto it =3D find(key);
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (it !=3D end())
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return *it;
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return *insert(key, default_value);
<br>=C2=A0 =C2=A0 }
<br></blockquote></div>

<p></p>

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

------=_Part_1038_779713260.1536950350349--

------=_Part_1037_793374212.1536950350348--

.

--0000000000008dff2f0577dcef26
Content-Type: text/plain; charset="UTF-8"

Hi Jason,

Can we expect a paper at some point? The anticipation is killing me :)

G

On Fri, Sep 14, 2018 at 7:39 PM Jason Rice <ricejasonf@gmail.com> wrote:

> By the way, this is also related to the Statements in Expressions GNU
>> C extension (
>> https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs
>> <https://www.google.com/url?q=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&sa=D&sntz=1&usg=AFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg>).
>>
>>
>
> Yes, I was advised not to mention these, but I think it may be unavoidable.
>
> I'm going to include the "macro-parameters" and just simplify the rules
> for normal ones to be treated as lvalues. I'm also going to eliminate the
> return-statement as it needlessly redefines what a return-statement is. (It
> was also high impact in the implementation)
>
> On Thursday, September 13, 2018 at 6:08:52 PM UTC-7, Miguel Ojeda wrote:
>>
>> On Wed, Sep 12, 2018 at 10:35 PM, Jason Rice <ricej...@gmail.com> wrote:
>> >> I think the interesting part is trying to do this general enough so
>> >> that it can be done for any call. Doing it for just a hardcoded set of
>> >> operators as a special case like we have now is not buying us much.
>> >
>> >
>> > You're right. The special class of parameter that is opt-in and does
>> what
>> > you're suggesting is probably the way to go though. I'm definitely
>> chewing
>> > on this.
>> >
>> > Perhaps it could look something like this:
>> >
>> > using foo(auto expr1, using auto expr2) {
>> >   // expr1 is evaluated and treated as an lvalue
>> >   // expr2 is pasted anywhere and not necessarily evaluated
>> > }
>>
>> Actually that syntax does not look bad at all! If expr1 is always
>> "evaluated" (like in function calls) and expr2 is always "pasted",
>> then possibly the second auto should be skipped (since an expression
>> might be of any type). It would even make the relation "using keyword"
>> <=> "expressions" (i.e. both introducing a parametric expression and
>> the expression-parameters).
>>
>> By the way, this is also related to the Statements in Expressions GNU
>> C extension (
>> https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs
>> <https://www.google.com/url?q=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&sa=D&sntz=1&usg=AFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg>).
>>
>>
>> Another example of this syntax: the common setdefault() for Python
>> dicts, but we get it with laziness included:
>>
>>     using setdefault(auto key, using default_value) {
>>         auto it = find(key);
>>         if (it != end())
>>             return *it;
>>         return *insert(key, default_value);
>>     }
>>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7980e9a-1d9d-4843-88dd-6908c3a445b9%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7980e9a-1d9d-4843-88dd-6908c3a445b9%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkXTS3RBP2CwN5X-r0UtFTXi9Mm0%2BXgF6v8QCASOFXxW7A%40mail.gmail.com.

--0000000000008dff2f0577dcef26
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Jason,<div><br></div><div>Can we expect a paper at some=
 point? The anticipation is killing me :)</div><div><br></div><div>G</div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Sep 14, 2018 a=
t 7:39 PM Jason Rice &lt;<a href=3D"mailto:ricejasonf@gmail.com">ricejasonf=
@gmail.com</a>&gt; wrote:<br></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"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">By the way, this=
 is also related to the Statements in Expressions GNU
<br>C extension (<a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgc=
c.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&amp;s=
a=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg" rel=3D"nof=
ollow" target=3D"_blank">https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs=
..html#Statement-Exprs</a>).
<br></blockquote><br>Yes, I was advised not to mention these, but I think i=
t may be unavoidable.<br><br>I&#39;m going to include the &quot;macro-param=
eters&quot; and just simplify the rules for normal ones to be treated as lv=
alues. I&#39;m also going to eliminate the return-statement as it needlessl=
y redefines what a return-statement is. (It was also high impact in the imp=
lementation)<br><br>On Thursday, September 13, 2018 at 6:08:52 PM UTC-7, Mi=
guel Ojeda wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Sep 12, 20=
18 at 10:35 PM, Jason Rice &lt;<a rel=3D"nofollow">ricej...@gmail.com</a>&g=
t; wrote:
<br>&gt;&gt; I think the interesting part is trying to do this general enou=
gh so
<br>&gt;&gt; that it can be done for any call. Doing it for just a hardcode=
d set of
<br>&gt;&gt; operators as a special case like we have now is not buying us =
much.
<br>&gt;
<br>&gt;
<br>&gt; You&#39;re right. The special class of parameter that is opt-in an=
d does what
<br>&gt; you&#39;re suggesting is probably the way to go though. I&#39;m de=
finitely chewing
<br>&gt; on this.
<br>&gt;
<br>&gt; Perhaps it could look something like this:
<br>&gt;
<br>&gt; using foo(auto expr1, using auto expr2) {
<br>&gt; =C2=A0 // expr1 is evaluated and treated as an lvalue
<br>&gt; =C2=A0 // expr2 is pasted anywhere and not necessarily evaluated
<br>&gt; }
<br>
<br>Actually that syntax does not look bad at all! If expr1 is always
<br>&quot;evaluated&quot; (like in function calls) and expr2 is always &quo=
t;pasted&quot;,
<br>then possibly the second auto should be skipped (since an expression
<br>might be of any type). It would even make the relation &quot;using keyw=
ord&quot;
<br>&lt;=3D&gt; &quot;expressions&quot; (i.e. both introducing a parametric=
 expression and
<br>the expression-parameters).
<br>
<br>By the way, this is also related to the Statements in Expressions GNU
<br>C extension (<a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgc=
c.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&amp;s=
a=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg" rel=3D"nof=
ollow" target=3D"_blank">https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs=
..html#Statement-Exprs</a>).
<br>
<br>Another example of this syntax: the common setdefault() for Python
<br>dicts, but we get it with laziness included:
<br>
<br>=C2=A0 =C2=A0 using setdefault(auto key, using default_value) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto it =3D find(key);
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (it !=3D end())
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return *it;
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return *insert(key, default_value);
<br>=C2=A0 =C2=A0 }
<br></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c7980e9a-1d9d-4843-88dd-6908c3a445b9%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7980e9a-1d9d-=
4843-88dd-6908c3a445b9%40isocpp.org</a>.<br>
</blockquote></div>

<p></p>

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

--0000000000008dff2f0577dcef26--

.

------=_Part_2720_2107485532.1539185569230
Content-Type: multipart/alternative;
 boundary="----=_Part_2721_672376210.1539185569231"

------=_Part_2721_672376210.1539185569231
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I submitted one for the San Diego mailing.

https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb

On Wednesday, October 10, 2018 at 3:01:25 AM UTC-7, Ga=C5=A1per A=C5=BEman =
wrote:
>
> Hi Jason,
>
> Can we expect a paper at some point? The anticipation is killing me :)
>
> G
>
> On Fri, Sep 14, 2018 at 7:39 PM Jason Rice <ricej...@gmail.com=20
> <javascript:>> wrote:
>
>> By the way, this is also related to the Statements in Expressions GNU=20
>>> C extension (
>>> https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs=
=20
>>> <https://www.google.com/url?q=3Dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%=
2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&sa=3DD&sntz=3D1&usg=3DAFQjCN=
FbAbvivdBhBrF8GCjuHKHsPZFazg>).=20
>>>
>>>
>>
>> Yes, I was advised not to mention these, but I think it may be=20
>> unavoidable.
>>
>> I'm going to include the "macro-parameters" and just simplify the rules=
=20
>> for normal ones to be treated as lvalues. I'm also going to eliminate th=
e=20
>> return-statement as it needlessly redefines what a return-statement is. =
(It=20
>> was also high impact in the implementation)
>>
>> On Thursday, September 13, 2018 at 6:08:52 PM UTC-7, Miguel Ojeda wrote:
>>>
>>> On Wed, Sep 12, 2018 at 10:35 PM, Jason Rice <ricej...@gmail.com>=20
>>> wrote:=20
>>> >> I think the interesting part is trying to do this general enough so=
=20
>>> >> that it can be done for any call. Doing it for just a hardcoded set=
=20
>>> of=20
>>> >> operators as a special case like we have now is not buying us much.=
=20
>>> >=20
>>> >=20
>>> > You're right. The special class of parameter that is opt-in and does=
=20
>>> what=20
>>> > you're suggesting is probably the way to go though. I'm definitely=20
>>> chewing=20
>>> > on this.=20
>>> >=20
>>> > Perhaps it could look something like this:=20
>>> >=20
>>> > using foo(auto expr1, using auto expr2) {=20
>>> >   // expr1 is evaluated and treated as an lvalue=20
>>> >   // expr2 is pasted anywhere and not necessarily evaluated=20
>>> > }=20
>>>
>>> Actually that syntax does not look bad at all! If expr1 is always=20
>>> "evaluated" (like in function calls) and expr2 is always "pasted",=20
>>> then possibly the second auto should be skipped (since an expression=20
>>> might be of any type). It would even make the relation "using keyword"=
=20
>>> <=3D> "expressions" (i.e. both introducing a parametric expression and=
=20
>>> the expression-parameters).=20
>>>
>>> By the way, this is also related to the Statements in Expressions GNU=
=20
>>> C extension (
>>> https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs=
=20
>>> <https://www.google.com/url?q=3Dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%=
2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&sa=3DD&sntz=3D1&usg=3DAFQjCN=
FbAbvivdBhBrF8GCjuHKHsPZFazg>).=20
>>>
>>>
>>> Another example of this syntax: the common setdefault() for Python=20
>>> dicts, but we get it with laziness included:=20
>>>
>>>     using setdefault(auto key, using default_value) {=20
>>>         auto it =3D find(key);=20
>>>         if (it !=3D end())=20
>>>             return *it;=20
>>>         return *insert(key, default_value);=20
>>>     }=20
>>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7980e9a-1d=
9d-4843-88dd-6908c3a445b9%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7980e9a-1=
d9d-4843-88dd-6908c3a445b9%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>

--=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/ee221a61-2afe-4d88-8b39-6c44614f2846%40isocpp.or=
g.

------=_Part_2721_672376210.1539185569231
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I submitted one for the San Diego mailing.<br><br><a href=
=3D"https://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb">ht=
tps://gist.github.com/ricejasonf/84c11ac6bb093c1ea8c380a9a466d8cb</a><br><b=
r>On Wednesday, October 10, 2018 at 3:01:25 AM UTC-7, Ga=C5=A1per A=C5=BEma=
n 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">Hi Ja=
son,<div><br></div><div>Can we expect a paper at some point? The anticipati=
on is killing me :)</div><div><br></div><div>G</div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr">On Fri, Sep 14, 2018 at 7:39 PM Jason Rice &=
lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"h7f5T=
S_DAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;=
return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">ri=
cej...@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v 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">By the way,=
 this is also related to the Statements in Expressions GNU
<br>C extension (<a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgc=
c.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&amp;s=
a=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg" rel=3D"nof=
ollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Expr=
s.html%23Statement-Exprs\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFbAbvivdBh=
BrF8GCjuHKHsPZFazg&#39;;return true;" onclick=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FState=
ment-Exprs.html%23Statement-Exprs\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
bAbvivdBhBrF8GCjuHKHsPZFazg&#39;;return true;">https://gcc.gnu.org/<wbr>onl=
inedocs/gcc/Statement-<wbr>Exprs.html#Statement-Exprs</a>).
<br></blockquote><br>Yes, I was advised not to mention these, but I think i=
t may be unavoidable.<br><br>I&#39;m going to include the &quot;macro-param=
eters&quot; and just simplify the rules for normal ones to be treated as lv=
alues. I&#39;m also going to eliminate the return-statement as it needlessl=
y redefines what a return-statement is. (It was also high impact in the imp=
lementation)<br><br>On Thursday, September 13, 2018 at 6:08:52 PM UTC-7, Mi=
guel Ojeda wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Sep 12, 20=
18 at 10:35 PM, Jason Rice &lt;<a rel=3D"nofollow">ricej...@gmail.com</a>&g=
t; wrote:
<br>&gt;&gt; I think the interesting part is trying to do this general enou=
gh so
<br>&gt;&gt; that it can be done for any call. Doing it for just a hardcode=
d set of
<br>&gt;&gt; operators as a special case like we have now is not buying us =
much.
<br>&gt;
<br>&gt;
<br>&gt; You&#39;re right. The special class of parameter that is opt-in an=
d does what
<br>&gt; you&#39;re suggesting is probably the way to go though. I&#39;m de=
finitely chewing
<br>&gt; on this.
<br>&gt;
<br>&gt; Perhaps it could look something like this:
<br>&gt;
<br>&gt; using foo(auto expr1, using auto expr2) {
<br>&gt; =C2=A0 // expr1 is evaluated and treated as an lvalue
<br>&gt; =C2=A0 // expr2 is pasted anywhere and not necessarily evaluated
<br>&gt; }
<br>
<br>Actually that syntax does not look bad at all! If expr1 is always
<br>&quot;evaluated&quot; (like in function calls) and expr2 is always &quo=
t;pasted&quot;,
<br>then possibly the second auto should be skipped (since an expression
<br>might be of any type). It would even make the relation &quot;using keyw=
ord&quot;
<br>&lt;=3D&gt; &quot;expressions&quot; (i.e. both introducing a parametric=
 expression and
<br>the expression-parameters).
<br>
<br>By the way, this is also related to the Statements in Expressions GNU
<br>C extension (<a href=3D"https://www.google.com/url?q=3Dhttps%3A%2F%2Fgc=
c.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Exprs.html%23Statement-Exprs&amp;s=
a=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNFbAbvivdBhBrF8GCjuHKHsPZFazg" rel=3D"nof=
ollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google=
..com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FStatement-Expr=
s.html%23Statement-Exprs\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFbAbvivdBh=
BrF8GCjuHKHsPZFazg&#39;;return true;" onclick=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FState=
ment-Exprs.html%23Statement-Exprs\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
bAbvivdBhBrF8GCjuHKHsPZFazg&#39;;return true;">https://gcc.gnu.org/<wbr>onl=
inedocs/gcc/Statement-<wbr>Exprs.html#Statement-Exprs</a>).
<br>
<br>Another example of this syntax: the common setdefault() for Python
<br>dicts, but we get it with laziness included:
<br>
<br>=C2=A0 =C2=A0 using setdefault(auto key, using default_value) {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto it =3D find(key);
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (it !=3D end())
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return *it;
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return *insert(key, default_value);
<br>=C2=A0 =C2=A0 }
<br></blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
h7f5TS_DAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"h7f5TS_DAgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c7980e9a-1d9d-4843-88dd-6908c3a445b9%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/c7980e9a-1d9d-4843-88dd-6908c3a445b9%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/c7980e9a-1d9d-4843-88dd-6908c3a445b9%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c7980e9a-1d9d-4843-<wbr>88dd-=
6908c3a445b9%40isocpp.org</a><wbr>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

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

------=_Part_2721_672376210.1539185569231--

------=_Part_2720_2107485532.1539185569230--

.