Topic: [std-proposals] Re: About p0697r0 how SD-6 uncle


Author: clar.nels@gmail.com
Date: Wed, 28 Jun 2017 16:18:44 -0700 (PDT)
Raw View
------=_Part_2115_1472048848.1498691924174
Content-Type: multipart/alternative;
 boundary="----=_Part_2116_1409950292.1498691924174"

------=_Part_2116_1409950292.1498691924174
Content-Type: text/plain; charset="UTF-8"

From my perspective, what actually proved harmful to the original poster
was not that the status of SD-6 was unclear, but just that Microsoft hasn't
implemented it. (Of course Microsoft may claim that they haven't
implemented it because its status is unclear, but to me that feels more
like an excuse than a rationale; confusion hasn't stopped several other
implementers.)

And I'd like to say something else about the SD-6 recommendations: strictly
speaking, they don't need to be implemented within the compiler, and
therefore necessarily by the compiler vendor.

Nothing is stopping Microsoft, or even someone else, from implementing a
separate header that defines the appropriate macros. Such a header could be
preincluded by a command-line option, to satisfy the "predefined"
requirements of SD-6.

Of course such an implementation would likely be just an approximation. It
may well have a difficult time in cases where a feature is enabled or
disabled by a command-line option. There may also be cases where an
independent implementer would come up with a different answer than
Microsoft would.

But even if Microsoft were never to implement the SD-6 recommendations in
their compiler, the recommendations could still be an improvement over the
status quo on which they are trying to improve -- if someone were
sufficiently motivated to make up for Microsoft's lack of initiative.

--
Clark Nelson            Chair, PL22.16 (ANSI C++ standard committee)
Intel Corporation       Chair, SG10 (C++ SG for feature-testing)
clark.nelson@intel.com  Chair, CPLEX (C SG for parallel language extensions)

--
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/80081c1a-9f0e-4e62-876d-448b18c11dba%40isocpp.org.

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

<div dir=3D"ltr"><div>From my perspective, what actually proved harmful to =
the original poster was not that the status of SD-6 was unclear, but just t=
hat Microsoft hasn&#39;t implemented it. (Of course Microsoft may claim tha=
t they haven&#39;t implemented it because its status is unclear, but to me =
that feels more like an excuse than a rationale; confusion hasn&#39;t stopp=
ed several other implementers.)</div><div><br></div><div>And I&#39;d like t=
o say something else about the SD-6 recommendations: strictly speaking, the=
y don&#39;t need to be implemented within the compiler, and therefore neces=
sarily by the compiler vendor.</div><div><br></div><div>Nothing is stopping=
 Microsoft, or even someone else, from implementing a separate header that =
defines the appropriate macros. Such a header could be preincluded by a com=
mand-line option, to satisfy the &quot;predefined&quot; requirements of SD-=
6.</div><div><br></div><div>Of course such an implementation would likely b=
e just an approximation. It may well have a difficult time in cases where a=
 feature is enabled or disabled by a command-line option. There may also be=
 cases where an independent implementer would come up with a different answ=
er than Microsoft would.</div><div><br></div><div>But even if Microsoft wer=
e never to implement the SD-6 recommendations in their compiler, the recomm=
endations could still be an improvement over the status quo on which they a=
re trying to improve -- if someone were sufficiently motivated to make up f=
or Microsoft&#39;s lack of initiative.</div><div><br></div><div>--</div><di=
v>Clark Nelson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chair, PL22.16 (ANS=
I C++ standard committee)</div><div>Intel Corporation =C2=A0 =C2=A0 =C2=A0 =
Chair, SG10 (C++ SG for feature-testing)</div><div>clark.nelson@intel.com =
=C2=A0Chair, CPLEX (C SG for parallel language extensions)</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/80081c1a-9f0e-4e62-876d-448b18c11dba%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/80081c1a-9f0e-4e62-876d-448b18c11dba=
%40isocpp.org</a>.<br />

------=_Part_2116_1409950292.1498691924174--

------=_Part_2115_1472048848.1498691924174--

.


Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Mon, 3 Jul 2017 01:59:54 -0700 (PDT)
Raw View
------=_Part_1593_1217302413.1499072394067
Content-Type: multipart/alternative;
 boundary="----=_Part_1594_1574846584.1499072394067"

------=_Part_1594_1574846584.1499072394067
Content-Type: text/plain; charset="UTF-8"

One question about the possible future. I mean Modules adoption without
macros export. How SD-6 macros can be used with modularized std library?

--
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/908b5de5-569e-452c-80ee-61cf64ea621b%40isocpp.org.

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

<div dir=3D"ltr">One question about the possible future. I mean Modules ado=
ption without macros  export. How SD-6 macros can be used with modularized =
std library?<br></div>

<p></p>

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

------=_Part_1594_1574846584.1499072394067--

------=_Part_1593_1217302413.1499072394067--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 3 Jul 2017 10:13:03 -0700 (PDT)
Raw View
------=_Part_1504_643409323.1499101983808
Content-Type: multipart/alternative;
 boundary="----=_Part_1505_1986624763.1499101983809"

------=_Part_1505_1986624763.1499101983809
Content-Type: text/plain; charset="UTF-8"

On Monday, July 3, 2017 at 4:59:54 AM UTC-4, Victor Dyachenko wrote:
>
> One question about the possible future. I mean Modules adoption without
> macros export. How SD-6 macros can be used with modularized std library?
>

Couldn't there just be a header for that sort of thing? After all, without
macro exporting, a number of C-standard library things will have to be
exposed through the user include mechanism. SD-6 macros would simply be
part and parcel of whatever solution is used in those cases.

--
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/40b2543e-c22c-485e-997b-907257851cbf%40isocpp.org.

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

<div dir=3D"ltr">On Monday, July 3, 2017 at 4:59:54 AM UTC-4, Victor Dyache=
nko wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">One=
 question about the possible future. I mean Modules adoption without macros=
  export. How SD-6 macros can be used with modularized std library?<br></di=
v></blockquote><div><br>Couldn&#39;t there just be a header for that sort o=
f thing? After all, without macro exporting, a number of C-standard library=
 things will have to be exposed through the user include mechanism. SD-6 ma=
cros would simply be part and parcel of whatever solution is used in those =
cases.<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/40b2543e-c22c-485e-997b-907257851cbf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40b2543e-c22c-485e-997b-907257851cbf=
%40isocpp.org</a>.<br />

------=_Part_1505_1986624763.1499101983809--

------=_Part_1504_643409323.1499101983808--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 4 Jul 2017 13:37:16 -0700 (PDT)
Raw View
------=_Part_2604_1744983008.1499200636978
Content-Type: multipart/alternative;
 boundary="----=_Part_2605_2128701949.1499200636979"

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

On Wednesday, June 28, 2017 at 3:51:10 PM UTC-4, Micha=C5=82 W. Urba=C5=84c=
zyk wrote:
>
> Hi everyone,
> I saw recent paper on feature test macros (p0697r0 [1]) and I'd like to=
=20
> share my very recent experience in that matter as a plain C++ user =E2=80=
=94 SD-6=20
> presence and its unclear status proved harmful to me.
>

I think the best solution to the SD-6 problem is to take the implementation=
=20
out of the hands of implementers.

Step 1: actively *forbid* implementations from providing these macros.

Step 2: create a publicly-accessible project that does provide these=20
macros. Each compiler vendor can provide pull-requests for each version of=
=20
their compiler. If a compiler vendor doesn't do so, then concerned citizens=
=20
can do the job. Basically, it would be Boost.Config, but without being part=
=20
of Boost.

This way, we no longer have to worry about major vendors not complying.=20
Because it won't be up to them.

--=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/e75afa3d-a28f-480f-bcff-00696b4def37%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, June 28, 2017 at 3:51:10 PM UTC-4, Micha=C5=
=82 W. Urba=C5=84czyk wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">Hi everyone,<br>I saw recent paper on feature test macros (p=
0697r0 [1]) and I&#39;d like to share my very recent experience in that mat=
ter as a plain C++ user =E2=80=94 SD-6 presence and its unclear status prov=
ed harmful to me.<br></div></blockquote><div><br>I think the best solution =
to the SD-6 problem is to take the implementation out of the hands of imple=
menters.<br><br>Step 1: actively <i>forbid</i> implementations from providi=
ng these macros.<br><br>Step 2: create a publicly-accessible project that d=
oes provide these macros. Each compiler vendor can provide pull-requests fo=
r each version of their compiler. If a compiler vendor doesn&#39;t do so, t=
hen concerned citizens can do the job. Basically, it would be Boost.Config,=
 but without being part of Boost.<br><br>This way, we no longer have to wor=
ry about major vendors not complying. Because it won&#39;t be up to them.<b=
r></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/e75afa3d-a28f-480f-bcff-00696b4def37%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e75afa3d-a28f-480f-bcff-00696b4def37=
%40isocpp.org</a>.<br />

------=_Part_2605_2128701949.1499200636979--

------=_Part_2604_1744983008.1499200636978--

.