On Wednesday, 12 December 2018 21:38:41 PST gmisocpp@gmail.com wrote:
> If we don't do this and C does get such features, C++ will come under
> pressure to adopt the C version of is_constant_evaluated too for
> compatibility. So shouldn't we head this off now?

How is that different from printf and std::printf?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



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

.

------=_Part_515_318967035.1544732898620
Content-Type: multipart/alternative;
 boundary="----=_Part_516_1401148020.1544732898621"

------=_Part_516_1401148020.1544732898621
Content-Type: text/plain; charset="UTF-8"

std::is_constant_evaluated is obviously a language feature and not a
library feature unlike printf so it should look like one. A user could not
write this function unlike printf and will expect to use this feature
without a header unlike printf,

Putting the feature into a namespace where it implies that some header must
be included to get the std:: namespace defined is confusing to teach. Also
language teachers can avoid teaching library functions like printf so
talking about printf vs std::printf is not a requirement.

But std::is_constant_evaluated is clearly a language feature so teaching it
will be a requirement  If C does get this feature, as it stands C will
guaranteed have to name it something else even if it does exactly the same
thing and C++ will want to share that code C code so we will get the C
version and teachers now have to teach both. And the C version will
actually look the more logical one to use if it does the same thing because
it will look like what it is more so. Language teachers will then be
inclined to teach both and it's back to students thinking C++ has two heads.

So to me, it seems dubious in that context to bundle a namespace into a
feature, that obscures what the feature is and the requirements to use
it, and invites a guaranteed inconsistency with C down the line and where
we'll prefer the C version later for compatibility and
teach-ability reasons and be stuck with both to teach and where language
teachers are less able to avoid that discussion unlike printf which can be
avoided.

I think this story is compelling enough to try to avoid that?

On Thursday, December 13, 2018 at 7:01:40 PM UTC+13, Thiago Macieira wrote:

> On Wednesday, 12 December 2018 21:38:41 PST gmis...@gmail.com
> <javascript:> wrote:
> > If we don't do this and C does get such features, C++ will come under
> > pressure to adopt the C version of is_constant_evaluated too for
> > compatibility. So shouldn't we head this off now?
>
> How is that different from printf and std::printf?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
>
>
>

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

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

<div dir=3D"ltr"><div>std::is_constant_evaluated is obviously a language fe=
ature and not a library feature unlike printf so it should look like one. A=
 user could not write this function=C2=A0unlike printf and=C2=A0will expect=
 to use this feature without a header unlike printf, </div><div><br></div><=
div>Putting the feature into a namespace where it implies that some header =
must be included to get the std:: namespace defined is confusing to teach.=
=C2=A0Also language teachers=C2=A0can avoid=C2=A0teaching library functions=
 like=C2=A0printf=C2=A0so talking about printf vs std::printf is not a requ=
irement.</div><div><br></div><div>But std::is_constant_evaluated=C2=A0is cl=
early=C2=A0a language feature=C2=A0so teaching it will be a requirement=C2=
=A0 If C does get this feature,=C2=A0as it stands C will guaranteed have to=
 name it something else even if it does exactly the same thing and C++ will=
 want to share that code C=C2=A0code so we will get the C version and teach=
ers now have to teach both. And the C version will actually look the more l=
ogical one to use if it does the same=C2=A0thing=C2=A0because it will look =
like what it is more so. Language teachers will then be inclined to teach b=
oth and it&#39;s back to students thinking=C2=A0C++ has two heads.</div><di=
v><br></div><div><div>So to me, it=C2=A0seems=C2=A0dubious in that context=
=C2=A0to bundle=C2=A0a namespace into a feature, that=C2=A0obscures=C2=A0wh=
at=C2=A0the feature=C2=A0is and=C2=A0the requirements=C2=A0to use it,=C2=A0=
and invites a guaranteed inconsistency with C down the line and where we&#3=
9;ll prefer the C version later for compatibility and teach-ability=C2=A0re=
asons and be stuck with both to teach and=C2=A0where language teachers are =
less able to=C2=A0avoid that discussion unlike printf which can be avoided.=
</div><div><br></div></div><div>I think this story is compelling enough to =
try to avoid that?<br><br>On Thursday, December 13, 2018 at 7:01:40 PM UTC+=
13, Thiago Macieira wrote:</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;">On Wednesday, =
12 December 2018 21:38:41 PST <a onmousedown=3D"this.href=3D&#39;javascript=
:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tr=
ue;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated=
-mailto=3D"CmID0aiUBAAJ">gmis...@gmail.com</a> wrote:
<br>&gt; If we don&#39;t do this and C does get such features, C++ will com=
e under
<br>&gt; pressure to adopt the C version of is_constant_evaluated too for
<br>&gt; compatibility. So shouldn&#39;t we head this off now?
<br>
<br>How is that different from printf and std::printf?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D=
"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;=
return true;" href=3D"http://macieira.info" target=3D"_blank" rel=3D"nofoll=
ow">macieira.info</a> - thiago (AT) <a onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return tru=
e;" href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow">kde.org</a>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_516_1401148020.1544732898621--

------=_Part_515_318967035.1544732898620--

.

On Thursday, 13 December 2018 12:27:57 PST gmisocpp@gmail.com wrote:
> std::is_constant_evaluated is obviously a language feature and not a
> library feature unlike printf so it should look like one. A user could not
> write this function unlike printf and will expect to use this feature
> without a header unlike printf,

std::is_enum is a language feature too, enums exist in C. There were pre-
intrinsic implementations of is_enum, but I believe they had a few corner-
cases they failed. There are also a lot of traits that could not be
implemented by library code and need help from the compiler, though it's
possible none of them are about concepts that exist in C.

We also have language features that require header inclusion, namely typeid
(<typeinfo>) and initializer lists (<initializer_list>). Not to mention <new>.

> Putting the feature into a namespace where it implies that some header must
> be included to get the std:: namespace defined is confusing to teach. Also
> language teachers can avoid teaching library functions like printf so
> talking about printf vs std::printf is not a requirement.

Strictly speaking, C++ makes no guarantee that ::printf exists and links. It
works in all compilers because all C++ compilers are also C compilers and make
use of the C library. So a C++ teacher should not be talking about ::printf.

Including headers, as I've shown, is not an impediment.

I don't like it because headers often tend to be big and slow compilation
down, but that boat has sailed. I lost that particular battle for Qt 5.0 when
we made the C++ Standard Library mandatory, causing my builds to slow down by
at least 25%.

> But std::is_constant_evaluated is clearly a language feature so teaching it
> will be a requirement  If C does get this feature, as it stands C will
> guaranteed have to name it something else even if it does exactly the same
> thing and C++ will want to share that code C code so we will get the C
> version and teachers now have to teach both. And the C version will
> actually look the more logical one to use if it does the same thing because
> it will look like what it is more so. Language teachers will then be
> inclined to teach both and it's back to students thinking C++ has two heads.

I understand your argument and sympathise, but it's not going to make a dent
in the fact that C++ already has two heads. I personally still write code
using <stdlib.h> and <stdio.h>.

> So to me, it seems dubious in that context to bundle a namespace into a
> feature, that obscures what the feature is and the requirements to use
> it, and invites a guaranteed inconsistency with C down the line and where
> we'll prefer the C version later for compatibility and
> teach-ability reasons and be stuck with both to teach and where language
> teachers are less able to avoid that discussion unlike printf which can be
> avoided.

Is there any inkling that C would want to have constexpr in the future?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



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

.

On Thu, 13 Dec 2018 at 22:28, <gmisocpp@gmail.com> wrote:
>
> std::is_constant_evaluated is obviously a language feature and not a libr=
ary feature unlike printf so it should look like one. A user could not writ=
e this function unlike printf and will expect to use this feature without a=
 header unlike printf,
>
> Putting the feature into a namespace where it implies that some header mu=
st be included to get the std:: namespace defined is confusing to teach. Al=
so language teachers can avoid teaching library functions like printf so ta=
lking about printf vs std::printf is not a requirement.

That suggestion for an implication is mistaken. And as far as the
current spelling of it goes, that's a library API to a language
facility; we have many more of those.

> But std::is_constant_evaluated is clearly a language feature so teaching =
it will be a requirement  If C does get this feature, as it stands C will g=
uaranteed have to name it something else even if it does exactly the same t=
hing and C++ will want to share that code C code so we will get the C versi=
on and teachers now have to teach both. And the C version will actually loo=
k the more logical one to use if it does the same thing because it will loo=
k like what it is more so. Language teachers will then be inclined to teach=
 both and it's back to students thinking C++ has two heads.
>
> So to me, it seems dubious in that context to bundle a namespace into a f=
eature, that obscures what the feature is and the requirements to use it, a=
nd invites a guaranteed inconsistency with C down the line and where we'll =
prefer the C version later for compatibility and teach-ability reasons and =
be stuck with both to teach and where language teachers are less able to av=
oid that discussion unlike printf which can be avoided.
>
> I think this story is compelling enough to try to avoid that?

I don't see how; there are perhaps more commonly-used facilities where
the same story would apply (atomics, traits...), and the story doesn't
seem
to materialize in ways that cause significant problems. The
alternative for a library spelling would be a keyword, and grabbing
those is more trouble
than this hypothetical story seems worth.

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

.

------=_Part_583_940851517.1544740864589
Content-Type: multipart/alternative;
 boundary="----=_Part_584_809001267.1544740864590"

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



=E5=9C=A8 2018=E5=B9=B412=E6=9C=8814=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8A=E5=8D=884:49:28=EF=BC=8CThiago Macieira=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On Thursday, 13 December 2018 12:27:57 PST gmis...@gmail.com <javascript:=
>=20
> wrote:=20
> > std::is_constant_evaluated is obviously a language feature and not a=20
> > library feature unlike printf so it should look like one. A user could=
=20
> not=20
> > write this function unlike printf and will expect to use this feature=
=20
> > without a header unlike printf,=20
>
> std::is_enum is a language feature too, enums exist in C. There were pre-=
=20
> intrinsic implementations of is_enum, but I believe they had a few corner=
-=20
> cases they failed. There are also a lot of traits that could not be=20
> implemented by library code and need help from the compiler, though it's=
=20
> possible none of them are about concepts that exist in C.=20
>

Would you expect std::is_emum<...>, or std::is_enum(...)?

I don't think namespace directly matters. The key point is whether the=20
function-like syntax (which indicates applicative evaluations but not=20
introducing non-strict/unevaluated contexts) confusing.

If so, it should better to be a keyword, but not a namespace-scope name. It=
=20
seems not consistent in style, since there is no prior art in the standard=
=20
C++ like this.

Otherwise, introduce the core mechanism first (like contextual keywords).=
=20
Note today C++ has still no way to introduce syntactic extensions with=20
user-declarable names, nor with namespaces support of pre-evaluation phase=
=20
language constructs. The only exception of namespace syntax around names=20
are of attributes, which are not entities. (I'd appreciate the try to make=
=20
macros as namespace members.)


> We also have language features that require header inclusion, namely=20
> typeid=20
> (<typeinfo>) and initializer lists (<initializer_list>). Not to mention=
=20
> <new>.=20
>
> > Putting the feature into a namespace where it implies that some header=
=20
> must=20
> > be included to get the std:: namespace defined is confusing to teach.=
=20
> Also=20
> > language teachers can avoid teaching library functions like printf so=
=20
> > talking about printf vs std::printf is not a requirement.=20
>
> Strictly speaking, C++ makes no guarantee that ::printf exists and links.=
=20
> It=20
> works in all compilers because all C++ compilers are also C compilers and=
=20
> make=20
> use of the C library. So a C++ teacher should not be talking about=20
> ::printf.=20
>
> Including headers, as I've shown, is not an impediment.=20
>
> I don't like it because headers often tend to be big and slow compilation=
=20
> down, but that boat has sailed. I lost that particular battle for Qt 5.0=
=20
> when=20
> we made the C++ Standard Library mandatory, causing my builds to slow dow=
n=20
> by=20
> at least 25%.=20
>
> > But std::is_constant_evaluated is clearly a language feature so teachin=
g=20
> it=20
> > will be a requirement  If C does get this feature, as it stands C will=
=20
> > guaranteed have to name it something else even if it does exactly the=
=20
> same=20
> > thing and C++ will want to share that code C code so we will get the C=
=20
> > version and teachers now have to teach both. And the C version will=20
> > actually look the more logical one to use if it does the same thing=20
> because=20
> > it will look like what it is more so. Language teachers will then be=20
> > inclined to teach both and it's back to students thinking C++ has two=
=20
> heads.=20
>
> I understand your argument and sympathise, but it's not going to make a=
=20
> dent=20
> in the fact that C++ already has two heads. I personally still write code=
=20
> using <stdlib.h> and <stdio.h>.=20
>
> > So to me, it seems dubious in that context to bundle a namespace into a=
=20
> > feature, that obscures what the feature is and the requirements to use=
=20
> > it, and invites a guaranteed inconsistency with C down the line and=20
> where=20
> > we'll prefer the C version later for compatibility and=20
> > teach-ability reasons and be stuck with both to teach and where languag=
e=20
> > teachers are less able to avoid that discussion unlike printf which can=
=20
> be=20
> > avoided.=20
>
> Is there any inkling that C would want to have constexpr in the future?=
=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/31e3d917-70d7-40bd-8933-119c5bf38e9d%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B412=E6=9C=8814=E6=97=A5=E6=
=98=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8A=E5=8D=884:49:28=EF=BC=8CThiago Maci=
eira=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>On Thursday, 13 December 2018 12:27:57 PST <a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"LuqeExvFBAAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;">gmis...@gmail.com</a> wrote:
<br>&gt; std::is_constant_evaluated is obviously a language feature and not=
 a
<br>&gt; library feature unlike printf so it should look like one. A user c=
ould not
<br>&gt; write this function unlike printf and will expect to use this feat=
ure
<br>&gt; without a header unlike printf,
<br>
<br>std::is_enum is a language feature too, enums exist in C. There were pr=
e-
<br>intrinsic implementations of is_enum, but I believe they had a few corn=
er-
<br>cases they failed. There are also a lot of traits that could not be=20
<br>implemented by library code and need help from the compiler, though it&=
#39;s=20
<br>possible none of them are about concepts that exist in C.
<br></blockquote><div><br>Would you expect std::is_emum&lt;...&gt;, or std:=
:is_enum(...)?<br><br>I don&#39;t think namespace directly matters. The key=
 point is whether the function-like syntax (which indicates applicative eva=
luations but not introducing non-strict/unevaluated contexts) confusing.<br=
><br>If so, it should better to be a keyword, but not a namespace-scope nam=
e. It seems not consistent in style, since there is no prior art in the sta=
ndard C++ like this.<br><br>Otherwise, introduce the core mechanism first (=
like contextual keywords). Note today C++ has still no way to introduce syn=
tactic extensions with user-declarable names, nor with namespaces support o=
f pre-evaluation phase language constructs. The only exception of namespace=
 syntax around names are of attributes, which are not entities. (I&#39;d ap=
preciate the try to make macros as namespace members.)<br><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">
<br>We also have language features that require header inclusion, namely ty=
peid=20
<br>(&lt;typeinfo&gt;) and initializer lists (&lt;initializer_list&gt;). No=
t to mention &lt;new&gt;.
<br>
<br>&gt; Putting the feature into a namespace where it implies that some he=
ader must
<br>&gt; be included to get the std:: namespace defined is confusing to tea=
ch. Also
<br>&gt; language teachers can avoid teaching library functions like printf=
 so
<br>&gt; talking about printf vs std::printf is not a requirement.
<br>
<br>Strictly speaking, C++ makes no guarantee that ::printf exists and link=
s. It=20
<br>works in all compilers because all C++ compilers are also C compilers a=
nd make=20
<br>use of the C library. So a C++ teacher should not be talking about ::pr=
intf.
<br>
<br>Including headers, as I&#39;ve shown, is not an impediment.
<br>
<br>I don&#39;t like it because headers often tend to be big and slow compi=
lation=20
<br>down, but that boat has sailed. I lost that particular battle for Qt 5.=
0 when=20
<br>we made the C++ Standard Library mandatory, causing my builds to slow d=
own by=20
<br>at least 25%.
<br>
<br>&gt; But std::is_constant_evaluated is clearly a language feature so te=
aching it
<br>&gt; will be a requirement =C2=A0If C does get this feature, as it stan=
ds C will
<br>&gt; guaranteed have to name it something else even if it does exactly =
the same
<br>&gt; thing and C++ will want to share that code C code so we will get t=
he C
<br>&gt; version and teachers now have to teach both. And the C version wil=
l
<br>&gt; actually look the more logical one to use if it does the same thin=
g because
<br>&gt; it will look like what it is more so. Language teachers will then =
be
<br>&gt; inclined to teach both and it&#39;s back to students thinking C++ =
has two heads.
<br>
<br>I understand your argument and sympathise, but it&#39;s not going to ma=
ke a dent=20
<br>in the fact that C++ already has two heads. I personally still write co=
de=20
<br>using &lt;stdlib.h&gt; and &lt;stdio.h&gt;.
<br>
<br>&gt; So to me, it seems dubious in that context to bundle a namespace i=
nto a
<br>&gt; feature, that obscures what the feature is and the requirements to=
 use
<br>&gt; it, and invites a guaranteed inconsistency with C down the line an=
d where
<br>&gt; we&#39;ll prefer the C version later for compatibility and
<br>&gt; teach-ability reasons and be stuck with both to teach and where la=
nguage
<br>&gt; teachers are less able to avoid that discussion unlike printf whic=
h can be
<br>&gt; avoided.
<br>
<br>Is there any inkling that C would want to have constexpr in the future?
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br>
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_584_809001267.1544740864590--

------=_Part_583_940851517.1544740864589--

.

--000000000000012d74057cef078d
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 13, 2018 at 3:49 PM Thiago Macieira <thiago@macieira.org> wrote:

> Strictly speaking, C++ makes no guarantee that ::printf exists and links.
>

That's false, at least for now. See [depr.c.headers].

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

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Dec 13=
, 2018 at 3:49 PM Thiago Macieira &lt;<a href=3D"mailto:thiago@macieira.org=
">thiago@macieira.org</a>&gt; wrote:</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
Strictly speaking, C++ makes no guarantee that ::printf exists and links.<b=
r></blockquote><div><br>That&#39;s false, at least for now. See [depr.c.hea=
ders].</div></div></div>

<p></p>

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

--000000000000012d74057cef078d--

.

------=_Part_710_1211197682.1544776707715
Content-Type: multipart/alternative;
 boundary="----=_Part_711_541500142.1544776707715"

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

Il giorno gioved=C3=AC 13 dicembre 2018 06:38:41 UTC+1, gmis...@gmail.com h=
a=20
scritto:
>
> If we don't do this and C does get such features, C++ will come under=20
> pressure to adopt the C version of is_constant_evaluated too for=20
> compatibility. So shouldn't we head this off now?
>

Frankly, I do not see a big compatibility issue here. The only case I see=
=20
where such an issue may arise is in a consteval function that occurs in an=
=20
header file, which is meant to be compiled from both in C and in C++. Such=
=20
an occurrence can be easily addressed with a:

#ifdef __cplusplus
using std::is_constant_evaluated;
#endif

directly in each function scope (or just once in global scope if you're=20
lazy and aware of the consequences). A minor inconvenience, maybe, but not=
=20
a significant "pressure", in my humble opinion.

Alberto

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c6eec3a1-e257-412c-92a4-277b03bfc8ac%40isocpp.or=
g.

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

<div dir=3D"ltr">Il giorno gioved=C3=AC 13 dicembre 2018 06:38:41 UTC+1, gm=
is...@gmail.com ha scritto:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>If we don&#39;t do this and C does get such features, C+=
+ will come under pressure to adopt the C version of is_constant_evaluated =
too for compatibility. So shouldn&#39;t we head this off now?</div></div></=
blockquote><div><br></div><div>Frankly, I do not see a big compatibility is=
sue here. The only case I see where such an issue may arise is in a constev=
al function that occurs in an header file, which is meant to be compiled fr=
om both in C and in C++. Such an occurrence can be easily addressed with a:=
</div><div><br></div><div>#ifdef __cplusplus<br></div><div>using std::is_co=
nstant_evaluated;</div><div>#endif</div><div><br></div><div>directly in eac=
h function scope (or just once in global scope if you&#39;re lazy and aware=
 of the consequences). A minor inconvenience, maybe, but not a significant =
&quot;pressure&quot;, in my humble opinion.</div><div><br></div><div>Albert=
o<br></div></div>

<p></p>

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

------=_Part_711_541500142.1544776707715--

------=_Part_710_1211197682.1544776707715--

.