------=_Part_6992_627655005.1429178319705
Content-Type: multipart/alternative;
 boundary="----=_Part_6993_557994971.1429178319705"

------=_Part_6993_557994971.1429178319705
Content-Type: text/plain; charset=UTF-8

Hi All,
I think that the "implementability" section of the paper on reduced static
if proposal is too pessimistic. I tried to implement the two examples from
"Motivation" section in C++14 with generic lambdas using the technique
indicated by Paul Fultz II here:
http://www.reddit.com/r/cpp/comments/295e77/clever_overloading_andrzejs_c_blog/

You can see the result here:
http://melpon.org/wandbox/permlink/ub4qmpDyIzkZWP1x

While the syntax is obviously more ugly than what the paper describes, I
believe the result is achievable in C++14 already. The compiler would only
need to mechanically transform one notation into another.

Regards,
&rzej

--

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

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

<div dir=3D"ltr">Hi All,<br>I think that the "implementability" section of =
the paper on reduced static if proposal is too pessimistic. I tried to impl=
ement the two examples from "Motivation" section in C++14 with generic lamb=
das using the technique indicated by Paul Fultz II here: http://www.reddit.=
com/r/cpp/comments/295e77/clever_overloading_andrzejs_c_blog/<br><br>You ca=
n see the result here: http://melpon.org/wandbox/permlink/ub4qmpDyIzkZWP1x<=
br><br>While the syntax is obviously more ugly than what the paper describe=
s, I believe the result is achievable in C++14 already. The compiler would =
only need to mechanically transform one notation into another.<br><br>Regar=
ds,<br>&amp;rzej<br></div>

<p></p>

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

------=_Part_6993_557994971.1429178319705--
------=_Part_6992_627655005.1429178319705--

.

On Thu, Apr 16, 2015 at 4:58 AM, Andrzej Krzemie=C5=84ski <akrzemi1@gmail.c=
om> wrote:
> Hi All,
> I think that the "implementability" section of the paper on reduced stati=
c
> if proposal is too pessimistic.

I think I would agree with you - but I never know until i start
implementing these things (unlike certain clang Gallifreyans - *cough*
Richard *cough* - who see all implementation-potentialities at once).

I believe the implementation in clang could be fairly straightforward
- in very broad buggy strokes consider:
  - create a new AST Node that inherits from Stmt that stores the
condition stmt, and the two AST branches
  - if the AST node is not being parsed within a template (i.e. not in
a dependent context, and the condition's truth value can be determined
then), then consider lexing but not parsing the false branch??, else
within a dependent context, parse both arms as we would any
compound-stmt within a template definition
  - when instantiating a function template body, evaluate then the
static-if's condition, and then decide which branch to instantiate -
and then in the instantiated body replace the entire static-if node,
with the transformed compound statement...

Am I missing something obvious (or not so obvious)?

OK back to trying to get that pesky constexpr lambda proposal done in
time prior to lenexa - ( FYI - Geneva can be very distracting ... ;)

-faisal

> I tried to implement the two examples from
> "Motivation" section in C++14 with generic lambdas using the technique
> indicated by Paul Fultz II here:
> http://www.reddit.com/r/cpp/comments/295e77/clever_overloading_andrzejs_c=
_blog/
>
> You can see the result here:
> http://melpon.org/wandbox/permlink/ub4qmpDyIzkZWP1x
>
> While the syntax is obviously more ugly than what the paper describes, I
> believe the result is achievable in C++14 already. The compiler would onl=
y
> need to mechanically transform one notation into another.
>
> Regards,
> &rzej
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--=20

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

.