Topic: constexpr all_of etc.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 2 Sep 2014 17:59:00 +0800
Raw View
--Apple-Mail=_B49D70C3-0282-42A6-94AB-A595632DFE67
Content-Type: text/plain; charset=ISO-8859-1
The initializer_list overloads of std::min and std::max are constexpr. Why not add similar overloads to std::all_of, any_of, and none_of?
The use that comes to mind is pack inequality.
template< typename ... pack_a, typename ... pack_b >
std::enable_if_t< ! std::all_of({ std::is_same_v< pack_a, pack_b > ... }) >
Although, come to think of it, this can be done with tuples.
std::enable_if_t< ! std::is_same_v< std::tuple< pack_a ... >, std::tuple< pack_b ... > > >
I'd still prefer the <algorithm> solution.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_B49D70C3-0282-42A6-94AB-A595632DFE67
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">The <font face=3D"Cour=
ier">initializer_list</font> overloads of <font face=3D"Courier">std::min</=
font> and <font face=3D"Courier">std::max</font> are <font face=3D"Courier"=
>constexpr</font>. Why not add similar overloads to <font face=3D"Courier">=
std::all_of</font>, <font face=3D"Courier">any_of</font>, and <font face=3D=
"Courier">none_of</font>?<div><br></div><div>The use that comes to mind is =
pack inequality.<br><div><br></div><div><font face=3D"Courier">template<=
typename ... pack_a, typename ... pack_b ></font></div><div><font face=
=3D"Courier">std::enable_if_t< ! std::all_of({ std::is_same_v< pack_a=
, pack_b > ... }) ></font></div><div><br></div></div><div>Although, c=
ome to think of it, this can be done with tuples.</div><div><br></div><div>=
<font face=3D"Courier">std::enable_if_t< ! std::is_same_v< std::tuple=
< pack_a ... >, std::tuple< pack_b ... > > ></font></div>=
<div><br></div><div>I’d still prefer the <font face=3D"Courier"><a=
lgorithm></font> solution.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_B49D70C3-0282-42A6-94AB-A595632DFE67--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 2 Sep 2014 18:14:40 +0300
Raw View
On 2 September 2014 12:59, David Krauss <potswa@gmail.com> wrote:
> The initializer_list overloads of std::min and std::max are constexpr. Wh=
y
> not add similar overloads to std::all_of, any_of, and none_of?
Sounds like a decent idea. Any particular reason why we wouldn't make
the existing overloads constexpr?
> The use that comes to mind is pack inequality.
>
> template< typename ... pack_a, typename ... pack_b >
> std::enable_if_t< ! std::all_of({ std::is_same_v< pack_a, pack_b > ... })=
>
>
> Although, come to think of it, this can be done with tuples.
>
> std::enable_if_t< ! std::is_same_v< std::tuple< pack_a ... >, std::tuple<
> pack_b ... > > >
>
> I=E2=80=99d still prefer the <algorithm> solution.
Sure, the tuple solution works for this particular case, but I suppose
the algorithm
solution has more potential uses.
--=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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 02 Sep 2014 19:50:14 +0300
Raw View
------64LEZNY3DAKNOV4XFXNA9C9DE4NT2Z
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
The tuple solution works because you are using std::tuple as a boost::mpl::=
vector substitute and implementing catamorphisms over packs through "tuple =
processing" naming them differently from what they substantially are.
Are you certain that making constexpr overloads of such algorithms like all=
_of etc is better than addressing the real issue, meaning the lack of first=
class support for the fundamentals allowing such constructs? Shouldn't the=
se things be considered eventually by expanding <type_traits> to boost::mpl=
territory?
Seems more like another popular substitute by hasty inspiration than a solu=
tion by design.
On September 2, 2014 6:14:40 PM EEST, Ville Voutilainen <ville.voutilainen@=
gmail.com> wrote:
>On 2 September 2014 12:59, David Krauss <potswa@gmail.com> wrote:
>> The initializer_list overloads of std::min and std::max are
>constexpr. Why
>> not add similar overloads to std::all_of, any_of, and none_of?
>
>Sounds like a decent idea. Any particular reason why we wouldn't make
>the existing overloads constexpr?
>
>> The use that comes to mind is pack inequality.
>>
>> template< typename ... pack_a, typename ... pack_b >
>> std::enable_if_t< ! std::all_of({ std::is_same_v< pack_a, pack_b >
>... }) >
>>
>> Although, come to think of it, this can be done with tuples.
>>
>> std::enable_if_t< ! std::is_same_v< std::tuple< pack_a ... >,
>std::tuple<
>> pack_b ... > > >
>>
>> I=E2=80=99d still prefer the <algorithm> solution.
>
>
>Sure, the tuple solution works for this particular case, but I suppose
>the algorithm
>solution has more potential uses.
>
>--=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 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/.
------64LEZNY3DAKNOV4XFXNA9C9DE4NT2Z
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">The tuple solution works because yo=
u are using std::tuple as a boost::mpl::vector substitute and implementing =
catamorphisms over packs through "tuple processing" naming them differently=
from what they substantially are.</p>
<p dir=3D"ltr">Are you certain that making constexpr overloads of such algo=
rithms like all_of etc is better than addressing the real issue, meaning th=
e lack of first class support for the fundamentals allowing such constructs=
? Shouldn't these things be considered eventually by expanding <type_tra=
its> to boost::mpl territory?</p>
<p dir=3D"ltr">Seems more like another popular substitute by hasty inspirat=
ion than a solution by design.</p>
<br><br><div class=3D"gmail_quote">On September 2, 2014 6:14:40 PM EEST, Vi=
lle Voutilainen <ville.voutilainen@gmail.com> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 2 September 2014 12:59, David Krauss <potswa@gm=
ail.com> wrote:<br /><blockquote class=3D"gmail_quote" style=3D"margin: =
0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> The=
initializer_list overloads of std::min and std::max are constexpr. Why<br =
/> not add similar overloads to std::all_of, any_of, and none_of?<br /></bl=
ockquote><br />Sounds like a decent idea. Any particular reason why we woul=
dn't make<br />the existing overloads constexpr?<br /><br /><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px sol=
id #729fcf; padding-left: 1ex;"> The use that comes to mind is pack inequal=
ity.<br /><br /> template< typename ... pack_a, typename ... pack_b >=
<br /> std::enable_if_t< ! std::all_of({ std::is_same_v< pack_a, pack=
_b > ... }) ><br /><br /> Although, come to think of it, this can be =
done with tuples.<br /><br /> std::enable_if_t< ! std::is_same_v< std=
::tuple< pack_a ... >,
std::tuple<<br /> pack_b ... > > ><br /><br /> I=E2=80=99d stil=
l prefer the <algorithm> solution.<br /></blockquote><br /><br />Sure=
, the tuple solution works for this particular case, but I suppose<br />the=
algorithm<br />solution has more potential uses.<br /></pre></blockquote><=
/div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
------64LEZNY3DAKNOV4XFXNA9C9DE4NT2Z--
.
Author: rhalbersma@gmail.com
Date: Tue, 2 Sep 2014 10:35:07 -0700 (PDT)
Raw View
------=_Part_404_1528695638.1409679307062
Content-Type: text/plain; charset=UTF-8
On Tuesday, September 2, 2014 5:14:41 PM UTC+2, Ville Voutilainen wrote:
>
> On 2 September 2014 12:59, David Krauss <pot...@gmail.com <javascript:>>
> wrote:
> > The initializer_list overloads of std::min and std::max are constexpr.
> Why
> > not add similar overloads to std::all_of, any_of, and none_of?
>
> Sounds like a decent idea. Any particular reason why we wouldn't make
> the existing overloads constexpr?
>
Funny enough, the relaxed constexpr paper N3597 has std::bitset::any() as a
motivating example, so it would fit right into that philosophy.
And since std::move is also constexpr as of C++14, why not make std::swap
constexpr as well?
And why not lambdas and all of std::array, std::bitset, std::tuple,
std::complex as well?
Or ultimately: full compile-time function evaluation as is possible in D
(anything not involving I/O, so including virtuals and dynamic allocation).
--
---
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_404_1528695638.1409679307062
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, September 2, 2014 5:14:41 PM UTC+2, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2 September 2=
014 12:59, David Krauss <<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"cv33Lr3qEbEJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">pot...@gma=
il.com</a>> wrote:
<br>> The initializer_list overloads of std::min and std::max are conste=
xpr. Why
<br>> not add similar overloads to std::all_of, any_of, and none_of?
<br>
<br>Sounds like a decent idea. Any particular reason why we wouldn't make
<br>the existing overloads constexpr?
<br></blockquote><div><br></div><div>Funny enough, the relaxed constexpr pa=
per N3597 has std::bitset::any() as a motivating example, so it would fit r=
ight into that philosophy.</div><div><br></div><div>And since std::move is =
also constexpr as of C++14, why not make std::swap constexpr as well?  =
;</div><div><br></div><div>And why not lambdas and all of std::array, std::=
bitset, std::tuple, std::complex as well? </div><div><br></div><div>Or=
ultimately: full compile-time function evaluation as is possible in D (any=
thing not involving I/O, so including virtuals and dynamic allocation).</di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_404_1528695638.1409679307062--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 2 Sep 2014 20:42:03 +0300
Raw View
On 2 September 2014 20:35, <rhalbersma@gmail.com> wrote:
> And since std::move is also constexpr as of C++14, why not make std::swap
> constexpr as well?
>
> And why not lambdas and all of std::array, std::bitset, std::tuple,
> std::complex as well?
Chances are that most of things in that set of examples are good candidates for
additional constexpr.
> Or ultimately: full compile-time function evaluation as is possible in D
> (anything not involving I/O, so including virtuals and dynamic allocation).
It's, however, likely that at some point there's going to be
increasing resistance
towards imposing such compile-time evaluation of everything on every
implementation.
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 02 Sep 2014 20:47:31 +0300
Raw View
------YJ0JK865U0ATHG6ICF93OQATV038TP
Content-Type: text/plain; charset=UTF-8
On September 2, 2014 8:35:07 PM EEST, rhalbersma@gmail.com wrote:
>And why not lambdas and all of std::array, std::bitset, std::tuple,
>std::complex as well?
>
>Or ultimately: full compile-time function evaluation as is possible in
>D
>(anything not involving I/O, so including virtuals and dynamic
>allocation).
A simple explanation to this is political pride over technical substance. You will get many non-reasons supporting this stance. It is more convenient to proceed this way because hasty inspirations are more popular for expert beginners.
--
---
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/.
------YJ0JK865U0ATHG6ICF93OQATV038TP
Content-Type: text/html; charset=UTF-8
<p dir="ltr"></p>
<p dir="ltr">On September 2, 2014 8:35:07 PM EEST, rhalbersma@gmail.com wrote:</p>
<p dir="ltr">>And why not lambdas and all of std::array, std::bitset, std::tuple, <br>
>std::complex as well? <br>
><br>
>Or ultimately: full compile-time function evaluation as is possible in<br>
>D <br>
>(anything not involving I/O, so including virtuals and dynamic<br>
>allocation).</p>
<p dir="ltr">A simple explanation to this is political pride over technical substance. You will get many non-reasons supporting this stance. It is more convenient to proceed this way because hasty inspirations are more popular for expert beginners.</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------YJ0JK865U0ATHG6ICF93OQATV038TP--
.
Author: Rein Halbersma <rhalbersma@gmail.com>
Date: Tue, 2 Sep 2014 19:50:17 +0200
Raw View
--001a1132f75ea01ede050218c020
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 2, 2014 at 7:42 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 2 September 2014 20:35, <rhalbersma@gmail.com> wrote:
> > And since std::move is also constexpr as of C++14, why not make std::swap
> > constexpr as well?
> >
> > And why not lambdas and all of std::array, std::bitset, std::tuple,
> > std::complex as well?
>
> Chances are that most of things in that set of examples are good
> candidates for
> additional constexpr.
Great! Are there efforts underway that you know of?
> > Or ultimately: full compile-time function evaluation as is possible in D
> > (anything not involving I/O, so including virtuals and dynamic
> allocation).
>
>
> It's, however, likely that at some point there's going to be
> increasing resistance
> towards imposing such compile-time evaluation of everything on every
> implementation.
Just a naive and honest question: what are the main technical obstacles for
compile-time evaluation of all non-I/O expressions? (and prefereably
without the constexpr keyword, implicit would do nicely) Works for D, so it
seems it can be done, but maybe D's compilation model is too different from
C++'s?
--
---
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/.
--001a1132f75ea01ede050218c020
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 2, 2014 at 7:42 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 2 September 2014 20:35,=
=C2=A0 <<a href=3D"mailto:rhalbersma@gmail.com">rhalbersma@gmail.com</a>=
> wrote:<br>
> And since std::move is also constexpr as of C++14, why not make std::s=
wap<br>
> constexpr as well?<br>
><br>
> And why not lambdas and all of std::array, std::bitset, std::tuple,<br=
>
> std::complex as well?<br>
<br>
</div>Chances are that most of things in that set of examples are good cand=
idates for<br>
additional constexpr.</blockquote><div><br></div><div>Great! Are there effo=
rts underway that you know of?</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div class=3D"">
> Or ultimately: full compile-time function evaluation as is possible in=
D<br>
> (anything not involving I/O, so including virtuals and dynamic allocat=
ion).<br>
<br>
<br>
</div>It's, however, likely that at some point there's going to be<=
br>
increasing resistance<br>
towards imposing such compile-time evaluation of everything on every<br>
implementation.</blockquote><div><br></div><div>Just a naive and honest que=
stion: what are the main technical obstacles for compile-time evaluation of=
all non-I/O expressions? (and prefereably without the constexpr keyword, i=
mplicit would do nicely) Works for D, so it seems it can be done, but maybe=
D's compilation model is too different from C++'s?</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a1132f75ea01ede050218c020--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 02 Sep 2014 20:55:34 +0300
Raw View
Compile time evaluation implies implementation of constructs that have been naively considered as "abominations" for the language. See work done by Alexandrescu on static if. Some of it could get resurrected by Ville. Still not enough.
On September 2, 2014 8:50:17 PM EEST, Rein Halbersma <rhalbersma@gmail.com> wrote:
>On Tue, Sep 2, 2014 at 7:42 PM, Ville Voutilainen <
>ville.voutilainen@gmail.com> wrote:
>
>> On 2 September 2014 20:35, <rhalbersma@gmail.com> wrote:
>> > And since std::move is also constexpr as of C++14, why not make
>std::swap
>> > constexpr as well?
>> >
>> > And why not lambdas and all of std::array, std::bitset, std::tuple,
>> > std::complex as well?
>>
>> Chances are that most of things in that set of examples are good
>> candidates for
>> additional constexpr.
>
>
>Great! Are there efforts underway that you know of?
>
>
>> > Or ultimately: full compile-time function evaluation as is possible
>in D
>> > (anything not involving I/O, so including virtuals and dynamic
>> allocation).
>>
>>
>> It's, however, likely that at some point there's going to be
>> increasing resistance
>> towards imposing such compile-time evaluation of everything on every
>> implementation.
>
>
>Just a naive and honest question: what are the main technical obstacles
>for
>compile-time evaluation of all non-I/O expressions? (and prefereably
>without the constexpr keyword, implicit would do nicely) Works for D,
>so it
>seems it can be done, but maybe D's compilation model is too different
>from
>C++'s?
--
---
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/.
.
Author: Rein Halbersma <rhalbersma@gmail.com>
Date: Tue, 2 Sep 2014 20:18:12 +0200
Raw View
--14dae93d94d8711d8205021924ab
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 2, 2014 at 7:55 PM, George Makrydakis <irrequietus@gmail.com>
wrote:
> Compile time evaluation implies implementation of constructs that have
> been naively considered as "abominations" for the language. See work done
> by Alexandrescu on static if. Some of it could get resurrected by Ville.
> Still not enough.
With abomination you mean of course "posing obstacles to Concepts".
I don't see how interference with the Concepts holy grail (that basically
torpedoed static_if) is an issue with full compile-time function
evaluation. The restriction on constexpr lambdas is especially frustrating,
as it can be worked around with using a handwritten struct with constexpr
constructor and operator(). The same Concepts interference card was played
against allowing polymorphic lambdas (which also could be worked around
with using templated operator()), until that was shown to be resolvable.
--
---
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/.
--14dae93d94d8711d8205021924ab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 2, 2014 at 7:55 PM, George Makrydakis <span dir=3D"ltr"><<a href=
=3D"mailto:irrequietus@gmail.com" target=3D"_blank">irrequietus@gmail.com</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Compile time evaluation implies implementation of construc=
ts that have been naively considered as "abominations" for the la=
nguage. See work done by Alexandrescu on static if. Some of it could get re=
surrected by Ville. Still not enough.</blockquote>
<div><br></div><div style=3D"font-family:arial,sans-serif;font-size:13px">W=
ith abomination you mean of course "posing obstacles to Concepts"=
..</div><div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div=
>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px">I don'=
t see how interference with the Concepts holy grail (that basically torpedo=
ed static_if) is an issue with full compile-time function evaluation. The r=
estriction on constexpr lambdas is especially frustrating, as it can be wor=
ked around with using a handwritten struct with constexpr constructor and o=
perator(). The same Concepts interference card was played against allowing =
polymorphic lambdas (which also could be worked around with using templated=
operator()), until that was shown to be resolvable.</span>=C2=A0</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--14dae93d94d8711d8205021924ab--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 2 Sep 2014 21:26:54 +0300
Raw View
--001a113954889449b70502194348
Content-Type: text/plain; charset=UTF-8
You essentially caught the gist of it. Concepts are nothing more than
glorified shorthands over sfinae hacks. Their political justification is
the overwhelming non-reason for not going through with full blown compile
time evaluation in a friendly way. Their actual intent would have been met
if they behaved more like typeclasses instead of sfinae shorthands.
In another thread, Sutton says that he would consider concepts a failed
experiment if they required any kind of template metaprogramming in order
to work. Problem is that template metaprogramming is the quintessential
tool for compile time evaluation and properly done, annihilates concepts
the way they are right now. The more you advance constexpr metaprogramming
to become as wide as template one, the less need you have for concepts.
That is one big issue for constexpr.
On Sep 2, 2014 9:18 PM, "Rein Halbersma" <rhalbersma@gmail.com> wrote:
> On Tue, Sep 2, 2014 at 7:55 PM, George Makrydakis <irrequietus@gmail.com>
> wrote:
>
>> Compile time evaluation implies implementation of constructs that have
>> been naively considered as "abominations" for the language. See work done
>> by Alexandrescu on static if. Some of it could get resurrected by Ville.
>> Still not enough.
>
>
> With abomination you mean of course "posing obstacles to Concepts".
>
> I don't see how interference with the Concepts holy grail (that basically
> torpedoed static_if) is an issue with full compile-time function
> evaluation. The restriction on constexpr lambdas is especially frustrating,
> as it can be worked around with using a handwritten struct with constexpr
> constructor and operator(). The same Concepts interference card was played
> against allowing polymorphic lambdas (which also could be worked around
> with using templated operator()), until that was shown to be resolvable.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113954889449b70502194348
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">You essentially caught the gist of it. Concepts are nothing =
more than glorified shorthands over sfinae hacks. Their political justifica=
tion is the overwhelming non-reason for not going through with full blown c=
ompile time evaluation in a friendly way. Their actual intent would have be=
en met if they behaved more like typeclasses instead of sfinae shorthands.<=
/p>
<p dir=3D"ltr">In another thread, Sutton says that he would consider concep=
ts a failed experiment if they required any kind of template metaprogrammin=
g in order to work. Problem is that template metaprogramming is the quintes=
sential tool for compile time evaluation and properly done, annihilates con=
cepts the way they are right now. The more you advance constexpr metaprogra=
mming to become as wide as template one, the less need you have for concept=
s. That is one big issue for constexpr.<br>
</p>
<div class=3D"gmail_quote">On Sep 2, 2014 9:18 PM, "Rein Halbersma&quo=
t; <<a href=3D"mailto:rhalbersma@gmail.com">rhalbersma@gmail.com</a>>=
wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 2, 2014 at 7:55 PM, George Makrydakis <span dir=3D"ltr"><<a href=
=3D"mailto:irrequietus@gmail.com" target=3D"_blank">irrequietus@gmail.com</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Compile time evaluation implies implementation of construc=
ts that have been naively considered as "abominations" for the la=
nguage. See work done by Alexandrescu on static if. Some of it could get re=
surrected by Ville. Still not enough.</blockquote>
<div><br></div><div style=3D"font-family:arial,sans-serif;font-size:13px">W=
ith abomination you mean of course "posing obstacles to Concepts"=
..</div><div style=3D"font-family:arial,sans-serif;font-size:13px"><br></div=
>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px">I don'=
t see how interference with the Concepts holy grail (that basically torpedo=
ed static_if) is an issue with full compile-time function evaluation. The r=
estriction on constexpr lambdas is especially frustrating, as it can be wor=
ked around with using a handwritten struct with constexpr constructor and o=
perator(). The same Concepts interference card was played against allowing =
polymorphic lambdas (which also could be worked around with using templated=
operator()), until that was shown to be resolvable.</span>=C2=A0</div>
</div></div></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a113954889449b70502194348--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 2 Sep 2014 21:27:07 +0300
Raw View
On 2 September 2014 21:18, Rein Halbersma <rhalbersma@gmail.com> wrote:
> I don't see how interference with the Concepts holy grail (that basically
> torpedoed static_if) is an issue with full compile-time function evaluation.
It seems there are enough other reasons besides Concepts that
torpedoed static_if.
--
---
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/.
.
Author: rhalbersma@gmail.com
Date: Tue, 2 Sep 2014 11:28:44 -0700 (PDT)
Raw View
------=_Part_2759_1517108735.1409682524657
Content-Type: text/plain; charset=UTF-8
On Tuesday, September 2, 2014 8:27:09 PM UTC+2, Ville Voutilainen wrote:
>
> On 2 September 2014 21:18, Rein Halbersma <rhalb...@gmail.com
> <javascript:>> wrote:
> > I don't see how interference with the Concepts holy grail (that
> basically
> > torpedoed static_if) is an issue with full compile-time function
> evaluation.
>
>
> It seems there are enough other reasons besides Concepts that
> torpedoed static_if.
>
Which is why I asked: "what are the main technical obstacles for
compile-time evaluation of all non-I/O expressions?"
--
---
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_2759_1517108735.1409682524657
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, September 2, 2014 8:27:09 PM UTC+2, Vi=
lle Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2 Sep=
tember 2014 21:18, Rein Halbersma <<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"214XOx1xTfQJ" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">=
rhalb...@gmail.com</a>> wrote:
<br>> I don't see how interference with the Concepts holy grail (that ba=
sically
<br>> torpedoed static_if) is an issue with full compile-time function e=
valuation.
<br>
<br>
<br>It seems there are enough other reasons besides Concepts that
<br>torpedoed static_if.
<br></blockquote><div><br></div><div>Which is why I asked: "<span style=3D"=
font-size: 13px;">what are the main technical obstacles for compile-time ev=
aluation of all non-I/O expressions?"</span><span style=3D"font-size: 13px;=
"> </span></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_2759_1517108735.1409682524657--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 02 Sep 2014 21:29:49 +0300
Raw View
------9O1T52XNZKHASREWHA9HRE720VUJ25
Content-Type: text/plain; charset=UTF-8
The issue is not static if alone. The committee does not have a real argument against compile time evaluation. Just politics.
On September 2, 2014 9:27:07 PM EEST, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>On 2 September 2014 21:18, Rein Halbersma <rhalbersma@gmail.com> wrote:
>> I don't see how interference with the Concepts holy grail (that
>basically
>> torpedoed static_if) is an issue with full compile-time function
>evaluation.
>
>
>It seems there are enough other reasons besides Concepts that
>torpedoed static_if.
>
>--
>
>---
>You received this message because you are subscribed to the Google
>Groups "ISO C++ Standard - Future Proposals" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to std-proposals+unsubscribe@isocpp.org.
>To post to this group, send email to std-proposals@isocpp.org.
>Visit this group at
>http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------9O1T52XNZKHASREWHA9HRE720VUJ25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">The issue is not static if alone. T=
he committee does not have a real argument against compile time evaluation.=
Just politics.</p>
<br><br><div class=3D"gmail_quote">On September 2, 2014 9:27:07 PM EEST, Vi=
lle Voutilainen <ville.voutilainen@gmail.com> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid=
rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 2 September 2014 21:18, Rein Halbersma <rhalber=
sma@gmail.com> wrote:<br /><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;=
"> I don't see how interference with the Concepts holy grail (that basicall=
y<br /> torpedoed static_if) is an issue with full compile-time function ev=
aluation.<br /></blockquote><br /><br />It seems there are enough other rea=
sons besides Concepts that<br />torpedoed static_if.<br /></pre></blockquot=
e></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
------9O1T52XNZKHASREWHA9HRE720VUJ25--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 2 Sep 2014 22:15:29 +0300
Raw View
On 2 September 2014 21:29, George Makrydakis <irrequietus@gmail.com> wrote:
> The issue is not static if alone. The committee does not have a real
> argument against compile time evaluation. Just politics.
Well, as I see it, the argument is very real, and it's not politics in
the very sense
of the word, but concern about implementation complexity which in turn leads to
portability concerns when different implementations are able to ship
more complex
constexpr support(*) with vastly different schedules. If that's
politics to you, that's fine by me,
but that argument is _very_ real.
(*) Feel free to count the number of implementations that support
C++14 constexpr.
The result of that count is one. The expectation is that there should
eventually be half
a dozen more.
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 02 Sep 2014 22:15:43 +0300
Raw View
I seriously doubt we are ever going to get a convincing argument against ha=
ving such levels of compile time evaluation. People who are adamantly oppos=
ing it argue that it would be too hard for non-expert users (nonsense), tha=
t their compilers would be strained (nonsense) or they just admit their ter=
ror even in their own proposals (nonsense++). People using libraries like b=
oost::mpl show that there is a wide area of coverage for such kinds of eval=
uation.
Mostly it is about waiting to gather everything into a bizzaro universe whe=
re they can be shown to be correct in their approach and pontificate a "sol=
ution" that supports their views. Or that they become proficient enough to =
understand the benefits of Turing completeness within the compiler. But why=
aren't they just accepting that such evaluation should be a priority?
Politics used to justify technical decisions are inexplicable to all but ex=
pert beginners. The continuous relaxation of constexpr requirements is slow=
ly leading C++ towards compile time evaluation semantics (albeit very, very=
incompletely). I don't think anymore that most of these people actually kn=
ow what they are doing, especially when they have only politics supporting =
them.
On September 2, 2014 9:28:44 PM EEST, rhalbersma@gmail.com wrote:
>
>
>On Tuesday, September 2, 2014 8:27:09 PM UTC+2, Ville Voutilainen
>wrote:
>>
>> On 2 September 2014 21:18, Rein Halbersma <rhalb...@gmail.com=20
>> <javascript:>> wrote:=20
>> > I don't see how interference with the Concepts holy grail (that=20
>> basically=20
>> > torpedoed static_if) is an issue with full compile-time function=20
>> evaluation.=20
>>
>>
>> It seems there are enough other reasons besides Concepts that=20
>> torpedoed static_if.=20
>>
>
>Which is why I asked: "what are the main technical obstacles for=20
>compile-time evaluation of all non-I/O expressions?"=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Rein Halbersma <rhalbersma@gmail.com>
Date: Tue, 2 Sep 2014 21:38:44 +0200
Raw View
--047d7b3a84be7cea6c05021a4448
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 2, 2014 at 9:15 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
> (*) Feel free to count the number of implementations that support
> C++14 constexpr.
> The result of that count is one. The expectation is that there should
> eventually be half
> a dozen more.
And what is holding the non-Clang compilers back exactly? IIRC, Clang moved
from C++11-style to C++14-style constexpr in the matter of a few months
last year. It's sad that the slowest adaptors determine the pace of
progress. Surely the committee is not in the business of protecting half a
dozen feet-dragging compilers from competitive pressures?
It would be interesting to see what would happen if someone hacked Clang to
introduce full D-style CTFE *as an extension, *(or TS or whatever the
politically accepted phrase is)
--
---
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/.
--047d7b3a84be7cea6c05021a4448
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 2, 2014 at 9:15 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D""><br></div>
(*) Feel free to count the number of implementations that support<br>
C++14 constexpr.<br>
The result of that count is one. The expectation is that there should<br>
eventually be half<br>
a dozen more.</blockquote><div><br></div><div>And what is holding the non-C=
lang compilers back exactly? IIRC, Clang moved from C++11-style to C++14-st=
yle constexpr in the matter of a few months last year. It's sad that th=
e slowest adaptors determine the pace of progress. Surely the committee is =
not in the business of protecting half a dozen feet-dragging compilers from=
competitive pressures?=C2=A0</div>
<div><br></div><div>It would be interesting to see what would happen if som=
eone hacked Clang to introduce full D-style CTFE <i>as an extension, </i>(o=
r TS or whatever the politically accepted phrase is)=C2=A0<br></div></div><=
/div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--047d7b3a84be7cea6c05021a4448--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 02 Sep 2014 22:40:41 +0300
Raw View
------UNE7QPS3CK6BGYDIDXFX61C77ZAJGF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
With all due respect, people incapable of fixing their compilers are either=
lazy or ignorant in their overwhelming majority. They have the burden of p=
roof of why they can't do it if there are no conflicts with what already is=
in a language. "I said so" does not count. I see people working in clang++=
being able to keep up with language feature implementations as fast as the=
se come about. I see experimental gcc branches working up their way with fe=
atures.
Just because some sponsoring companies may have problems putting together a=
decent compiler team does not mean that C++ has to remain in the dark ages=
, especially when it comes to compile time evaluation.
Though as you know, I have understanding respect for your position as secre=
tary, lack of *eventual* compiler support is not a valid reason for not sol=
ving a problem the right way. Your argument expresses that of certain peopl=
e, but I think you are misguided. By analogy, one should not make an omelet=
te because he would have to break some eggs. As such, the argument of compi=
ler complexity either safeguards incompetence or is used as a deflector shi=
eld for "external" contributions piggybacking on poetical correctness in or=
der to avoid liability of irresponsible decisions.
Properly solved problems, anticipate eventual compiler "inconsistencies" la=
ter on by forcing well defined semantics. I do not believe that such "diffi=
culty" arguments have any real merit in the realm of compile time evaluatio=
n.
It is all basically politics as I have said before.
On September 2, 2014 10:15:29 PM EEST, Ville Voutilainen <ville.voutilainen=
@gmail.com> wrote:
>On 2 September 2014 21:29, George Makrydakis <irrequietus@gmail.com>
>wrote:
>> The issue is not static if alone. The committee does not have a real
>> argument against compile time evaluation. Just politics.
>
>Well, as I see it, the argument is very real, and it's not politics in
>the very sense
>of the word, but concern about implementation complexity which in turn
>leads to
>portability concerns when different implementations are able to ship
>more complex
>constexpr support(*) with vastly different schedules. If that's
>politics to you, that's fine by me,
>but that argument is _very_ real.
>
>(*) Feel free to count the number of implementations that support
>C++14 constexpr.
>The result of that count is one. The expectation is that there should
>eventually be half
>a dozen more.
--=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/.
------UNE7QPS3CK6BGYDIDXFX61C77ZAJGF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">With all due respect, people incapa=
ble of fixing their compilers are either lazy or ignorant in their overwhel=
ming majority. They have the burden of proof of why they can't do it if the=
re are no conflicts with what already is in a language. "I said so" does no=
t count. I see people working in clang++ being able to keep up with languag=
e feature implementations as fast as these come about. I see experimental g=
cc branches working up their way with features.</p>
<p dir=3D"ltr">Just because some sponsoring companies may have problems put=
ting together a decent compiler team does not mean that C++ has to remain i=
n the dark ages, especially when it comes to compile time evaluation.</p>
<p dir=3D"ltr">Though as you know, I have understanding respect for your po=
sition as secretary, lack of *eventual* compiler support is not a valid rea=
son for not solving a problem the right way. Your argument expresses that o=
f certain people, but I think you are misguided. By analogy, one should not=
make an omelette because he would have to break some eggs. As such, the ar=
gument of compiler complexity either safeguards incompetence or is used as =
a deflector shield for "external" contributions piggybacking on poetical co=
rrectness in order to avoid liability of irresponsible decisions.</p>
<p dir=3D"ltr">Properly solved problems, anticipate eventual compiler "inco=
nsistencies" later on by forcing well defined semantics. I do not believe t=
hat such "difficulty" arguments have any real merit in the realm of compile=
time evaluation.</p>
<p dir=3D"ltr">It is all basically politics as I have said before.<br>
</p>
<br><br><div class=3D"gmail_quote">On September 2, 2014 10:15:29 PM EEST, V=
ille Voutilainen <ville.voutilainen@gmail.com> wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 2 September 2014 21:29, George Makrydakis <irre=
quietus@gmail.com> wrote:<br /><blockquote class=3D"gmail_quote" style=
=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left=
: 1ex;"> The issue is not static if alone. The committee does not have a re=
al<br /> argument against compile time evaluation. Just politics.<br /></bl=
ockquote><br />Well, as I see it, the argument is very real, and it's not p=
olitics in<br />the very sense<br />of the word, but concern about implemen=
tation complexity which in turn leads to<br />portability concerns when dif=
ferent implementations are able to ship<br />more complex<br />constexpr su=
pport(*) with vastly different schedules. If that's<br />politics to you, t=
hat's fine by me,<br />but that argument is _very_ real.<br /><br />(*) Fee=
l free to count the number of implementations that support<br />C++14 const=
expr.<br />The result of that count is one. The expectation is that there s=
hould<br />eventually be
half<br />a dozen more.<br /></pre></blockquote></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
------UNE7QPS3CK6BGYDIDXFX61C77ZAJGF--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 02 Sep 2014 22:59:20 +0300
Raw View
------VYL96PGBIX5IF0KUWDYIM5UB1DF92N
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Having a C++ language feature extension that is not in the standard is para=
gonable to a language fork, when it comes to compile time evaluation. If su=
ccessful, it could be repeated to the point of wondering why the committee =
subgroup responsible was against it, placing them in an awkward position. G=
iven that good interests are intertwined in such an old player in the indus=
try like C++, that is engineered to not happen. Cause and effect.
Respectfully, the committee members involved in crucial decisions like this=
have an immense burden of proof on their shoulders. I respect them for tha=
t, but I do not have to respect unprovable non-arguments even if they come =
out of critically acclaimed people. Even monkeys fall from trees.
You have no valid technical reason against compile time evaluation.
On September 2, 2014 10:38:44 PM EEST, Rein Halbersma <rhalbersma@gmail.com=
> wrote:
>On Tue, Sep 2, 2014 at 9:15 PM, Ville Voutilainen <
>ville.voutilainen@gmail.com> wrote:
>
>>
>> (*) Feel free to count the number of implementations that support
>> C++14 constexpr.
>> The result of that count is one. The expectation is that there should
>> eventually be half
>> a dozen more.
>
>
>And what is holding the non-Clang compilers back exactly? IIRC, Clang
>moved
>from C++11-style to C++14-style constexpr in the matter of a few months
>last year. It's sad that the slowest adaptors determine the pace of
>progress. Surely the committee is not in the business of protecting
>half a
>dozen feet-dragging compilers from competitive pressures?
>
>It would be interesting to see what would happen if someone hacked
>Clang to
>introduce full D-style CTFE *as an extension, *(or TS or whatever the
>politically accepted phrase is)
>
>--=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 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/.
------VYL96PGBIX5IF0KUWDYIM5UB1DF92N
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">Having a C++ language feature exten=
sion that is not in the standard is paragonable to a language fork, when it=
comes to compile time evaluation. If successful, it could be repeated to t=
he point of wondering why the committee subgroup responsible was against it=
, placing them in an awkward position. Given that good interests are intert=
wined in such an old player in the industry like C++, that is engineered to=
not happen. Cause and effect.</p>
<p dir=3D"ltr">Respectfully, the committee members involved in crucial deci=
sions like this have an immense burden of proof on their shoulders. I respe=
ct them for that, but I do not have to respect unprovable non-arguments eve=
n if they come out of critically acclaimed people. Even monkeys fall from t=
rees.</p>
<p dir=3D"ltr">You have no valid technical reason against compile time eval=
uation.<br>
</p>
<br><br><div class=3D"gmail_quote">On September 2, 2014 10:38:44 PM EEST, R=
ein Halbersma <rhalbersma@gmail.com> wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204,=
204, 204); padding-left: 1ex;">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 2, 2014 at 9:15 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br />
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D""><br /></div>
(*) Feel free to count the number of implementations that support<br />
C++14 constexpr.<br />
The result of that count is one. The expectation is that there should<br />
eventually be half<br />
a dozen more.</blockquote><div><br /></div><div>And what is holding the non=
-Clang compilers back exactly? IIRC, Clang moved from C++11-style to C++14-=
style constexpr in the matter of a few months last year. It's sad that =
the slowest adaptors determine the pace of progress. Surely the committee i=
s not in the business of protecting half a dozen feet-dragging compilers fr=
om competitive pressures?=C2=A0</div>
<div><br /></div><div>It would be interesting to see what would happen if s=
omeone hacked Clang to introduce full D-style CTFE <i>as an extension, </i>=
(or TS or whatever the politically accepted phrase is)=C2=A0<br /></div></d=
iv></div>
</div>
<p></p>
</blockquote></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
------VYL96PGBIX5IF0KUWDYIM5UB1DF92N--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 2 Sep 2014 22:59:49 +0300
Raw View
On 2 September 2014 22:38, Rein Halbersma <rhalbersma@gmail.com> wrote:
> And what is holding the non-Clang compilers back exactly? IIRC, Clang moved
Ask their implementers. As far as I understand, they have other priorities
and responsibilities in addition to maximum speed of implementing new features.
> from C++11-style to C++14-style constexpr in the matter of a few months last
> year. It's sad that the slowest adaptors determine the pace of progress.
I never said the slowest adaptors determine the pace of progress. But
if we don't
pay heed to cases where the majority of vendors are all in the camp of "slowest
adaptors", madness ensues. We shouldn't determine the pace of progress
any more by the fastest adaptors as we do by the slowest ones.
> Surely the committee is not in the business of protecting half a dozen
> feet-dragging compilers from competitive pressures?
A portion of the committee most certainly is. Other people may at times agree
with that portion due to other reasons. Fast progress without
portability is, for
example, more or less useless to me and my users.
> It would be interesting to see what would happen if someone hacked Clang to
> introduce full D-style CTFE as an extension, (or TS or whatever the
> politically accepted phrase is)
It certainly would be interesting, yes.
--
---
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/.
.
Author: Rein Halbersma <rhalbersma@gmail.com>
Date: Tue, 2 Sep 2014 22:03:08 +0200
Raw View
--001a11c34262bbf64405021a9bfa
Content-Type: text/plain; charset=UTF-8
OK, Ville, thanks for your insights! I didn't mean to imply that one should
hold you responsible for the current state of affairs :-)
On Tue, Sep 2, 2014 at 9:59 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 2 September 2014 22:38, Rein Halbersma <rhalbersma@gmail.com> wrote:
> > And what is holding the non-Clang compilers back exactly? IIRC, Clang
> moved
>
> Ask their implementers. As far as I understand, they have other priorities
> and responsibilities in addition to maximum speed of implementing new
> features.
>
> > from C++11-style to C++14-style constexpr in the matter of a few months
> last
> > year. It's sad that the slowest adaptors determine the pace of progress.
>
> I never said the slowest adaptors determine the pace of progress. But
> if we don't
> pay heed to cases where the majority of vendors are all in the camp of
> "slowest
> adaptors", madness ensues. We shouldn't determine the pace of progress
> any more by the fastest adaptors as we do by the slowest ones.
>
> > Surely the committee is not in the business of protecting half a dozen
> > feet-dragging compilers from competitive pressures?
>
> A portion of the committee most certainly is. Other people may at times
> agree
> with that portion due to other reasons. Fast progress without
> portability is, for
> example, more or less useless to me and my users.
>
> > It would be interesting to see what would happen if someone hacked Clang
> to
> > introduce full D-style CTFE as an extension, (or TS or whatever the
> > politically accepted phrase is)
>
> It certainly would be interesting, yes.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/qcKUf-U7_YU/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c34262bbf64405021a9bfa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">OK, Ville, thanks for your insights! I didn't mean to =
imply that one should hold you responsible for the current state of affairs=
:-)<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, S=
ep 2, 2014 at 9:59 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"m=
ailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmai=
l.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 2 September 2014 22:38, R=
ein Halbersma <<a href=3D"mailto:rhalbersma@gmail.com">rhalbersma@gmail.=
com</a>> wrote:<br>
> And what is holding the non-Clang compilers back exactly? IIRC, Clang =
moved<br>
<br>
</div>Ask their implementers. As far as I understand, they have other prior=
ities<br>
and responsibilities in addition to maximum speed of implementing new featu=
res.<br>
<div class=3D""><br>
> from C++11-style to C++14-style constexpr in the matter of a few month=
s last<br>
> year. It's sad that the slowest adaptors determine the pace of pro=
gress.<br>
<br>
</div>I never said the slowest adaptors determine the pace of progress. But=
<br>
if we don't<br>
pay heed to cases where the majority of vendors are all in the camp of &quo=
t;slowest<br>
adaptors", madness ensues. We shouldn't determine the pace of prog=
ress<br>
any more by the fastest adaptors as we do by the slowest ones.<br>
<div class=3D""><br>
> Surely the committee is not in the business of protecting half a dozen=
<br>
> feet-dragging compilers from competitive pressures?<br>
<br>
</div>A portion of the committee most certainly is. Other people may at tim=
es agree<br>
with that portion due to other reasons. Fast progress without<br>
portability is, for<br>
example, more or less useless to me and my users.<br>
<div class=3D""><br>
> It would be interesting to see what would happen if someone hacked Cla=
ng to<br>
> introduce full D-style CTFE as an extension, (or TS or whatever the<br=
>
> politically accepted phrase is)<br>
<br>
</div>It certainly would be interesting, yes.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/qcKUf-U7_YU/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/qcKUf-U7_YU=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a11c34262bbf64405021a9bfa--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 02 Sep 2014 23:09:03 +0300
Raw View
------W9QZGOFS833H4WP83LCPEKRQS2Z4T4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Implementers should do as fine a job as the committee does, since some of t=
hem are members of the committee. Their refuge behind unprovable complexity=
claims is unfounded on technical terms when it harms the language by forci=
ng programmers to go into complex library constructs that strain the compil=
ers more than language features would.
Again, no valid reason against compile time evaluation is given, especially=
since far too many people have uses for it to the point of implementing su=
ch behaviour through template meta-programming. Just like David did with st=
d::tuple for example on this thread.
On September 2, 2014 10:59:49 PM EEST, Ville Voutilainen <ville.voutilainen=
@gmail.com> wrote:
>On 2 September 2014 22:38, Rein Halbersma <rhalbersma@gmail.com> wrote:
>> And what is holding the non-Clang compilers back exactly? IIRC, Clang
>moved
>
>Ask their implementers. As far as I understand, they have other
>priorities
>and responsibilities in addition to maximum speed of implementing new
>features.
>
>> from C++11-style to C++14-style constexpr in the matter of a few
>months last
>> year. It's sad that the slowest adaptors determine the pace of
>progress.
>
>I never said the slowest adaptors determine the pace of progress. But
>if we don't
>pay heed to cases where the majority of vendors are all in the camp of
>"slowest
>adaptors", madness ensues. We shouldn't determine the pace of progress
>any more by the fastest adaptors as we do by the slowest ones.
>
>> Surely the committee is not in the business of protecting half a
>dozen
>> feet-dragging compilers from competitive pressures?
>
>A portion of the committee most certainly is. Other people may at times
>agree
>with that portion due to other reasons. Fast progress without
>portability is, for
>example, more or less useless to me and my users.
>
>> It would be interesting to see what would happen if someone hacked
>Clang to
>> introduce full D-style CTFE as an extension, (or TS or whatever the
>> politically accepted phrase is)
>
>It certainly would be interesting, yes.
>
>--=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 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/.
------W9QZGOFS833H4WP83LCPEKRQS2Z4T4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">Implementers should do as fine a jo=
b as the committee does, since some of them are members of the committee. T=
heir refuge behind unprovable complexity claims is unfounded on technical t=
erms when it harms the language by forcing programmers to go into complex l=
ibrary constructs that strain the compilers more than language features wou=
ld.</p>
<p dir=3D"ltr">Again, no valid reason against compile time evaluation is gi=
ven, especially since far too many people have uses for it to the point of =
implementing such behaviour through template meta-programming. Just like Da=
vid did with std::tuple for example on this thread.<br>
</p>
<br><br><div class=3D"gmail_quote">On September 2, 2014 10:59:49 PM EEST, V=
ille Voutilainen <ville.voutilainen@gmail.com> wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 2 September 2014 22:38, Rein Halbersma <rhalber=
sma@gmail.com> wrote:<br /><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;=
"> And what is holding the non-Clang compilers back exactly? IIRC, Clang mo=
ved<br /></blockquote><br />Ask their implementers. As far as I understand,=
they have other priorities<br />and responsibilities in addition to maximu=
m speed of implementing new features.<br /><br /><blockquote class=3D"gmail=
_quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf;=
padding-left: 1ex;"> from C++11-style to C++14-style constexpr in the matt=
er of a few months last<br /> year. It's sad that the slowest adaptors dete=
rmine the pace of progress.<br /></blockquote><br />I never said the slowes=
t adaptors determine the pace of progress. But<br />if we don't<br />pay he=
ed to cases where the majority of vendors are all in the camp of "slowest<b=
r />adaptors", madness ensues.
We shouldn't determine the pace of progress<br />any more by the fastest ad=
aptors as we do by the slowest ones.<br /><br /><blockquote class=3D"gmail_=
quote" style=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; =
padding-left: 1ex;"> Surely the committee is not in the business of protect=
ing half a dozen<br /> feet-dragging compilers from competitive pressures?<=
br /></blockquote><br />A portion of the committee most certainly is. Other=
people may at times agree<br />with that portion due to other reasons. Fas=
t progress without<br />portability is, for<br />example, more or less usel=
ess to me and my users.<br /><br /><blockquote class=3D"gmail_quote" style=
=3D"margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left=
: 1ex;"> It would be interesting to see what would happen if someone hacked=
Clang to<br /> introduce full D-style CTFE as an extension, (or TS or what=
ever the<br /> politically accepted phrase is)<br /></blockquote><br />It c=
ertainly would be interesting,
yes.<br /></pre></blockquote></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
------W9QZGOFS833H4WP83LCPEKRQS2Z4T4--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 2 Sep 2014 23:09:58 +0300
Raw View
On 2 September 2014 23:03, Rein Halbersma <rhalbersma@gmail.com> wrote:
> OK, Ville, thanks for your insights! I didn't mean to imply that one should
> hold you responsible for the current state of affairs :-)
No harm done. In general, for full compile-time evaluation, we would need
1) a proposal...
1.1) ...that has convincing motivation
2) to understand that shouting on this forum how C++ "chooses to
remain in the dark ages" doesn't cover
either of the above (and I'm not specifically addressing you with
this, Rein :) )
3) to understand that repeating the statement "you have no technical
argument" doesn't help much,
either. The committee doesn't need a technical argument, like it or
not. The burden of proof for
language extensions lies first and foremost on the proposal author.
The committee's _default_
answer to _anything_ that doesn't reach consensus is "no".
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 02 Sep 2014 23:23:13 +0300
Raw View
------QTQJCC0797N4E4E2X2NLNQW2Z2OBJB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Addressing others by proxy does not validate indefensible claims. The commi=
ttee is proven wrong in all your points when decisions based on social non-=
arguments are put forward by sponsored lobbying. Especially when it has to =
handle budding drafts that are not proposals yet, that haven't been put to =
any vote, yet delegating their essence to their sponsored members using arg=
uments as bogus as the ones for the lack of compile time evaluation. Worse =
if it is misguiding people.
So don't ask people for proposals if in the end you are the only ones who w=
ant to do them. And I am not addressing you directly as Ville, but as a res=
ponsible secretary. If you think that people should have respect for such a=
n argument, the answer is "No".
On September 2, 2014 11:09:58 PM EEST, Ville Voutilainen <ville.voutilainen=
@gmail.com> wrote:
>On 2 September 2014 23:03, Rein Halbersma <rhalbersma@gmail.com> wrote:
>> OK, Ville, thanks for your insights! I didn't mean to imply that one
>should
>> hold you responsible for the current state of affairs :-)
>
>No harm done. In general, for full compile-time evaluation, we would
>need
>1) a proposal...
>1.1) ...that has convincing motivation
>2) to understand that shouting on this forum how C++ "chooses to
>remain in the dark ages" doesn't cover
>either of the above (and I'm not specifically addressing you with
>this, Rein :) )
>3) to understand that repeating the statement "you have no technical
>argument" doesn't help much,
>either. The committee doesn't need a technical argument, like it or
>not. The burden of proof for
>language extensions lies first and foremost on the proposal author.
>The committee's _default_
>answer to _anything_ that doesn't reach consensus is "no".
>
>--=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 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/.
------QTQJCC0797N4E4E2X2NLNQW2Z2OBJB
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">Addressing others by proxy does not=
validate indefensible claims. The committee is proven wrong in all your po=
ints when decisions based on social non-arguments are put forward by sponso=
red lobbying. Especially when it has to handle budding drafts that are not =
proposals yet, that haven't been put to any vote, yet delegating their esse=
nce to their sponsored members using arguments as bogus as the ones for the=
lack of compile time evaluation. Worse if it is misguiding people.</p>
<p dir=3D"ltr">So don't ask people for proposals if in the end you are the =
only ones who want to do them. And I am not addressing you directly as Vill=
e, but as a responsible secretary. If you think that people should have res=
pect for such an argument, the answer is "No".<br>
</p>
<br><br><div class=3D"gmail_quote">On September 2, 2014 11:09:58 PM EEST, V=
ille Voutilainen <ville.voutilainen@gmail.com> wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px soli=
d rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 2 September 2014 23:03, Rein Halbersma <rhalber=
sma@gmail.com> wrote:<br /><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;=
"> OK, Ville, thanks for your insights! I didn't mean to imply that one sho=
uld<br /> hold you responsible for the current state of affairs :-)<br /></=
blockquote><br />No harm done. In general, for full compile-time evaluation=
, we would need<br />1) a proposal...<br />1.1) ...that has convincing moti=
vation<br />2) to understand that shouting on this forum how C++ "chooses t=
o<br />remain in the dark ages" doesn't cover<br />either of the above (and=
I'm not specifically addressing you with<br />this, Rein :) )<br />3) to u=
nderstand that repeating the statement "you have no technical<br />argument=
" doesn't help much,<br />either. The committee doesn't need a technical ar=
gument, like it or<br />not. The burden of proof for<br />language extensio=
ns lies first and foremost
on the proposal author.<br />The committee's _default_<br />answer to _anyt=
hing_ that doesn't reach consensus is "no".<br /></pre></blockquote></div><=
/body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
------QTQJCC0797N4E4E2X2NLNQW2Z2OBJB--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 2 Sep 2014 23:37:47 +0300
Raw View
On 2 September 2014 23:23, George Makrydakis <irrequietus@gmail.com> wrote:
> Addressing others by proxy does not validate indefensible claims. The
> committee is proven wrong in all your points when decisions based on social
> non-arguments are put forward by sponsored lobbying. Especially when it has
> to handle budding drafts that are not proposals yet, that haven't been put
> to any vote, yet delegating their essence to their sponsored members using
> arguments as bogus as the ones for the lack of compile time evaluation.
> Worse if it is misguiding people.
I think what's misguiding is all these unsubstantiated claims about
"social non-arguments",
"sponsored lobbying" and "bogus arguments".
> So don't ask people for proposals if in the end you are the only ones who
> want to do them. And I am not addressing you directly as Ville, but as a
We actually have evidence of not being the "only ones who want to do proposals".
Most of the successful proposals originating outside the committee actually
followed the proposal guidelines and considered the feedback given by the
subgroups of the committee.
> responsible secretary. If you think that people should have respect for such
> an argument, the answer is "No".
You seem to have a very bad misunderstanding what the INCITS/WG21 secretary
is and is not responsible for.
--
---
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/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 2 Sep 2014 15:33:50 -0700
Raw View
--089e01183d4eb33e9105021cb65d
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 2, 2014 at 12:38 PM, Rein Halbersma <rhalbersma@gmail.com>
wrote:
> On Tue, Sep 2, 2014 at 9:15 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>>
>> (*) Feel free to count the number of implementations that support
>> C++14 constexpr.
>> The result of that count is one. The expectation is that there should
>> eventually be half
>> a dozen more.
>
>
> And what is holding the non-Clang compilers back exactly? IIRC, Clang
> moved from C++11-style to C++14-style constexpr in the matter of a few
> months last year.
>
The implementation of C++14 constexpr in Clang took, in total, about a
week. But the starting point wasn't the same as it is for most compilers.
There are basically two different ways that people have historically
implemented constant expression evaluation in C and C++ compilers:
1) "fold": the AST is rewritten as constant expressions are simplified. In
some implementations this happens as you parse, in others it happens as a
separate step. So when you build a + operation whose operands are 1 and 1,
you end up with an expression "2" and no evidence that you ever had a '+'.
This also means you can use essentially the same code to perform various
kinds of optimization.
2) Real evaluation: the AST represents the code as written, and a separate
process walks it and produces a symbolic value from it.
Most implementations seem to do (1) in some way or another. This is fairly
well-suited for C++11 constexpr (where you can in-place-rewrite calls to
constexpr functions to the corresponding returned expression, substitute in
values for function parameters, and just keep on folding), but not
well-suited to C++14 constexpr. You can, in principle, use a similar
technique in C++14, but mutability and non-trivial control flow means you
need to keep a lot more things symbolic, retain an evaluation environment,
and perform rewrites in the appropriate sequencing order. [Even in C++11,
this approach is somewhat tricky, because (for instance) you need to track
whether the fold invoked undefined behavior (which would render an
expression non-constant) or otherwise did something that's not allowed in a
constant expression.]
Clang has always done (2). This made the C++11 constexpr implementation
more complex (because Clang couldn't rely on the existing code generation
codepaths to perform constant expression evaluation; all sorts of new forms
of evaluation needed to be implemented) but made implementing the C++14
constexpr much more straightforward, since most of the necessary
infrastructure was built as part of the C++11 constexpr implementation.
It's sad that the slowest adaptors determine the pace of progress. Surely
> the committee is not in the business of protecting half a dozen
> feet-dragging compilers from competitive pressures?
>
> It would be interesting to see what would happen if someone hacked Clang
> to introduce full D-style CTFE *as an extension, *(or TS or whatever the
> politically accepted phrase is)
>
I think the remaining holes in C++14 constexpr are:
* lambdas
* destructors
* polymorphism (virtual functions, dynamic_cast, typeid, exceptions [for
polymorphic catch])
* dynamic memory allocation
The other restrictions in 5.19 exist to prevent "bad things" (reading the
value representation of an object, undefined behavior, uninitialized stuff,
....) that would be non-portable, unimplementable (inline asm, depending on
values that don't exist until runtime, ...), or -- occasionally --
politically undesirable (goto considered harmful).
I'm confident we'll have a good answer for lambdas + constexpr in C++17.
Constexpr destructors add some implementation cost (implementations would
need to track whether and when to run destructors).
The committee had some fears about implementation issues with polymorphism
(requiring the compiler to track the dynamic type of an object), but we
already actually require such tracking, to support things like checking the
validity of a base-to-derived cast. I don't think there are pressing
technical issues here.
Dynamic memory allocation is a challenge, due to three factors:
1) Values will be represented differently during translation and during
execution, so it's not reasonable to expose the value representation of
objects during constexpr evaluation. This is mostly a problem for placement
allocation functions, since these allow a constexpr evaluation to get a
view of the same storage as both a T* and as (say) an array of unsigned
char.
2) Even if restricted to just the normal allocation functions, there is
still the issue that the normal allocation functions are replaceable. We
have (in C++14) adopted a rule that the compiler is not actually required
to call these functions if it can satisfy the allocation in some other way,
so this problem is mitigated; in constexpr evaluations, we would (out of
necessity) simply not call the allocation function at all.
3) If dynamic storage were able to "leak" from compile time evaluation to
runtime evaluation, we would need a mechanism to set up an initial heap
state of some form. This is both a desirable feature and a very technically
challenging one.
The simplest case for dynamic allocation -- support non-placement new and
delete only, do not allow the end result of a constant expression
evaluation to refer to dynamically-allocated memory, and do not call a
replacement global allocation/deallocation function -- is completely
straightforward in Clang's implementation. I can't speak for the complexity
that would be required in other implementations.
--
---
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/.
--089e01183d4eb33e9105021cb65d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 2, 2014 at 12:38 PM, Rein Halbersma <span dir=3D"ltr"><<a href=
=3D"mailto:rhalbersma@gmail.com" target=3D"_blank">rhalbersma@gmail.com</a>=
></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<div class=3D"">On Tue, Sep 2, 2014 at 9:15 PM, Ville Voutilainen <span dir=
=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blan=
k">ville.voutilainen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div><br></div>
(*) Feel free to count the number of implementations that support<br>
C++14 constexpr.<br>
The result of that count is one. The expectation is that there should<br>
eventually be half<br>
a dozen more.</blockquote><div><br></div></div><div>And what is holding the=
non-Clang compilers back exactly? IIRC, Clang moved from C++11-style to C+=
+14-style constexpr in the matter of a few months last year.</div></div>
</div></div></blockquote><div><br></div><div>The implementation of C++14 co=
nstexpr in Clang took, in total, about a week. But the starting point wasn&=
#39;t the same as it is for most compilers. There are basically two differe=
nt ways that people have historically implemented constant expression evalu=
ation in C and C++ compilers:</div>
<div><br></div><div>1) "fold": the AST is rewritten as constant e=
xpressions are simplified. In some implementations this happens as you pars=
e, in others it happens as a separate step. So when you build a + operation=
whose operands are 1 and 1, you end up with an expression "2" an=
d no evidence that you ever had a '+'. This also means you can use =
essentially the same code to perform various kinds of optimization.</div>
<div>2) Real evaluation: the AST represents the code as written, and a sepa=
rate process walks it and produces a symbolic value from it.</div><div><br>=
</div><div>Most implementations seem to do (1) in some way or another. This=
is fairly well-suited for C++11 constexpr (where you can in-place-rewrite =
calls to constexpr functions to the corresponding returned expression, subs=
titute in values for function parameters, and just keep on folding), but no=
t well-suited to C++14 constexpr. You can, in principle, use a similar tech=
nique in C++14, but mutability and non-trivial control flow means you need =
to keep a lot more things symbolic, retain an evaluation environment, and p=
erform rewrites in the appropriate sequencing order. [Even in C++11, this a=
pproach is somewhat tricky, because (for instance) you need to track whethe=
r the fold invoked undefined behavior (which would render an expression non=
-constant) or otherwise did something that's not allowed in a constant =
expression.]</div>
<div><br></div><div>Clang has always done (2). This made the C++11 constexp=
r implementation more complex (because Clang couldn't rely on the exist=
ing code generation codepaths to perform constant expression evaluation; al=
l sorts of new forms of evaluation needed to be implemented) but made imple=
menting the C++14 constexpr much more straightforward, since most of the ne=
cessary infrastructure was built as part of the C++11 constexpr implementat=
ion.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote">
<div>It's sad that the slowest adaptors determine the pace of progress.=
Surely the committee is not in the business of protecting half a dozen fee=
t-dragging compilers from competitive pressures?=C2=A0</div>
<div><br></div><div>It would be interesting to see what would happen if som=
eone hacked Clang to introduce full D-style CTFE <i>as an extension, </i>(o=
r TS or whatever the politically accepted phrase is)</div></div></div>
</div></blockquote><div><br></div><div>I think the remaining holes in C++14=
constexpr are:</div><div><br></div><div>=C2=A0* lambdas</div><div>=C2=A0* =
destructors</div><div>=C2=A0* polymorphism (virtual functions, dynamic_cast=
, typeid, exceptions [for polymorphic catch])<br>
</div><div>=C2=A0* dynamic memory allocation<br></div><div><br></div><div>T=
he other restrictions in 5.19 exist to prevent "bad things" (read=
ing the value representation of an object, undefined behavior, uninitialize=
d stuff, ...) that would be non-portable, unimplementable (inline asm, depe=
nding on values that don't exist until runtime, ...), or -- occasionall=
y -- politically undesirable (goto considered harmful).</div>
<div><br></div><div>I'm confident we'll have a good answer for lamb=
das + constexpr in C++17.</div><div><br></div><div>Constexpr destructors ad=
d some implementation cost (implementations would need to track whether and=
when to run destructors).</div>
<div><br></div><div>The committee had some fears about implementation issue=
s with polymorphism (requiring the compiler to track the dynamic type of an=
object), but we already actually require such tracking, to support things =
like checking the validity of a base-to-derived cast. I don't think the=
re are pressing technical issues here.</div>
<div><br></div><div>Dynamic memory allocation is a challenge, due to three =
factors:</div><div>=C2=A01) Values will be represented differently during t=
ranslation and during execution, so it's not reasonable to expose the v=
alue representation of objects during constexpr evaluation. This is mostly =
a problem for placement allocation functions, since these allow a constexpr=
evaluation to get a view of the same storage as both a T* and as (say) an =
array of unsigned char.</div>
<div>=C2=A02) Even if restricted to just the normal allocation functions, t=
here is still the issue that the normal allocation functions are replaceabl=
e. We have (in C++14) adopted a rule that the compiler is not actually requ=
ired to call these functions if it can satisfy the allocation in some other=
way, so this problem is mitigated; in constexpr evaluations, we would (out=
of necessity) simply not call the allocation function at all.</div>
<div>=C2=A03) If dynamic storage were able to "leak" from compile=
time evaluation to runtime evaluation, we would need a mechanism to set up=
an initial heap state of some form. This is both a desirable feature and a=
very technically challenging one.</div>
<div><br></div><div>The simplest case for dynamic allocation -- support non=
-placement new and delete only, do not allow the end result of a constant e=
xpression evaluation to refer to dynamically-allocated memory, and do not c=
all a replacement global allocation/deallocation function -- is completely =
straightforward in Clang's implementation. I can't speak for the co=
mplexity that would be required in other implementations.</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--089e01183d4eb33e9105021cb65d--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Wed, 03 Sep 2014 02:18:46 +0300
Raw View
On September 2, 2014 11:37:47 PM EEST, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
>I think what's misguiding is all these unsubstantiated claims about
>"social non-arguments",
>"sponsored lobbying" and "bogus arguments".
C++ needs volunteers, but it seems that certain people will have
problems with this. I am just informing a new potential author on what
to expect, given that you tried to motivate another person into going
through with a proposal. I will refer you to the certain events occuring
in Rapperswil, where I was motivated by you to come and discuss some
preliminary work and what happened afterwards - despite I am very happy
of having being there. It was awesome! However...
No votes, no technical arguments, given a library guideline for
something addressing EWG#30 as discussed, then the following day seeing
the gist of it being graciously delegated over to an internal party as a
language feature. I cared little about the library guideline "result" as
can be documented in another email. I don't think anymore that most of
you people can actually claim to understand what template
metaprogramming is for. "Your" problem started the next day, because of
EWG#30 and what some brilliant but hasty people did. That's when "you"
lost face, to put it bluntly.
Sponsored lobbying is occurring when people who work for your sponsors
in a big company with some vested interest in C++, vote their work
colleagues while they don't even bother to consider third party work in
order to prove or disprove it - despite they "want" to hear what it is
about. The claims are pretty much substantiated and your defensive
position against them disvalues you. Don't discuss a case that did not
involve you directly, for obvious reasons.
>
>We actually have evidence of not being the "only ones who want to do
>proposals".
>Most of the successful proposals originating outside the committee
>actually
>followed the proposal guidelines and considered the feedback given by
>the
>subgroups of the committee.
Misleading in its generalization by induction and inaccurate in its
content by ad-hominem intention. You forwarded yourself two N-less
drafts that were not part of the pre-mailing of the last meeting to the
EWG committee which were not given equal treatment, in the case I am
referring to.
Herb Sutter mentioned in public that such ways of leading people into
discussing their preliminary work are not following procedure. The
results of such non-sequiturs disprove your position as to the
infallible modus operandi of certain committee practices.
Giving a library guideline one day while delegating the gist of the same
work to a specific person as a language feature the next day, is very,
very problematic to "your" image. I still think it was an honest error,
but I see no real amendment to it by those involved. I let the readers
assume what they wish. I am entitled to continue my work based on that
preliminary draft (not proposal!) and let their overconfident brilliance
deal with the obvious aftermath.
Therefore, not only can you not cite procedure to your defense, but
neither can the EWG subgroup justify its conflicting deliberations other
than on the basis of C++ political-social necessities and non-arguments,
given that the EWG is not incompetent. I find that particularly amusing
under first order logic.
>
>> responsible secretary. If you think that people should have respect
>for such
>> an argument, the answer is "No".
>
>You seem to have a very bad misunderstanding what the INCITS/WG21
>secretary
>is and is not responsible for.
Again, motivating people to come to standard C++ meetings and work
voluntarily on material that is then "encouraged" towards misleading
guidelines (and following redelegation to internal parties by "blunder")
is awkward for you to defend. More so when you are a committee member,
national body authority on wg21 and EWG C++ committee secretary. It is
very problematic for the prestige of such meetings despite you are not
guilty as charged. If "I" cannot trust somebody who probably understands
this language better than "I" do and is aware of how these things are
done procedurally by title, who am "I" to trust? Naked kings?
Therefore, I am suggesting that you should not motivate newcomers on
this list and in this manner to follow a procedure for language features
"you guys" have apparently varying respect for. I still consider that
documentable case an unfortunate error that inconveniently burdens
"you". It is a consequence of "your" actions that people with first hand
experience of such errors simply point out the inconsistencies of your
paper trail.
Lastly, you seem to have a very big misunderstanding of what I am
actually going to prove despite your witty attempts at subverting the
argument. This is not an argument "you guys" can disprove or ignore due
to facts of "your" own creation. I am working on my own public draft,
based on my preliminary work as any other "motivated" author. "Your"
error is worth a particular kind of treatment, by technical resolution.
Have a pleasant evening and remember to keep it technical; as is my
substantiated critique of "your" procedures. You will have to discuss
this in your little inner circle, regardless of what your forced stance
on this list may be.
I still think *you* are an honest man; feel free to prove it and
continue to do great work.
George
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Wed, 03 Sep 2014 02:27:28 +0300
Raw View
This is a multi-part message in MIME format.
--------------060903030902030509080200
Content-Type: text/plain; charset=UTF-8; format=flowed
On 09/03/2014 01:33 AM, Richard Smith wrote:
> On Tue, Sep 2, 2014 at 12:38 PM, Rein Halbersma <rhalbersma@gmail.com
> <mailto:rhalbersma@gmail.com>> wrote:
>
> On Tue, Sep 2, 2014 at 9:15 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com <mailto:ville.voutilainen@gmail.com>>
> wrote:
>
>
> (*) Feel free to count the number of implementations that support
> C++14 constexpr.
> The result of that count is one. The expectation is that there
> should
> eventually be half
> a dozen more.
>
>
> And what is holding the non-Clang compilers back exactly? IIRC,
> Clang moved from C++11-style to C++14-style constexpr in the
> matter of a few months last year.
>
>
> The implementation of C++14 constexpr in Clang took, in total, about a
> week. But the starting point wasn't the same as it is for most
> compilers. There are basically two different ways that people have
> historically implemented constant expression evaluation in C and C++
> compilers:
I would argue that doing anything related to extending templates and
constexpr in clang++ is probably the best way to go about studying new
features. It is a better structured compiler, despite some long standing
bugs of interest to niche public. This makes it easy for it to implement
new features and for others, like yours truly, to implement their own.
>
> 1) "fold": the AST is rewritten as constant expressions are
> simplified. In some implementations this happens as you parse, in
> others it happens as a separate step. So when you build a + operation
> whose operands are 1 and 1, you end up with an expression "2" and no
> evidence that you ever had a '+'. This also means you can use
> essentially the same code to perform various kinds of optimization.
> 2) Real evaluation: the AST represents the code as written, and a
> separate process walks it and produces a symbolic value from it.
>
> Most implementations seem to do (1) in some way or another. This is
> fairly well-suited for C++11 constexpr (where you can in-place-rewrite
> calls to constexpr functions to the corresponding returned expression,
> substitute in values for function parameters, and just keep on
> folding), but not well-suited to C++14 constexpr. You can, in
> principle, use a similar technique in C++14, but mutability and
> non-trivial control flow means you need to keep a lot more things
> symbolic, retain an evaluation environment, and perform rewrites in
> the appropriate sequencing order. [Even in C++11, this approach is
> somewhat tricky, because (for instance) you need to track whether the
> fold invoked undefined behavior (which would render an expression
> non-constant) or otherwise did something that's not allowed in a
> constant expression.]
>
> Clang has always done (2). This made the C++11 constexpr
> implementation more complex (because Clang couldn't rely on the
> existing code generation codepaths to perform constant expression
> evaluation; all sorts of new forms of evaluation needed to be
> implemented) but made implementing the C++14 constexpr much more
> straightforward, since most of the necessary infrastructure was built
> as part of the C++11 constexpr implementation.
>
> It's sad that the slowest adaptors determine the pace of progress.
> Surely the committee is not in the business of protecting half a
> dozen feet-dragging compilers from competitive pressures?
>
> It would be interesting to see what would happen if someone hacked
> Clang to introduce full D-style CTFE /as an extension, /(or TS or
> whatever the politically accepted phrase is)
>
>
> I think the remaining holes in C++14 constexpr are:
>
> * lambdas
> * destructors
> * polymorphism (virtual functions, dynamic_cast, typeid, exceptions
> [for polymorphic catch])
> * dynamic memory allocation
>
> The other restrictions in 5.19 exist to prevent "bad things" (reading
> the value representation of an object, undefined behavior,
> uninitialized stuff, ...) that would be non-portable, unimplementable
> (inline asm, depending on values that don't exist until runtime, ...),
> or -- occasionally -- politically undesirable (goto considered harmful).
>
> I'm confident we'll have a good answer for lambdas + constexpr in C++17.
>
> Constexpr destructors add some implementation cost (implementations
> would need to track whether and when to run destructors).
>
> The committee had some fears about implementation issues with
> polymorphism (requiring the compiler to track the dynamic type of an
> object), but we already actually require such tracking, to support
> things like checking the validity of a base-to-derived cast. I don't
> think there are pressing technical issues here.
>
> Dynamic memory allocation is a challenge, due to three factors:
> 1) Values will be represented differently during translation and
> during execution, so it's not reasonable to expose the value
> representation of objects during constexpr evaluation. This is mostly
> a problem for placement allocation functions, since these allow a
> constexpr evaluation to get a view of the same storage as both a T*
> and as (say) an array of unsigned char.
> 2) Even if restricted to just the normal allocation functions, there
> is still the issue that the normal allocation functions are
> replaceable. We have (in C++14) adopted a rule that the compiler is
> not actually required to call these functions if it can satisfy the
> allocation in some other way, so this problem is mitigated; in
> constexpr evaluations, we would (out of necessity) simply not call the
> allocation function at all.
> 3) If dynamic storage were able to "leak" from compile time
> evaluation to runtime evaluation, we would need a mechanism to set up
> an initial heap state of some form. This is both a desirable feature
> and a very technically challenging one.
>
> The simplest case for dynamic allocation -- support non-placement new
> and delete only, do not allow the end result of a constant expression
> evaluation to refer to dynamically-allocated memory, and do not call a
> replacement global allocation/deallocation function -- is completely
> straightforward in Clang's implementation. I can't speak for the
> complexity that would be required in other implementations.
> --
>
Now, this is a true technical reply and the reason I keep following this
list for the time being. Thanks.
--
---
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/.
--------------060903030902030509080200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
<div class=3D"moz-cite-prefix">On 09/03/2014 01:33 AM, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQq=3DK0XDR-zy6N8hMFQiwfa1o77GcuAAp-wDMDacSHXmy9Q@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Tue, Sep 2, 2014 at 12:38 PM, Rein
Halbersma <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:rhalbersma@gmail.com" target=3D"_blank">rhal=
bersma@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div class=3D"">On Tue, Sep 2, 2014 at 9:15 PM, Ville
Voutilainen <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:ville.voutilainen@gmail.com"
target=3D"_blank">ville.voutilainen@gmail.com</a>=
></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
<div><br>
</div>
(*) Feel free to count the number of
implementations that support<br>
C++14 constexpr.<br>
The result of that count is one. The expectation
is that there should<br>
eventually be half<br>
a dozen more.</blockquote>
<div><br>
</div>
</div>
<div>And what is holding the non-Clang compilers
back exactly? IIRC, Clang moved from C++11-style
to C++14-style constexpr in the matter of a few
months last year.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The implementation of C++14 constexpr in Clang took, in
total, about a week. But the starting point wasn't the
same as it is for most compilers. There are basically two
different ways that people have historically implemented
constant expression evaluation in C and C++ compilers:</div>
</div>
</div>
</div>
</blockquote>
<br>
I would argue that doing anything related to extending templates and
constexpr in clang++ is probably the best way to go about studying
new features. It is a better structured compiler, despite some long
standing bugs of interest to niche public. This makes it easy for it
to implement new features and for others, like yours truly, to
implement their own.<br>
<br>
<blockquote
cite=3D"mid:CAOfiQq=3DK0XDR-zy6N8hMFQiwfa1o77GcuAAp-wDMDacSHXmy9Q@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>1) "fold": the AST is rewritten as constant expressions
are simplified. In some implementations this happens as
you parse, in others it happens as a separate step. So
when you build a + operation whose operands are 1 and 1,
you end up with an expression "2" and no evidence that you
ever had a '+'. This also means you can use essentially
the same code to perform various kinds of optimization.</div>
<div>2) Real evaluation: the AST represents the code as
written, and a separate process walks it and produces a
symbolic value from it.</div>
<div><br>
</div>
<div>Most implementations seem to do (1) in some way or
another. This is fairly well-suited for C++11 constexpr
(where you can in-place-rewrite calls to constexpr
functions to the corresponding returned expression,
substitute in values for function parameters, and just
keep on folding), but not well-suited to C++14 constexpr.
You can, in principle, use a similar technique in C++14,
but mutability and non-trivial control flow means you need
to keep a lot more things symbolic, retain an evaluation
environment, and perform rewrites in the appropriate
sequencing order. [Even in C++11, this approach is
somewhat tricky, because (for instance) you need to track
whether the fold invoked undefined behavior (which would
render an expression non-constant) or otherwise did
something that's not allowed in a constant expression.]</div>
<div><br>
</div>
<div>Clang has always done (2). This made the C++11
constexpr implementation more complex (because Clang
couldn't rely on the existing code generation codepaths to
perform constant expression evaluation; all sorts of new
forms of evaluation needed to be implemented) but made
implementing the C++14 constexpr much more
straightforward, since most of the necessary
infrastructure was built as part of the C++11 constexpr
implementation.</div>
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>It's sad that the slowest adaptors determine
the pace of progress. Surely the committee is not
in the business of protecting half a dozen
feet-dragging compilers from competitive
pressures?=C2=A0</div>
<div><br>
</div>
<div>It would be interesting to see what would
happen if someone hacked Clang to introduce full
D-style CTFE <i>as an extension, </i>(or TS or
whatever the politically accepted phrase is)</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I think the remaining holes in C++14 constexpr are:</div>
<div><br>
</div>
<div>=C2=A0* lambdas</div>
<div>=C2=A0* destructors</div>
<div>=C2=A0* polymorphism (virtual functions, dynamic_cast,
typeid, exceptions [for polymorphic catch])<br>
</div>
<div>=C2=A0* dynamic memory allocation<br>
</div>
<div><br>
</div>
<div>The other restrictions in 5.19 exist to prevent "bad
things" (reading the value representation of an object,
undefined behavior, uninitialized stuff, ...) that would
be non-portable, unimplementable (inline asm, depending on
values that don't exist until runtime, ...), or --
occasionally -- politically undesirable (goto considered
harmful).</div>
<div><br>
</div>
<div>I'm confident we'll have a good answer for lambdas +
constexpr in C++17.</div>
<div><br>
</div>
<div>Constexpr destructors add some implementation cost
(implementations would need to track whether and when to
run destructors).</div>
<div><br>
</div>
<div>The committee had some fears about implementation
issues with polymorphism (requiring the compiler to track
the dynamic type of an object), but we already actually
require such tracking, to support things like checking the
validity of a base-to-derived cast. I don't think there
are pressing technical issues here.</div>
<div><br>
</div>
<div>Dynamic memory allocation is a challenge, due to three
factors:</div>
<div>=C2=A01) Values will be represented differently during
translation and during execution, so it's not reasonable
to expose the value representation of objects during
constexpr evaluation. This is mostly a problem for
placement allocation functions, since these allow a
constexpr evaluation to get a view of the same storage as
both a T* and as (say) an array of unsigned char.</div>
<div>=C2=A02) Even if restricted to just the normal allocation
functions, there is still the issue that the normal
allocation functions are replaceable. We have (in C++14)
adopted a rule that the compiler is not actually required
to call these functions if it can satisfy the allocation
in some other way, so this problem is mitigated; in
constexpr evaluations, we would (out of necessity) simply
not call the allocation function at all.</div>
<div>=C2=A03) If dynamic storage were able to "leak" from compi=
le
time evaluation to runtime evaluation, we would need a
mechanism to set up an initial heap state of some form.
This is both a desirable feature and a very technically
challenging one.</div>
<div><br>
</div>
<div>The simplest case for dynamic allocation -- support
non-placement new and delete only, do not allow the end
result of a constant expression evaluation to refer to
dynamically-allocated memory, and do not call a
replacement global allocation/deallocation function -- is
completely straightforward in Clang's implementation. I
can't speak for the complexity that would be required in
other implementations.</div>
</div>
</div>
</div>
-- <br>
<br>
</blockquote>
<br>
Now, this is a true technical reply and the reason I keep following
this list for the time being. Thanks.<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------060903030902030509080200--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 3 Sep 2014 10:36:00 +0800
Raw View
--Apple-Mail=_B12C16C6-812E-4E8B-A305-561D47DF7E1C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Yikes, last night I slept through my own thread. Here's a combo reply.
On 2014-09-02, at 11:14 PM, Ville Voutilainen <ville.voutilainen@gmail.com>=
wrote:
> Sounds like a decent idea. Any particular reason why we wouldn't make
> the existing overloads constexpr?
I didn't mean to specifically exclude the existing ones, but the only curre=
nt overloads take an iterator range and a predicate, which is typically a l=
ambda. Since we don't have constexpr containers (unless you count array, an=
d initializer_list which I covered) nor constexpr lambdas, adding constexpr=
there could be premature.
On the other hand, the future trend will be toward more constexpr. I wish c=
onstexpr generic algorithms were already optional to the implementation. Co=
nstexpr qualification is designed to limit compilation complexity, but if g=
uarantees of non-qualification lead to programs that really depend on non-q=
ualification, users will have been misled when those programs break.
On 2014-09-03, at 12:50 AM, George Makrydakis <irrequietus@gmail.com> wrote=
:
> The tuple solution works because you are using std::tuple as a boost::mpl=
::vector substitute and implementing catamorphisms over packs through "tupl=
e processing" naming them differently from what they substantially are.
>=20
Packs are neither tuples (fixed size, unlike elements) nor vectors (fixed s=
ize, like elements), they are lists (variable size, like elements) or perha=
ps queues, since insertion and removal occur at either end.
Anyway, I don't think taxonomy is a good guiding force.
Template-ids work perfectly well as metadata elements. Naming a class templ=
ate specialization such as tuple<void> does not cause an instantiation, so =
there are no semantic requirements on the types in the list. Type-list oper=
ations can invariably be implemented without instantiating the type-list cl=
ass.
Metacomputation often generates runtime types, and using tuple as the basis=
of computation saves a rebind operation. For a program which generates man=
y types, that may halve the metadata the compiler needs to deal with.
> Are you certain that making constexpr overloads of such algorithms like a=
ll_of etc is better than addressing the real issue, meaning the lack of fir=
st class support for the fundamentals allowing such constructs? Shouldn't t=
hese things be considered eventually by expanding <type_traits> to boost::m=
pl territory?
>=20
We already have tuple_element and tuple_size.
> Seems more like another popular substitute by hasty inspiration than a s=
olution by design.
>=20
bool all_of( std::initializer_list< bool > ) is simple and obvious, does th=
at make it "hasty"? I happen to do a lot of metaprogramming, but the functi=
on isn't specific to metaprogramming at all.
Adding a new core language construct for type lists when we already have al=
l the right machinery, and plenty of legacy code already works without, sou=
nds like over-specific optimization for niche uses at the expense of curren=
t practice. Impeding progress on unrelated issues for the sake of increasin=
g pressure to adopt a specific direction on one issue is dirty politics.
On 2014-09-03, at 1:42 AM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
> It's, however, likely that at some point there's going to be
> increasing resistance
> towards imposing such compile-time evaluation of everything on every
> implementation.
That happened already at the beginning, right? I'd predict that the state o=
f the art will progress in an equilibrium. It would be unwise to require fu=
ll runtime emulation from everyone in 2014, but 2030 should be enough time =
:) . I'm all for progress, but nobody benefits from a standard until it's i=
mplemented, and divergence due to implementations prioritizing different fe=
ature subsets is still divergence in practical terms.
On 2014-09-03, at 1:50 AM, Rein Halbersma <rhalbersma@gmail.com> wrote:
> Just a naive and honest question: what are the main technical obstacles f=
or compile-time evaluation of all non-I/O expressions?
Correctness and portability. C++ is trickier than D.
> (and prefereably without the constexpr keyword, implicit would do nicely)=
Works for D, so it seems it can be done, but maybe D's compilation model i=
s too different from C++'s?
http://stackoverflow.com/a/19830673/153285 (and follow the link back to thi=
s list).
On 2014-09-03, at 2:29 AM, George Makrydakis <irrequietus@gmail.com> wrote:
> The issue is not static if alone. The committee does not have a real argu=
ment against compile time evaluation. Just politics.
>=20
In practice the approaches to metaprogramming are more divergent than to us=
ual programming, for many reasons:
1. It feels different and unfamiliar, so beginners are tempted to throw kno=
wledge out the window and "just hack it."
2. Metaprogramming is more tractable without side effects, so imperative pr=
ogramming tends to get excluded. This was true even in macro preprocessor d=
ays. This is the real reason static_if will never happen.
3. Implementations have various quirks, leading to numerous and divergent s=
uperstitious workarounds. I still see new code using typedef char yes[2]; s=
izeof sfinae_test( blah ) =3D=3D sizeof (yes). This is just an illustrative=
example, but distraction and circumlocution have hindered the evolutionary=
development of C++ best practices.
"Politics" are inevitable. Good politics involves not only consensus, but t=
he modesty to limit eternal commitments to judgments of absolute certainty.=
High-level metaprogramming in general, not only C++, is too new to expect =
consensus nor certainty about what is necessary or so harmful as to be usel=
ess.
On 2014-09-03, at 3:15 AM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
> The result of that count is one.
Clang.
> The expectation is that there should
> eventually be half
> a dozen more.
GCC, EDG, MSVC, XLC, Sun, make five.
Borland gave up and adopted Clang. Digital Mars and Green Hills have been a=
wful quiet lately, it's not clear that they have the economic motivation to=
finish C++11. What am I missing?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_B12C16C6-812E-4E8B-A305-561D47DF7E1C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;">Yikes, last night I sl=
ept through my own thread. Here’s a combo reply.<div><br><div><div>On=
2014–09–02, at 11:14 PM, Ville Voutilainen <<a href=3D"mail=
to:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:<=
/div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">Soun=
ds like a decent idea. Any particular reason why we wouldn't make<br>the ex=
isting overloads constexpr?<br></blockquote><div><br></div><div>I didn&rsqu=
o;t mean to specifically exclude the existing ones, but the only current ov=
erloads take an iterator range and a predicate, which is typically a lambda=
.. Since we don’t have constexpr containers (unless you count <font fa=
ce=3D"Courier">array</font>, and <font face=3D"Courier">initializer_list</f=
ont> which I covered) nor constexpr lambdas, adding <font face=3D"Courier">=
constexpr</font> there could be premature.</div><div><br></div><div>On the =
other hand, the future trend will be toward more constexpr. I wish constexp=
r generic algorithms were already optional to the implementation. Constexpr=
qualification is designed to limit compilation complexity, but if guarante=
es of non-qualification lead to programs that really depend on non-qualific=
ation, users will have been misled when those programs break.</div></div><b=
r></div><div><br></div><div><div>On 2014–09–03, at 12:50 AM, Ge=
orge Makrydakis <<a href=3D"mailto:irrequietus@gmail.com">irrequietus@gm=
ail.com</a>> wrote:</div><blockquote type=3D"cite"><p dir=3D"ltr">The tu=
ple solution works because you are using std::tuple as a boost::mpl::vector=
substitute and implementing catamorphisms over packs through "tuple proces=
sing" naming them differently from what they substantially are.</p></blockq=
uote><div>Packs are neither tuples (fixed size, unlike elements) nor vector=
s (fixed size, like elements), they are lists (variable size, like elements=
) or perhaps queues, since insertion and removal occur at either end.</div>=
<div><br></div><div>Anyway, I don’t think taxonomy is a good guiding =
force.</div><div><br></div><div>Template-ids work perfectly well as metadat=
a elements. Naming a class template specialization such as <font face=3D"Co=
urier">tuple<void></font> does not cause an instantiation, so there a=
re no semantic requirements on the types in the list. Type-list operations =
can invariably be implemented without instantiating the type-list class.</d=
iv><div><br></div><div>Metacomputation often generates runtime types, and u=
sing <font face=3D"Courier">tuple</font> as the basis of computation saves =
a rebind operation. For a program which generates many types, that may halv=
e the metadata the compiler needs to deal with.</div><blockquote type=3D"ci=
te"><p dir=3D"ltr">Are you certain that making constexpr overloads of such =
algorithms like all_of etc is better than addressing the real issue, meanin=
g the lack of first class support for the fundamentals allowing such constr=
ucts? Shouldn't these things be considered eventually by expanding <type=
_traits> to boost::mpl territory?</p></blockquote><div>We already have <=
font face=3D"Courier">tuple_element</font> and <font face=3D"Courier">=
tuple_size</font>.</div><blockquote type=3D"cite"><p dir=3D"ltr"> Seem=
s more like another popular substitute by hasty inspiration than a solution=
by design.</p></blockquote></div><div><font face=3D"Courier">bool all_of( =
std::initializer_list< bool > )</font> is simple and obvious, do=
es that make it “hasty”? I happen to do a lot of metaprogrammin=
g, but the function isn’t specific to metaprogramming at all.</div><d=
iv><br></div><div>Adding a new core language construct for type lists when =
we already have all the right machinery, and plenty of legacy code already =
works without, sounds like over-specific optimization for niche uses at the=
expense of current practice. Impeding progress on unrelated issues for the=
sake of increasing pressure to adopt a specific direction on one issue is =
dirty politics.</div><div><br></div><div><br></div><div><div>On 2014–=
09–03, at 1:42 AM, Ville Voutilainen <<a href=3D"mailto:ville.vout=
ilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><br clas=
s=3D"Apple-interchange-newline"><blockquote type=3D"cite">It's, however, li=
kely that at some point there's going to be<br>increasing resistance<br>tow=
ards imposing such compile-time evaluation of everything on every<br>implem=
entation.</blockquote></div><div><br></div><div>That happened already at th=
e beginning, right? I’d predict that the state of the art will progre=
ss in an equilibrium. It would be unwise to require full runtime emulation =
from everyone in 2014, but 2030 should be enough time :) . I’m all fo=
r progress, but nobody benefits from a standard until it’s implemente=
d, and divergence due to implementations prioritizing different feature sub=
sets is still divergence in practical terms.</div><div><br></div><div><br><=
/div><div><div>On 2014–09–03, at 1:50 AM, Rein Halbersma <<a=
href=3D"mailto:rhalbersma@gmail.com">rhalbersma@gmail.com</a>> wrote:</=
div></div><div><br class=3D"Apple-interchange-newline"><blockquote type=3D"=
cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">Just a naive and honest question: what are the main technical obstacles f=
or compile-time evaluation of all non-I/O expressions? </div></div></div></=
blockquote><div><br></div><div>Correctness and portability. C++ is trickier=
than D.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote">(and prefereably without the conste=
xpr keyword, implicit would do nicely) Works for D, so it seems it can be d=
one, but maybe D's compilation model is too different from C++'s?</div></di=
v></div></blockquote><br></div><div><a href=3D"http://stackoverflow.com/a/1=
9830673/153285">http://stackoverflow.com/a/19830673/153285</a> (and follow =
the link back to this list).</div><div><br></div><div><br></div><div><div>O=
n 2014–09–03, at 2:29 AM, George Makrydakis <<a href=3D"mail=
to:irrequietus@gmail.com">irrequietus@gmail.com</a>> wrote:</div><blockq=
uote type=3D"cite"><p dir=3D"ltr">The issue is not static if alone. The com=
mittee does not have a real argument against compile time evaluation. Just =
politics.</p></blockquote></div><div>In practice the approaches to metaprog=
ramming are more divergent than to usual programming, for many reasons:</di=
v><div><br></div><div>1. It feels different and unfamiliar, so beginners ar=
e tempted to throw knowledge out the window and “just hack it.”=
</div><div>2. Metaprogramming is more tractable without side effects, so im=
perative programming tends to get excluded. This was true even in macro pre=
processor days. This is the real reason <font face=3D"Courier">static_if</f=
ont> will never happen.</div><div>3. Implementations have various quirks, l=
eading to numerous and divergent superstitious workarounds. I still see new=
code using <font face=3D"Courier">typedef char yes[2]; sizeof sfinae_test(=
blah ) =3D=3D sizeof (yes)</font>. This is just an illustrative example, b=
ut distraction and circumlocution have hindered the evolutionary developmen=
t of C++ best practices.</div><div><br></div><div>“Politics” ar=
e inevitable. <i>Good</i> politics involves not only consensus, but th=
e modesty to limit eternal commitments to judgments of absolute certainty. =
High-level metaprogramming in general, not only C++, is too new to expect c=
onsensus nor certainty about what is necessary or so harmful as to be usele=
ss.</div><div><br></div><div><br></div><div><div>On 2014–09–03,=
at 3:15 AM, Ville Voutilainen <<a href=3D"mailto:ville.voutilainen@gmai=
l.com">ville.voutilainen@gmail.com</a>> wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite">The result of that count is o=
ne.</blockquote><div><br></div><div>Clang.</div><br><blockquote type=3D"cit=
e">The expectation is that there should<br>eventually be half<br>a dozen mo=
re.</blockquote></div><div><br></div><div>GCC, EDG, MSVC, XLC, Sun, make fi=
ve.</div><div><br></div><div>Borland gave up and adopted Clang. Digital Mar=
s and Green Hills have been awful quiet lately, it’s not clear that t=
hey have the economic motivation to finish C++11. What am I missing?</div><=
div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_B12C16C6-812E-4E8B-A305-561D47DF7E1C--
.
Author: ville.voutilainen@gmail.com
Date: Wed, 3 Sep 2014 07:03:44 +0000
Raw View
On Wed Sep 03 2014 05:36:00 GMT+0300 (EEST), David Krauss wrote:
> Yikes, last night I slept through my own thread. Here's a combo reply.
> On 2014-09-03, at 3:15 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>
> > The result of that count is one.
>
> Clang.
>
> > The expectation is that there should
> > eventually be half
> > a dozen more.
>
>
> GCC, EDG, MSVC, XLC, Sun, make five.
>
> Borland gave up and adopted Clang. Digital Mars and Green Hills have been awful quiet lately, it's not clear that they have the economic motivation to finish C++11. What am I missing?
Intel?
--
---
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/.
.
Author: Rein Halbersma <rhalbersma@gmail.com>
Date: Wed, 3 Sep 2014 09:21:06 +0200
Raw View
--14dae94734a359a5c005022414d7
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 3, 2014 at 12:33 AM, Richard Smith <richard@metafoo.co.uk>
wrote:
> Dynamic memory allocation is a challenge, due to three factors:
> 1) Values will be represented differently during translation and during
> execution, so it's not reasonable to expose the value representation of
> objects during constexpr evaluation. This is mostly a problem for placement
> allocation functions, since these allow a constexpr evaluation to get a
> view of the same storage as both a T* and as (say) an array of unsigned
> char.
> 2) Even if restricted to just the normal allocation functions, there is
> still the issue that the normal allocation functions are replaceable. We
> have (in C++14) adopted a rule that the compiler is not actually required
> to call these functions if it can satisfy the allocation in some other way,
> so this problem is mitigated; in constexpr evaluations, we would (out of
> necessity) simply not call the allocation function at all.
> 3) If dynamic storage were able to "leak" from compile time evaluation to
> runtime evaluation, we would need a mechanism to set up an initial heap
> state of some form. This is both a desirable feature and a very technically
> challenging one.
>
> The simplest case for dynamic allocation -- support non-placement new and
> delete only, do not allow the end result of a constant expression
> evaluation to refer to dynamically-allocated memory, and do not call a
> replacement global allocation/deallocation function -- is completely
> straightforward in Clang's implementation. I can't speak for the complexity
> that would be required in other implementations.
>
Could you give an example of what type of code would be possible / hard?
E.g. what kind of functionality would be feasible for a constexpr
std::string? The full std::string interface, or only strings that fit
within a small string buffer? It would be extremely nice do abandon all the
variadic template/lambda hacks that do some crippled compile-time string
manipulation.
--
---
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/.
--14dae94734a359a5c005022414d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Sep 3, 2014 at 12:33 AM, Richard Smith <span dir=3D"ltr"><<a href=3D=
"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"">Dynamic memory allocation is a c=
hallenge, due to three factors:<br>
</div><div>=C2=A01) Values will be represented differently during translati=
on and during execution, so it's not reasonable to expose the value rep=
resentation of objects during constexpr evaluation. This is mostly a proble=
m for placement allocation functions, since these allow a constexpr evaluat=
ion to get a view of the same storage as both a T* and as (say) an array of=
unsigned char.</div>
<div>=C2=A02) Even if restricted to just the normal allocation functions, t=
here is still the issue that the normal allocation functions are replaceabl=
e. We have (in C++14) adopted a rule that the compiler is not actually requ=
ired to call these functions if it can satisfy the allocation in some other=
way, so this problem is mitigated; in constexpr evaluations, we would (out=
of necessity) simply not call the allocation function at all.</div>
<div>=C2=A03) If dynamic storage were able to "leak" from compile=
time evaluation to runtime evaluation, we would need a mechanism to set up=
an initial heap state of some form. This is both a desirable feature and a=
very technically challenging one.</div>
<div><br></div><div>The simplest case for dynamic allocation -- support non=
-placement new and delete only, do not allow the end result of a constant e=
xpression evaluation to refer to dynamically-allocated memory, and do not c=
all a replacement global allocation/deallocation function -- is completely =
straightforward in Clang's implementation. I can't speak for the co=
mplexity that would be required in other implementations.</div>
</div></div></div></blockquote><div><br></div><div>Could you give an exampl=
e of what type of code would be possible / hard? E.g. what kind of function=
ality would be feasible for a constexpr std::string? The full std::string i=
nterface, or only strings that fit within a small string buffer? It would b=
e extremely nice do abandon all the variadic template/lambda hacks that do =
some crippled compile-time string manipulation.</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--14dae94734a359a5c005022414d7--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Wed, 03 Sep 2014 10:29:07 +0300
Raw View
On 09/03/2014 10:03 AM, ville.voutilainen@gmail.com wrote:
>
> On Wed Sep 03 2014 05:36:00 GMT+0300 (EEST), David Krauss wrote:
>> Yikes, last night I slept through my own thread. Here's a combo reply.
>
>> On 2014-09-03, at 3:15 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>>
>>> The result of that count is one.
>> Clang.
>>
>>> The expectation is that there should
>>> eventually be half
>>> a dozen more.
>>
>> GCC, EDG, MSVC, XLC, Sun, make five.
>>
>> Borland gave up and adopted Clang. Digital Mars and Green Hills have been awful quiet lately, it's not clear that they have the economic motivation to finish C++11. What am I missing?
> Intel?
>
About Intel, remember:
1) https://isocpp.org/blog/2013/10/edg48-vc2013
2) https://www.edg.com/index.php?location=faq_q3_who
3) http://www.boost.org/doc/libs/1_56_0/boost/config/compiler/intel.hpp
It seems that the compiler implementation difficulty argument is
problematic as well since the actual compilers going after a valid
implementation are the usual knowns.
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Wed, 03 Sep 2014 11:37:58 +0300
Raw View
This is a multi-part message in MIME format.
--------------000409030109010902030008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 09/03/2014 05:36 AM, David Krauss wrote:
> On 2014--09--03, at 12:50 AM, George Makrydakis <irrequietus@gmail.com
> <mailto:irrequietus@gmail.com>> wrote:
>>
>> The tuple solution works because you are using std::tuple as a
>> boost::mpl::vector substitute and implementing catamorphisms over
>> packs through "tuple processing" naming them differently from what
>> they substantially are.
>>
> Packs are neither tuples (fixed size, unlike elements) nor vectors
> (fixed size, like elements), they are lists (variable size, like
> elements) or perhaps queues, since insertion and removal occur at
> either end.
Incorrect; parameter packs behave like product types and their way of
processing head-to-list is what is revealing of their "tuple" nature.
Are they not an n-ordered sequence of parameter types? Are tuples in
their mathematical sense modelled as nested ordered pairs? See an
analysis of the behavior of parameter packs at
http://ecn.channel9.msdn.com/events/GoingNative12/GN12VariadicTemplatesAreFunadic.pdf.
For the rest google is your friend. Take note that "tuple" without an
std:: infront of it does not refer to a std::tuple, but to the notion
std::tuple is actually implementing (as well as others like it).
The std::tuple tuple becomes of fixed size once you instantiate the
template. But per se, you use it in a context where it is fed a
parameter pack, whose size is determined in instantiation. Its template
parameter list as a class template in serious C++11 implementations,
/*is using itself the pack*/ which is the fundamental concept of what we
are referring to type-wise. And it is not a secret that template
meta-programmers (ab)use the std::tuple class template and the
std::get<N> over it when they are trying do some pretty trivial stuff
instead of depending upon boost::mpl::vector. Also, you should remember
that boost::mpl::deque as per
http://www.boost.org/doc/libs/1_56_0/boost/mpl/deque.hpp is that they
are in the end based on boost::mpl::vector, which itself in any serious
C++11 implementation depends upon the concept of a pack.
What you are describing as "insertion and removal occur at either end"
was actually already happening with boost::mpl::vectors, that are easier
to implement now that packs are available because packs are the
fundamental construct here. Even boost::mpl::deque is actually using
boost::mpl::vector, so yes, terminology is something severely impaired
for the vast majority of people citing such sources.
Parameter packs, under the condition that their use in a template
parameter list is made within a deducible context (remember multiple
parameter packs?) can allow both catamorphisms and anamorphisms (left
and right folds and unfolds, referring to your "ends" processing) and
structure preserving transformations (for example mapping). See
http://en.cppreference.com/w/cpp/language/parameter_pack#Pack_expansion
currently for some creative uses of pack expansion.
>
> Anyway, I don't think taxonomy is a good guiding force.
In the sense that C++ has the term "functor" for something that has
nothing to do with the actual way functor is used in category theory, I
would agree. C++ terminology is working against itself because it has to
cater for people who willfully ignore established terminology preceding
C++ itself. As are other things. So, yes, taxonomy is not helping such
arguments because it is vaporizing their substance.
>
> Template-ids work perfectly well as metadata elements. Naming a class
> template specialization such as tuple<void> does not cause an
> instantiation, so there are no semantic requirements on the types in
> the list. Type-list operations can invariably be implemented without
> instantiating the type-list class.
>
> Metacomputation often generates runtime types, and using tuple as the
> basis of computation saves a rebind operation. For a program which
> generates many types, that may halve the metadata the compiler needs
> to deal with.
First, you are overusing the term meta- to the demise of the argument.
That people use std::tuple for some of its processing aspects for
>> Are you certain that making constexpr overloads of such algorithms
>> like all_of etc is better than addressing the real issue, meaning the
>> lack of first class support for the fundamentals allowing such
>> constructs? Shouldn't these things be considered eventually by
>> expanding <type_traits> to boost::mpl territory?
>>
> We already have tuple_element and tuple_size.
According to the wishes of the committee in currently active EWG#30, you
cannot defend such argument. You also validated my own argument in your
previous paragraph.
>> Seems more like another popular substitute by hasty inspiration than
>> a solution by design.
>>
> bool all_of( std::initializer_list< bool > ) is simple and obvious,
> does that make it "hasty"? I happen to do a lot of metaprogramming,
> but the function isn't specific to metaprogramming at all.
>
> Adding a new core language construct for type lists when we already
> have all the right machinery, and plenty of legacy code already works
> without, sounds like over-specific optimization for niche uses at the
> expense of current practice. Impeding progress on unrelated issues for
> the sake of increasing pressure to adopt a specific direction on one
> issue is dirty politics.
Nobody cares of any adoption of any feature; /*correctness is not about
adoption but about proving "you" don't follow "your own" rules*/. It is
about pointing out that certain practices are not based on technical
grounds and that everybody plays with different cards while saying they
are on the same game. That is at least hypocritical and adulating the
committee over such happenstances is the worst service one can do to C++
as a language.
>
> On 2014--09--03, at 2:29 AM, George Makrydakis <irrequietus@gmail.com
> <mailto:irrequietus@gmail.com>> wrote:
>>
>> The issue is not static if alone. The committee does not have a real
>> argument against compile time evaluation. Just politics.
>>
> In practice the approaches to metaprogramming are more divergent than
> to usual programming, for many reasons:
>
> 1. It feels different and unfamiliar, so beginners are tempted to
> throw knowledge out the window and "just hack it."
> 2. Metaprogramming is more tractable without side effects, so
> imperative programming tends to get excluded. This was true even in
> macro preprocessor days. This is the real reason static_if will never
> happen.
> 3. Implementations have various quirks, leading to numerous and
> divergent superstitious workarounds. I still see new code using
> typedef char yes[2]; sizeof sfinae_test( blah ) == sizeof (yes). This
> is just an illustrative example, but distraction and circumlocution
> have hindered the evolutionary development of C++ best practices.
1) The Stroustrupian beginner argument is inexplicable and inapplicable
since such uses of C++ are not for beginners, but are requested by all
serious users of C++ to the point of having active EWG issues. Beginners
want to "write stuff up fast" and that is why they use languages other
than C++ for the most part, with wider library and language feature
support. C++ is for people who are supposed to be aware of what they are
doing.
2) Template metaprogramming can be functionally characterized as "a
pure, non-strict, untyped functional language with pattern matching",
see
http://bannalia.blogspot.gr/2008/05/functional-characterization-of-c.html for
example. In that sense, if you are making an imperative vs functional
kind of argument, that is lost to begin with by decades of computer
science research you can find in any good library.
3) I agree about the essence of this point very much. The problem is
that instead of fixing template metaprogramming to make it easier to
work with, we got constexpr metaprogramming (which is about playing with
values and not types unless you clutter the declarative parameter list
with decltype enclosures) and - arguably - concepts, which are nothing
more than sfinae shorthands instead of the glorious typeclass (see
haskell) character they would have expressed. We would not have a need
for distraction and circumlocution anymore.
The funny thing is that the semantics of concepts with variadics depend
upon pack expansion rules, so to the dismay of people who do not want
this, template metaprogramming techniques can and will be applied to
either fix concept lacunae or get rid of them altogether in meaningful
code. Concepts don't have generative features themselves, they are just
shorthands used for twisting pattern matching through sfinae hacks for
"error reporting". They are the direct sequence of C++'s design adoption
of latent typing and lack of proper bounded polymorphism. You can search
the bibliography on how *_/monads/_* in C++ template metaprogramming can
be used to produce more meaningful errors during compilation than
concepts will ever be able to in their current design (/unless in the
end they are turned into endofunctors themselves.../). But since
concepts the poster child of the EWG and by birthright they are used as
the reflex reaction to anything that shows how incomplete they are, we
have to put up with them. I am not saying that they are not a good
thing, I am saying that they are used as an utopic panacea by certain
enthousiastic experts. They are not.
I think that I have made the point of where this is getting to.
>
> "Politics" are inevitable. /Good/ politics involves not only
> consensus, but the modesty to limit eternal commitments to judgments
> of absolute certainty. High-level metaprogramming in general, not only
> C++, is too new to expect consensus nor certainty about what is
> necessary or so harmful as to be useless.
>
"Consensus" of people not following their own procedural rules is
another terminological abuse, especially when no votes are casted and
the gist of specific work is redelegated to an internal party while the
original one is given a misguiding library implementation. It is that
conflict that says "error" if honest, worse if not. The problem is the
attitude, not result. One cares little about any result from people who
prove themselves ill-equiped to claim to be of the standard they are.
Proofs by construction are superior to inexplicable and mockery of
consensus procedures.
Inconvenient truths are politically incorrect but that is the problem of
the people who are involved in them. You are implying some sort of
indistinction between ethics and politics that has been proven
dangerously fallacious since the times of Macchiavelli. And then there
is the fairytale of the naked king.
Good discussion as always David.
George
--
---
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/.
--------------000409030109010902030008
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 09/03/2014 05:36 AM, David Krauss
wrote:<br>
</div>
<blockquote
cite="mid:BBB9AFB8-CE7A-4B58-AA64-B0D5EC265DD5@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<div>On 2014–09–03, at 12:50 AM, George Makrydakis <<a
moz-do-not-send="true" href="mailto:irrequietus@gmail.com">irrequietus@gmail.com</a>>
wrote:</div>
<blockquote type="cite">
<p dir="ltr">The tuple solution works because you are using
std::tuple as a boost::mpl::vector substitute and
implementing catamorphisms over packs through "tuple
processing" naming them differently from what they
substantially are.</p>
</blockquote>
<div>Packs are neither tuples (fixed size, unlike elements) nor
vectors (fixed size, like elements), they are lists (variable
size, like elements) or perhaps queues, since insertion and
removal occur at either end.</div>
</div>
</blockquote>
<br>
Incorrect; parameter packs behave like product types and their way
of processing head-to-list is what is revealing of their "tuple"
nature. Are they not an n-ordered sequence of parameter types? Are
tuples in their mathematical sense modelled as nested ordered pairs?
See an analysis of the behavior of parameter packs at <a
href="http://ecn.channel9.msdn.com/events/GoingNative12/GN12VariadicTemplatesAreFunadic.pdf">http://ecn.channel9.msdn.com/events/GoingNative12/GN12VariadicTemplatesAreFunadic.pdf</a>.
For the rest google is your friend. Take note that "tuple" without
an std:: infront of it does not refer to a std::tuple, but to the
notion std::tuple is actually implementing (as well as others like
it).<br>
<br>
The std::tuple tuple becomes of fixed size once you instantiate the
template. But per se, you use it in a context where it is fed a
parameter pack, whose size is determined in instantiation. Its
template parameter list as a class template in serious C++11
implementations, <i><b>is using itself the pack</b></i> which is
the fundamental concept of what we are referring to type-wise. And
it is not a secret that template meta-programmers (ab)use the
std::tuple class template and the std::get<N> over it when
they are trying do some pretty trivial stuff instead of depending
upon boost::mpl::vector. Also, you should remember that
boost::mpl::deque as per <a
href="http://www.boost.org/doc/libs/1_56_0/boost/mpl/deque.hpp">http://www.boost.org/doc/libs/1_56_0/boost/mpl/deque.hpp</a>
is that they are in the end based on boost::mpl::vector, which
itself in any serious C++11 implementation depends upon the concept
of a pack.<br>
<br>
What you are describing as "insertion and removal occur at either
end" was actually already happening with boost::mpl::vectors, that
are easier to implement now that packs are available because packs
are the fundamental construct here. Even boost::mpl::deque is
actually using boost::mpl::vector, so yes, terminology is something
severely impaired for the vast majority of people citing such
sources.<br>
<br>
Parameter packs, under the condition that their use in a template
parameter list is made within a deducible context (remember multiple
parameter packs?) can allow both catamorphisms and anamorphisms
(left and right folds and unfolds, referring to your "ends"
processing) and structure preserving transformations (for example
mapping). See <a
href="http://en.cppreference.com/w/cpp/language/parameter_pack#Pack_expansion">http://en.cppreference.com/w/cpp/language/parameter_pack#Pack_expansion</a>
currently for some creative uses of pack expansion.<br>
<br>
<blockquote
cite="mid:BBB9AFB8-CE7A-4B58-AA64-B0D5EC265DD5@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>Anyway, I don’t think taxonomy is a good guiding force.</div>
</div>
</blockquote>
<br>
In the sense that C++ has the term "functor" for something that has
nothing to do with the actual way functor is used in category
theory, I would agree. C++ terminology is working against itself
because it has to cater for people who willfully ignore established
terminology preceding C++ itself. As are other things. So, yes,
taxonomy is not helping such arguments because it is vaporizing
their substance.<br>
<br>
<blockquote
cite="mid:BBB9AFB8-CE7A-4B58-AA64-B0D5EC265DD5@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>Template-ids work perfectly well as metadata elements.
Naming a class template specialization such as <font
face="Courier">tuple<void></font> does not cause an
instantiation, so there are no semantic requirements on the
types in the list. Type-list operations can invariably be
implemented without instantiating the type-list class.</div>
<div><br>
</div>
<div>Metacomputation often generates runtime types, and using <font
face="Courier">tuple</font> as the basis of computation
saves a rebind operation. For a program which generates many
types, that may halve the metadata the compiler needs to deal
with.</div>
</div>
</blockquote>
<br>
First, you are overusing the term meta- to the demise of the
argument. That people use std::tuple for some of its processing
aspects for<br>
<br>
<blockquote
cite="mid:BBB9AFB8-CE7A-4B58-AA64-B0D5EC265DD5@gmail.com"
type="cite">
<div>
<blockquote type="cite">
<p dir="ltr">Are you certain that making constexpr overloads
of such algorithms like all_of etc is better than addressing
the real issue, meaning the lack of first class support for
the fundamentals allowing such constructs? Shouldn't these
things be considered eventually by expanding
<type_traits> to boost::mpl territory?</p>
</blockquote>
<div>We already have <font face="Courier">tuple_element</font> and
<font face="Courier">tuple_size</font>.</div>
</div>
</blockquote>
<br>
According to the wishes of the committee in currently active EWG#30,
you cannot defend such argument. You also validated my own argument
in your previous paragraph.<br>
<br>
<blockquote
cite="mid:BBB9AFB8-CE7A-4B58-AA64-B0D5EC265DD5@gmail.com"
type="cite">
<div>
<blockquote type="cite">
<p dir="ltr"> Seems more like another popular substitute by
hasty inspiration than a solution by design.</p>
</blockquote>
</div>
<div><font face="Courier">bool all_of( std::initializer_list<
bool > )</font> is simple and obvious, does that make it
“hasty”? I happen to do a lot of metaprogramming, but the
function isn’t specific to metaprogramming at all.</div>
<div><br>
</div>
<div>Adding a new core language construct for type lists when we
already have all the right machinery, and plenty of legacy code
already works without, sounds like over-specific optimization
for niche uses at the expense of current practice. Impeding
progress on unrelated issues for the sake of increasing pressure
to adopt a specific direction on one issue is dirty politics.</div>
</blockquote>
<br>
Nobody cares of any adoption of any feature; <i><b>correctness is
not about adoption but about proving "you" don't follow "your
own" rules</b></i>. It is about pointing out that certain
practices are not based on technical grounds and that everybody
plays with different cards while saying they are on the same game.
That is at least hypocritical and adulating the committee over such
happenstances is the worst service one can do to C++ as a language.<br>
<br>
<br>
<br>
<blockquote
cite="mid:BBB9AFB8-CE7A-4B58-AA64-B0D5EC265DD5@gmail.com"
type="cite">
<div><br>
</div>
<div>
<div>On 2014–09–03, at 2:29 AM, George Makrydakis <<a
moz-do-not-send="true" href="mailto:irrequietus@gmail.com">irrequietus@gmail.com</a>>
wrote:</div>
<blockquote type="cite">
<p dir="ltr">The issue is not static if alone. The committee
does not have a real argument against compile time
evaluation. Just politics.</p>
</blockquote>
</div>
<div>In practice the approaches to metaprogramming are more
divergent than to usual programming, for many reasons:</div>
<div><br>
</div>
<div>1. It feels different and unfamiliar, so beginners are
tempted to throw knowledge out the window and “just hack it.”</div>
<div>2. Metaprogramming is more tractable without side effects, so
imperative programming tends to get excluded. This was true even
in macro preprocessor days. This is the real reason <font
face="Courier">static_if</font> will never happen.</div>
<div>3. Implementations have various quirks, leading to numerous
and divergent superstitious workarounds. I still see new code
using <font face="Courier">typedef char yes[2]; sizeof
sfinae_test( blah ) == sizeof (yes)</font>. This is just an
illustrative example, but distraction and circumlocution have
hindered the evolutionary development of C++ best practices.</div>
</blockquote>
<br>
1) The Stroustrupian beginner argument is inexplicable and
inapplicable since such uses of C++ are not for beginners, but are
requested by all serious users of C++ to the point of having active
EWG issues. Beginners want to "write stuff up fast" and that is why
they use languages other than C++ for the most part, with wider
library and language feature support. C++ is for people who are
supposed to be aware of what they are doing.<br>
<br>
2) Template metaprogramming can be functionally characterized as "a
pure, non-strict, untyped functional language with pattern
matching", see <a
href="http://bannalia.blogspot.gr/2008/05/functional-characterization-of-c.html">http://bannalia.blogspot.gr/2008/05/functional-characterization-of-c.html</a>
for example. In that sense, if you are making an imperative vs
functional kind of argument, that is lost to begin with by decades
of computer science research you can find in any good library.<br>
<br>
3) I agree about the essence of this point very much. The problem is
that instead of fixing template metaprogramming to make it easier to
work with, we got constexpr metaprogramming (which is about playing
with values and not types unless you clutter the declarative
parameter list with decltype enclosures) and - arguably - concepts,
which are nothing more than sfinae shorthands instead of the
glorious typeclass (see haskell) character they would have
expressed. We would not have a need for distraction and
circumlocution anymore.<br>
<br>
The funny thing is that the semantics of concepts with variadics
depend upon pack expansion rules, so to the dismay of people who do
not want this, template metaprogramming techniques can and will be
applied to either fix concept lacunae or get rid of them altogether
in meaningful code. Concepts don't have generative features
themselves, they are just shorthands used for twisting pattern
matching through sfinae hacks for "error reporting". They are the
direct sequence of C++'s design adoption of latent typing and lack
of proper bounded polymorphism. You can search the bibliography on
how <b><u><i>monads</i></u></b> in C++ template metaprogramming can
be used to produce more meaningful errors during compilation than
concepts will ever be able to in their current design (<i>unless in
the end they are turned into endofunctors themselves...</i>). But
since concepts the poster child of the EWG and by birthright they
are used as the reflex reaction to anything that shows how
incomplete they are, we have to put up with them. I am not saying
that they are not a good thing, I am saying that they are used as an
utopic panacea by certain enthousiastic experts. They are not.<br>
<br>
I think that I have made the point of where this is getting to.<br>
<br>
<blockquote
cite="mid:BBB9AFB8-CE7A-4B58-AA64-B0D5EC265DD5@gmail.com"
type="cite">
<div><br>
</div>
<div>“Politics” are inevitable. <i>Good</i> politics involves not
only consensus, but the modesty to limit eternal commitments to
judgments of absolute certainty. High-level metaprogramming in
general, not only C++, is too new to expect consensus nor
certainty about what is necessary or so harmful as to be
useless.</div>
<br>
</blockquote>
<br>
"Consensus" of people not following their own procedural rules is
another terminological abuse, especially when no votes are casted
and the gist of specific work is redelegated to an internal party
while the original one is given a misguiding library implementation.
It is that conflict that says "error" if honest, worse if not. The
problem is the attitude, not result. One cares little about any
result from people who prove themselves ill-equiped to claim to be
of the standard they are. Proofs by construction are superior to
inexplicable and mockery of consensus procedures.<br>
<br>
Inconvenient truths are politically incorrect but that is the
problem of the people who are involved in them. You are implying
some sort of indistinction between ethics and politics that has been
proven dangerously fallacious since the times of Macchiavelli. And
then there is the fairytale of the naked king.<br>
<br>
Good discussion as always David.<br>
<br>
George<br>
<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------000409030109010902030008--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 3 Sep 2014 17:24:58 +0800
Raw View
--Apple-Mail=_24DB0E7B-6582-4F2A-A4AC-DE8A6E6FD71C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-09-03, at 4:37 PM, George Makrydakis <irrequietus@gmail.com> wrote:
> According to the wishes of the committee in currently active EWG#30, you =
cannot defend such argument. You also validated my own argument in your pre=
vious paragraph.
What argument? I see a lot of discussion about taxonomy. You left a paragra=
ph incomplete.
EWG30 says:
> There are lots of very basic manipulations that are either really hard o=
r impossible to do with argument packs unless you use something that causes=
a big recursive template instantiation, which is expensive at compile-time=
and can cause bad error messages. I want to be able to index argument pack=
s with integral constant expressions, "take" or "drop" the first N elements=
of the pack, etc.=20
>=20
This does not express a prejudice against using std::tuple as a type-list n=
or commit to a new core language facility. The immediately linked proposals=
don't describe any new core facilities either.
My main argument is simply that std::tuple is a better choice for EWG30-sty=
le operations than a dedicated std::packer class, as mentioned in N4115, or=
something heavier like mpl::vector. This subject perhaps deserves a paper.
Also, I believe that the gain of avoiding wrapping pack expansions as tuple=
<T...> isn't worth the cost of a new core language feature. However, this i=
sn't as concrete and I suspect such a feature will eventually happen anyway=
.. It could be well and good, as long as there are other concomitant gains.
However, this really has no bearing on the proposal in this thread, since a=
s mentioned it's not really a metaprogramming facility but just a generic f=
acility with as much application in metaprogramming as anywhere else a brac=
ed-init-list of Booleans might arise.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_24DB0E7B-6582-4F2A-A4AC-DE8A6E6FD71C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09–03, at 4:37 PM, George Makrydakis <<a href=3D"mailto:irre=
quietus@gmail.com">irrequietus@gmail.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><span style=3D"font-fam=
ily: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
background-color: rgb(255, 255, 255); float: none; display: inline !import=
ant;">According to the wishes of the committee in currently active EWG#30, =
you cannot defend such argument. You also validated my own argument in your=
previous paragraph.</span><br style=3D"font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant: normal; font-weight: normal; letter=
-spacing: normal; line-height: normal; orphans: auto; text-align: start; te=
xt-indent: 0px; text-transform: none; white-space: normal; widows: auto; wo=
rd-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote></div><br><d=
iv>What argument? I see a lot of discussion about taxonomy. You left a para=
graph incomplete.</div><div><br></div><div>EWG30 says:</div><div><blockquot=
e type=3D"cite"><span class=3D"msg"><p> There are lots of very basic m=
anipulations that are either really hard
or impossible to do with argument packs unless you use something that
causes a big recursive template instantiation, which is expensive at
compile-time and can cause bad error messages. I want to be able to
index argument packs with integral constant expressions, "take" or
"drop" the first N elements of the pack, etc. </p></span></blockquote>=
</div><div>This does not express a prejudice against using <font face=3D"Co=
urier">std::tuple</font> as a type-list nor commit to a new core language f=
acility. The immediately linked proposals don’t describe any new core=
facilities either.</div><div><br></div><div>My main argument is simply tha=
t <font face=3D"Courier">std::tuple</font> is a better choice for EWG30-sty=
le operations than a dedicated <font face=3D"Courier">std::packer</font> cl=
ass, as mentioned in N4115, or something heavier like <font face=3D"Co=
urier">mpl::vector</font>. This subject perhaps deserves a paper.</div><div=
><br></div><div>Also, I believe that the gain of avoiding wrapping pack exp=
ansions as <font face=3D"Courier">tuple<T...></font> isn’t=
worth the cost of a new core language feature. However, this isn’t a=
s concrete and I suspect such a feature will eventually happen anyway. It c=
ould be well and good, as long as there are other concomitant gains.</div><=
div><br></div><div>However, this really has no bearing on the proposal in t=
his thread, since as mentioned it’s not really a metaprogramming faci=
lity but just a generic facility with as much application in metaprogrammin=
g as anywhere else a braced-init-list of Booleans might arise.</div><div><b=
r></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_24DB0E7B-6582-4F2A-A4AC-DE8A6E6FD71C--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 3 Sep 2014 11:16:06 -0400
Raw View
--001a113467f41507ef05022ab7ca
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 2, 2014 at 7:18 PM, George Makrydakis <irrequietus@gmail.com>
wrote:
> On September 2, 2014 11:37:47 PM EEST, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>
>> I think what's misguiding is all these unsubstantiated claims about
>> "social non-arguments",
>> "sponsored lobbying" and "bogus arguments".
>>
>
> C++ needs volunteers, but it seems that certain people will have problems
> with this. I am just informing a new potential author on what to expect,
> given that you tried to motivate another person
<snip>
George
>
>
I may be wrong, but I get the impression that your experience with the
committee is dominated by one large, unfortunate, experience or "data
point". Before extrapolating that into conclusions about the committee, I
would suggest many additional data points are required.
Tony
--
---
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/.
--001a113467f41507ef05022ab7ca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Sep 2, 2014 at 7:18 PM, George Makrydakis <span dir=3D"ltr"=
><<a href=3D"mailto:irrequietus@gmail.com" target=3D"_blank">irrequietus=
@gmail.com</a>></span> wrote:<br>
<div><br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div class=3D"">
On September 2, 2014 11:37:47 PM EEST, Ville Voutilainen <<a href=3D"mai=
lto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.=
com</a>> wrote:<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">
<br>
I think what's misguiding is all these unsubstantiated claims about<br>
"social non-arguments",<br>
"sponsored lobbying" and "bogus arguments".<br>
</blockquote>
<br></div>
C++ needs volunteers, but it seems that certain people will have problems w=
ith this. I am just informing a new potential author on what to expect, giv=
en that you tried to motivate another person </blockquote><div><br><snip=
><br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"=
"><font color=3D"#888888">
George</font></span><div class=3D""><div class=3D"h5"><br></div></div></blo=
ckquote></div><br></div><div class=3D"gmail_extra">I may be wrong, but I ge=
t the impression that your experience with the committee is dominated by on=
e large, unfortunate, experience or "data point".=C2=A0 Before ex=
trapolating that into conclusions about the committee, I would suggest many=
additional data points are required.<br>
<br>Tony<br></div><div class=3D"gmail_extra"><br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a113467f41507ef05022ab7ca--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Wed, 03 Sep 2014 20:48:42 +0300
Raw View
This is a multi-part message in MIME format.
--------------020105000408040902010605
Content-Type: text/plain; charset=UTF-8; format=flowed
On 09/03/2014 06:16 PM, Tony V E wrote:
> I may be wrong, but I get the impression that your experience with the
> committee is dominated by one large, unfortunate, experience or "data
> point". Before extrapolating that into conclusions about the
> committee, I would suggest many additional data points are required.
>
> Tony
>
I will give you the *whole* story, with all respect to David since I
would not like to hijack the thread into sheer offtopicness, but you
asked me about it here. Here goes.
Initially, after motivation by Ville, I put together an incomplete draft
for accessing parameters within a parameter pack either individually by
ordinal index or over an interval of indexes / sizes describing a pack;
it was also possible to have some notation accompanying that pack that
would give us the possibility to detect whether the pack was made out of
a pattern of types.
These requirements led to a few interesting effects boosting template
constructs as to require less class template partial specializations /
function template overloads (the "vertical pattern" boilerplate) and
shorter parameter lists where type sequence patterns / complex
constructs avoiding sfinae were possible. The important thing to note is
that there are a series of active EWG issues, most of all EWG#30, that
could be addressed in a unified manner if the EWG did conclude to a
language feature implementation for them.
Ville forwarded two N-less drafts (one of them mine) that were not in
the pre-meeting mailing list, for two things that were fundamentally
different in their premise but related to parameter packs to the EWG. He
did invite me without any guarantees and I thought that it would have
been a nice way to know some of the brilliant minds behind what makes
C++ tick. I did not go there to present a proposal. I did not go there
expecting to have to win any argument. I went there with the intention
of discussing some preliminary work with people who by historical right,
*_/should/_* know this language better than I.
After arriving early morning /*Wednesday*/ and while trying to
understand what was going on, with the intervention of Ville (whom I
thank for the invitation), I am told that at some "unknown point in time
after we finish, we can discuss this!". I worked on my presentation
slides the same night.
/*Thursday*/ comes. Another N-less paper related to packs was discussed
into a specific time slot and despite its ambiguities even the EWG
missed it got "encouraged" by a specific and inter and intrarelated
block of people. Instead, /I had to remind the people involved in this
"loose" program three times/ that if they /indeed/ wanted to discuss
some preliminary work, I was there just for that. In the end, I was
given a slot a few minutes before evening break.
Starting the presentation, I specified that this was preliminary work,
but it addressed several issues that currently merit attention. After
about 9 minutes of presentation time, /with a series of rows of people
sleeping and munching away before I even started discussing my
preliminary work/, three arguments were raised: "template
metaprogramming scares people away", "it would strain the compiler",
"let's do it with concepts". All of these are not only non-arguments,
but we are kind of really getting away from the picture by pingballing
concepts in: they lack generative features and you cannot use them for
accessing sub-packs or individual parameters within a pack.
In their attempt to demonstrate authority while being politically
correct, they tried to get away from a difficult situation by pulling
out the card of a "library reccomendation" since this is something that
would interest "template metaprogrammers" only. Understanding of their
embarassing tiredness because sessions started at 08:00-08:30 and
unpreparedness (non pre-meeting mailing), I announce in the mailing list
that I'd go forward with a library in order to play a little bit more
with this. I already knew that this was undoable without heavy
preprocessor and template metaprogramming but that was not the issue.
Take note that no votes are casted, this is an N-less incomplete draft
and not a proposal; but it could be in one of the following meetings.
/*Friday*/. They start discussing active issues list and EWG#30 comes
up. Exactly one of the issues I rapidly discussed about during the
presentation. It is then decided that _/after 2 years almost/_ that this
was pending there, they should do something about it. And they start
looking among them on what to do about it. One of the people who said
"this would strain the compiler" for my preliminary work that directly
addresses this, "express interest in drafting" about an issue where my
work offers a fit.
Unsurprisingly, that other N-less draft that got its early slot and was
obviously supported by a specific block of people despite its problems,
gets "encouragement" to work on this and "merge" towards the goal of
addressing EWG#30. When I talked to the people involved in this, it was
visible that they were particularly strained in giving an answer as to
/why my very related work was ignored since they went into disproving
the non-arguments they made the previous day.//
//*Saturday.*/ I go to the EWG and I ask for a hearing once the issues
list gets active. Ville is presiding and /because he has understood what
happened/ he concedes to it. I get the same non-arguments again but with
even more difficulty by them because ... EWG#30, first and foremost. One
person tries to become arbiter of the situation and says "what about
presenting the complete paper?" as a resolution of the issue. Yet, none
of this is written in the transcriptions of the early Saturday meeting.
Unsurprising.
The people who were easily and without real technical arguments
dismissive of my preliminary work are the ones who are trying to
implement it. Draw your own conclusions. I am simply continuing to this
work on the premises I started with in
https://github.com/irrequietus/atpp, should anybody care. As for Ville,
well, I think that he is an honest man. Infact he will "eventually
amend" EWG#30 to reflect these things, as he said in this mailing list.
I will be given my N-number once I ask for it (upon completion of my work).
My disgust towards this C++ EWG practice is justified; more so if people
like Herb Sutter voiced their concern that the irregularity of the
procedure with which such preliminary work was discussed was
problematic. The aftermath of my experience is that from now on, groups
like the EWG will be more respectful of their own procedures,
safeguarding newcoming authors from the impression that since they are
not backed by coworkers in /*g*/reat, /*g*/reat companies, "these things
happen". I still think that any serious C++ programmer should visit one
of these meetings once; disillusionment about certain people is
important for the community at large.
It is not that they are not aware that this is a problem they created,
it is that they don't know how to deal with it other than waiting for
the little kid to stop saying that the naked king is naked.
George
--
---
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/.
--------------020105000408040902010605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<br>
<div class=3D"moz-cite-prefix">On 09/03/2014 06:16 PM, Tony V E wrote:<=
/div>
<blockquote
cite=3D"mid:CAOHCbitVbTLnPBiMVB6HwzZc5cfN0+aDDyJbOVFwwdnTzbvUvQ@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">I may be wrong, but I get the impression that your
experience with the committee is dominated by one large,
unfortunate, experience or "data point".=C2=A0 Before extrapolating
that into conclusions about the committee, I would suggest many
additional data points are required.<br>
<div class=3D"gmail_extra">
<br>
Tony<br>
</div>
<div class=3D"gmail_extra"><br>
</div>
</div>
</blockquote>
I will give you the <b>whole</b> story, with all respect to David
since I would not like to hijack the thread into sheer offtopicness,
but you asked me about it here. Here goes.<br>
<br>
Initially, after motivation by Ville, I put together an incomplete
draft for accessing parameters within a parameter pack either
individually by ordinal index or over an interval of indexes / sizes
describing a pack; it was also possible to have some notation
accompanying that pack that would give us the possibility to detect
whether the pack was made out of a pattern of types.<br>
<br>
These requirements led to a few interesting effects boosting
template constructs as to require less class template partial
specializations / function template overloads (the "vertical
pattern" boilerplate) and shorter parameter lists where type
sequence patterns / complex constructs avoiding sfinae were
possible. The important thing to note is that there are a series of
active EWG issues, most of all EWG#30, that could be addressed in a
unified manner if the EWG did conclude to a language feature
implementation for them.<br>
<br>
Ville forwarded two N-less drafts (one of them mine) that were not
in the pre-meeting mailing list, for two things that were
fundamentally different in their premise but related to parameter
packs to the EWG. He did invite me without any guarantees and I
thought that it would have been a nice way to know some of the
brilliant minds behind what makes C++ tick. I did not go there to
present a proposal. I did not go there expecting to have to win any
argument. I went there with the intention of discussing some
preliminary work with people who by historical right, <b><u><i>should</=
i></u></b>
know this language better than I.<br>
<br>
After arriving early morning <i><b>Wednesday</b></i> and while
trying to understand what was going on, with the intervention of
Ville (whom I thank for the invitation), I am told that at some
"unknown point in time after we finish, we can discuss this!". I
worked on my presentation slides the same night.<br>
<br>
<i><b>Thursday</b></i> comes. Another N-less paper related to packs
was discussed into a specific time slot and despite its ambiguities
even the EWG missed it got "encouraged" by a specific and inter and
intrarelated block of people. Instead, <i>I had to remind the people
involved in this "loose" program three times</i> that if they <i>inde=
ed</i>
wanted to discuss some preliminary work, I was there just for that.
In the end, I was given a slot a few minutes before evening break.<br>
<br>
Starting the presentation, I specified that this was preliminary
work, but it addressed several issues that currently merit
attention. After about 9 minutes of presentation time, <i>with a
series of rows of people sleeping and munching away before I even
started discussing my preliminary work</i>, three arguments were
raised: "template metaprogramming scares people away", "it would
strain the compiler", "let's do it with concepts". All of these are
not only non-arguments, but we are kind of really getting away from
the picture by pingballing concepts in: they lack generative
features and you cannot use them for accessing sub-packs or
individual parameters within a pack.<br>
<br>
In their attempt to demonstrate authority while being politically
correct, they tried to get away from a difficult situation by
pulling out the card of a "library reccomendation" since this is
something that would interest "template metaprogrammers" only.
Understanding of their embarassing tiredness because sessions
started at 08:00-08:30 and unpreparedness (non pre-meeting mailing),
I announce in the mailing list that I'd go forward with a library in
order to play a little bit more with this. I already knew that this
was undoable without heavy preprocessor and template metaprogramming
but that was not the issue.<br>
<br>
Take note that no votes are casted, this is an N-less incomplete
draft and not a proposal; but it could be in one of the following
meetings.<br>
<br>
<i><b>Friday</b></i>. They start discussing active issues list and
EWG#30 comes up. Exactly one of the issues I rapidly discussed about
during the presentation. It is then decided that <u><i>after 2
years almost</i></u> that this was pending there, they should do
something about it. And they start looking among them on what to do
about it. One of the people who said "this would strain the
compiler" for my preliminary work that directly addresses this,
"express interest in drafting" about an issue where my work offers a
fit.<br>
<br>
Unsurprisingly, that other N-less draft that got its early slot and
was obviously supported by a specific block of people despite its
problems, gets "encouragement" to work on this and "merge" towards
the goal of addressing EWG#30. When I talked to the people involved
in this, it was visible that they were particularly strained in
giving an answer as to <i>why my very related work was ignored
since they went into disproving the non-arguments they made the
previous day.</i><i><br>
<br>
</i><i><b>Saturday.</b></i> I go to the EWG and I ask for a hearing
once the issues list gets active. Ville is presiding and <i>because
he has understood what happened</i> he concedes to it. I get the
same non-arguments again but with even more difficulty by them
because ... EWG#30, first and foremost. One person tries to become
arbiter of the situation and says "what about presenting the
complete paper?" as a resolution of the issue. Yet, none of this is
written in the transcriptions of the early Saturday meeting.
Unsurprising.<br>
<br>
The people who were easily and without real technical arguments
dismissive of my preliminary work are the ones who are trying to
implement it. Draw your own conclusions. I am simply continuing to
this work on the premises I started with in <a
href=3D"https://github.com/irrequietus/atpp">https://github.com/irreq=
uietus/atpp</a>,
should anybody care. As for Ville, well, I think that he is an
honest man. Infact he will "eventually amend" EWG#30 to reflect
these things, as he said in this mailing list. I will be given my
N-number once I ask for it (upon completion of my work).<br>
<br>
My disgust towards this C++ EWG practice is justified; more so if
people like Herb Sutter voiced their concern that the irregularity
of the procedure with which such preliminary work was discussed was
problematic. The aftermath of my experience is that from now on,
groups like the EWG will be more respectful of their own procedures,
safeguarding newcoming authors from the impression that since they
are not backed by coworkers in <i><b>g</b></i>reat, <i><b>g</b></i>reat
companies, "these things happen". I still think that any serious C++
programmer should visit one of these meetings once; disillusionment
about certain people is important for the community at large.<br>
<br>
It is not that they are not aware that this is a problem they
created, it is that they don't know how to deal with it other than
waiting for the little kid to stop saying that the naked king is
naked.<br>
<br>
George<br>
<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------020105000408040902010605--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Wed, 03 Sep 2014 21:03:53 +0300
Raw View
This is a multi-part message in MIME format.
--------------080205020800030702010206
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 09/03/2014 12:24 PM, David Krauss wrote:
> What argument? I see a lot of discussion about taxonomy. You left a
> paragraph incomplete.
>
Ignoring research done in the last 4 - 5 decades of computer science
claiming it is taxonomy, is the practical argument certain C++ users
deploy when they are unaware of the meaning of said research. I know you
are better than this David, I seriously do. Read the entire post again,
will not repeat what I already said.
> EWG30 says:
>>
>> There are lots of very basic manipulations that are either really
>> hard or impossible to do with argument packs unless you use something
>> that causes a big recursive template instantiation, which is
>> expensive at compile-time and can cause bad error messages. I want to
>> be able to index argument packs with integral constant expressions,
>> "take" or "drop" the first N elements of the pack, etc.
>>
> This does not express a prejudice against using std::tuple as a
> type-list nor commit to a new core language facility. The immediately
> linked proposals don't describe any new core facilities either.
>
> My main argument is simply that std::tuple is a better choice for
> EWG30-style operations than a dedicated std::packer class, as
> mentioned in N4115, or something heavier like mpl::vector. This
> subject perhaps deserves a paper.
That is what people are already using in order to avoid including
boost::mpl::vector, up to a point. The result is an ugly hack. And any
library based solution like this, would only resort to increasing the
number of recursive template instantiations and function template
overloads to do simple parameter access. This issue is about /removing
the need for using such solutions, advancing pack processing to a whole
new level./
>
> Also, I believe that the gain of avoiding wrapping pack expansions as
> tuple<T...> isn't worth the cost of a new core language feature.
> However, this isn't as concrete and I suspect such a feature will
> eventually happen anyway. It could be well and good, as long as there
> are other concomitant gains.
>
> However, this really has no bearing on the proposal in this thread,
> since as mentioned it's not really a metaprogramming facility but just
> a generic facility with as much application in metaprogramming as
> anywhere else a braced-init-list of Booleans might arise.
>
Resolution of EWG#30 as a language feature makes the template parameter
list (including any packs declared in a deducible context within it)
into a fundamental computational construct that has no need of the
constexpr overloads, since non-type parameter packs can expand into a
list of values of the same type. Because of the rules of pack expansion,
implementing catamorphisms, anamorphisms and structure preserving
transformations is quite easy.
At that point it is more a question of style, since type and
template-type packs have the advantage of expanding to lists of type and
template-template parameters and not just lists of values.
Variadics are into functional territory, stop thinking imperatively
because that does not apply there.
Other than that, I think that constexpr metaprogramming is not a bad
idea for certain things.
--
---
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/.
--------------080205020800030702010206
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 09/03/2014 12:24 PM, David Krauss
wrote:</div>
<blockquote
cite="mid:D5D53925-CF60-4E87-9447-A2DB2F1F532E@gmail.com"
type="cite">
<div>What argument? I see a lot of discussion about taxonomy. You
left a paragraph incomplete.</div>
<div><br>
</div>
</blockquote>
<br>
Ignoring research done in the last 4 - 5 decades of computer science
claiming it is taxonomy, is the practical argument certain C++ users
deploy when they are unaware of the meaning of said research. I know
you are better than this David, I seriously do. Read the entire post
again, will not repeat what I already said.<br>
<br>
<blockquote
cite="mid:D5D53925-CF60-4E87-9447-A2DB2F1F532E@gmail.com"
type="cite">
<div>EWG30 says:</div>
<div>
<blockquote type="cite"><span class="msg">
<p> There are lots of very basic manipulations that are
either really hard
or impossible to do with argument packs unless you use
something that
causes a big recursive template instantiation, which is
expensive at
compile-time and can cause bad error messages. I want to
be able to
index argument packs with integral constant expressions,
"take" or
"drop" the first N elements of the pack, etc. </p>
</span></blockquote>
</div>
<div>This does not express a prejudice against using <font
face="Courier">std::tuple</font> as a type-list nor commit to
a new core language facility. The immediately linked proposals
don’t describe any new core facilities either.</div>
<div><br>
</div>
<div>My main argument is simply that <font face="Courier">std::tuple</font>
is a better choice for EWG30-style operations than a dedicated <font
face="Courier">std::packer</font> class, as mentioned in
N4115, or something heavier like <font face="Courier">mpl::vector</font>.
This subject perhaps deserves a paper.</div>
</blockquote>
<br>
That is what people are already using in order to avoid including
boost::mpl::vector, up to a point. The result is an ugly hack. And
any library based solution like this, would only resort to
increasing the number of recursive template instantiations and
function template overloads to do simple parameter access. This
issue is about <i>removing the need for using such solutions,
advancing pack processing to a whole new level.</i><br>
<br>
<blockquote
cite="mid:D5D53925-CF60-4E87-9447-A2DB2F1F532E@gmail.com"
type="cite">
<div><br>
</div>
<div>Also, I believe that the gain of avoiding wrapping pack
expansions as <font face="Courier">tuple<T...></font>
isn’t worth the cost of a new core language feature. However,
this isn’t as concrete and I suspect such a feature will
eventually happen anyway. It could be well and good, as long as
there are other concomitant gains.</div>
<div><br>
</div>
<div>However, this really has no bearing on the proposal in this
thread, since as mentioned it’s not really a metaprogramming
facility but just a generic facility with as much application in
metaprogramming as anywhere else a braced-init-list of Booleans
might arise.</div>
<div><br>
</div>
</blockquote>
<br>
Resolution of EWG#30 as a language feature makes the template
parameter list (including any packs declared in a deducible context
within it) into a fundamental computational construct that has no
need of the constexpr overloads, since non-type parameter packs can
expand into a list of values of the same type. Because of the rules
of pack expansion, implementing catamorphisms, anamorphisms and
structure preserving transformations is quite easy.<br>
<br>
At that point it is more a question of style, since type and
template-type packs have the advantage of expanding to lists of type
and template-template parameters and not just lists of values.<br>
<br>
Variadics are into functional territory, stop thinking imperatively
because that does not apply there.<br>
<br>
Other than that, I think that constexpr metaprogramming is not a bad
idea for certain things.<br>
<br>
<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------080205020800030702010206--
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Thu, 04 Sep 2014 15:02:16 -0700
Raw View
Richard Smith <richard@metafoo.co.uk> writes:
[...]
| 1) "fold": the AST is rewritten as constant expressions are
| simplified. In some implementations this happens as you parse, in
| others it happens as a separate step. So when you build a + operation
| whose operands are 1 and 1, you end up with an expression "2" and no
| evidence that you ever had a '+'. This also means you can use
| essentially the same code to perform various kinds of optimization.
| 2) Real evaluation: the AST represents the code as written, and a
| separate process walks it and produces a symbolic value from it.
you are making the implicit assumption that all C++ compilers start
doing constexpr fom ASTs :-)
Agree, there is more variations in C++ implementations than meet the eyes.
-- Gaby
--
---
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/.
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Thu, 04 Sep 2014 15:10:40 -0700
Raw View
Rein Halbersma <rhalbersma@gmail.com> writes:
[...]
| The simplest case for dynamic allocation -- support non-placement
| new and delete only, do not allow the end result of a constant
| expression evaluation to refer to dynamically-allocated memory,
| and do not call a replacement global allocation/deallocation
| function -- is completely straightforward in Clang's
| implementation. I can't speak for the complexity that would be
| required in other implementations.
|
|
| Could you give an example of what type of code would be possible /
| hard?
C++ -- following the lead of C -- has the notion of phase distinction
where the elaboration phase of the compiler happens before the linker
phase which happens before the loading phase, which happens before
runtime. You can't assume the actors from the previous phase are
present in the next phase -- in particular the elaborator is long gone
by the time the loader is doing its thing. Consequently, all the
"constants" from the elaboration phase through load-time are carefully
described symbolically -- this is even more glaring when you look at the
sort of (restricted) constant expressions you can use as template
arguments (e.g. making up an address constant out of an integer constant).
If you add dynamic allocation, you need to describe what that means
(e.g. the form of what is a value) through that chain. As far I know,
nobody has presented a thoughtful coherent analysis of the issue and a
solution.
-- Gaby
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Fri, 05 Sep 2014 03:18:05 +0300
Raw View
------Y1131RL31HSSJM8JXQCCNAAMFB0YK1
Content-Type: text/plain; charset=UTF-8
On September 5, 2014 1:10:40 AM EEST, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
>Rein Halbersma <rhalbersma@gmail.com> writes:
>
>[...]
>
>| The simplest case for dynamic allocation -- support non-placement
>| new and delete only, do not allow the end result of a constant
>| expression evaluation to refer to dynamically-allocated memory,
>| and do not call a replacement global allocation/deallocation
>| function -- is completely straightforward in Clang's
>| implementation. I can't speak for the complexity that would be
>| required in other implementations.
>|
>|
>| Could you give an example of what type of code would be possible /
>| hard?
>
....
>If you add dynamic allocation, you need to describe what that means
>(e.g. the form of what is a value) through that chain. As far I know,
>nobody has presented a thoughtful coherent analysis of the issue and a
>solution.
>
That "value" in that case, has to be immutable by the fact that as you said, the actors of the previous phases cannot be assumed to be present in the next one.
Your main problem with the constexpr runtime barrier is that people reason in terms of variables as their "values", instead of (recursive) constexpr expressions dealing with immutable values being consumed during this process.
Thinking about this declarative behavior of constexpr with imperative runtime semantics such as "dynamic allocation" is just wrong and is a reason for confusion. It is not about form, but about immutability.
--
---
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/.
------Y1131RL31HSSJM8JXQCCNAAMFB0YK1
Content-Type: text/html; charset=UTF-8
<p dir="ltr"></p>
<p dir="ltr">On September 5, 2014 1:10:40 AM EEST, Gabriel Dos Reis <gdr@axiomatics.org> wrote:<br>
>Rein Halbersma <rhalbersma@gmail.com> writes:<br>
><br>
>[...]<br>
><br>
>| The simplest case for dynamic allocation -- support non-placement<br>
>| new and delete only, do not allow the end result of a constant<br>
>| expression evaluation to refer to dynamically-allocated memory,<br>
>| and do not call a replacement global allocation/deallocation<br>
>| function -- is completely straightforward in Clang's<br>
>| implementation. I can't speak for the complexity that would be<br>
>| required in other implementations.<br>
>| <br>
>| <br>
>| Could you give an example of what type of code would be possible /<br>
>| hard?<br>
></p>
<p dir="ltr">...</p>
<p dir="ltr">>If you add dynamic allocation, you need to describe what that means<br>
>(e.g. the form of what is a value) through that chain. As far I know,<br>
>nobody has presented a thoughtful coherent analysis of the issue and a<br>
>solution. <br>
></p>
<p dir="ltr">That "value" in that case, has to be immutable by the fact that as you said, the actors of the previous phases cannot be assumed to be present in the next one. <br>
Your main problem with the constexpr runtime barrier is that people reason in terms of variables as their "values", instead of (recursive) constexpr expressions dealing with immutable values being consumed during this process.<br>
<br>
Thinking about this declarative behavior of constexpr with imperative runtime semantics such as "dynamic allocation" is just wrong and is a reason for confusion. It is not about form, but about immutability.<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------Y1131RL31HSSJM8JXQCCNAAMFB0YK1--
.