On segunda-feira, 3 de julho de 2017 01:59:54 PDT 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?

Simple: there'll be no such ting as modules without macros export. Modules
will support exporting macros.

--
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/1977533.QtUah234yG%40tjmaciei-mobl1.

.

On 3 July 2017 at 19:35, Thiago Macieira <thiago@macieira.org> wrote:
> On segunda-feira, 3 de julho de 2017 01:59:54 PDT 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?
>
> Simple: there'll be no such ting as modules without macros export. Modules
> will support exporting macros.


That remains to be seen. With the Modules as proposed currently, you
need to provide
an additional header that provides the macros, a module can't export a macro.

--
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/CAFk2RUbMT0hTnCLwCsV-MZbBeagZMZYnRbqPBz%2BZLEDaj9aAXg%40mail.gmail.com.

.

On segunda-feira, 3 de julho de 2017 09:49:46 PDT Ville Voutilainen wrote:
> On 3 July 2017 at 19:35, Thiago Macieira <thiago@macieira.org> wrote:
> > On segunda-feira, 3 de julho de 2017 01:59:54 PDT 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?
> >
> > Simple: there'll be no such ting as modules without macros export. Modules
> > will support exporting macros.
>
> That remains to be seen. With the Modules as proposed currently, you
> need to provide
> an additional header that provides the macros, a module can't export a
> macro.

Well, it's in the end the same thing. If you include a header that defines
everything or if you include a wrapper header that defines the macros we need
and causes the module to be used, the end result is the same.

--
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/1709843.041tWgB9dG%40tjmaciei-mobl1.

.

On 3 July 2017 at 20:51, Thiago Macieira <thiago@macieira.org> wrote:
> On segunda-feira, 3 de julho de 2017 09:49:46 PDT Ville Voutilainen wrote:
>> On 3 July 2017 at 19:35, Thiago Macieira <thiago@macieira.org> wrote:
>> > On segunda-feira, 3 de julho de 2017 01:59:54 PDT 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?
>> >
>> > Simple: there'll be no such ting as modules without macros export. Modules
>> > will support exporting macros.
>>
>> That remains to be seen. With the Modules as proposed currently, you
>> need to provide
>> an additional header that provides the macros, a module can't export a
>> macro.
>
> Well, it's in the end the same thing. If you include a header that defines
> everything or if you include a wrapper header that defines the macros we need
> and causes the module to be used, the end result is the same.

Seems far-fetched to me. The importation of a module is quite
different, and fairly many
would say it's better.

--
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/CAFk2RUYVu6VPGP9F6V%2B%3DjdESgJgb010bUFNSh_Bw7pbovy9Zag%40mail.gmail.com.

.

On segunda-feira, 3 de julho de 2017 11:21:00 PDT Ville Voutilainen wrote:
> > Well, it's in the end the same thing. If you include a header that defines
> > everything or if you include a wrapper header that defines the macros we
> > need and causes the module to be used, the end result is the same.
>
> Seems far-fetched to me. The importation of a module is quite
> different, and fairly many
> would say it's better.

Right, but I'd expect libraries that need to export macros to continue using
headers.

And since many may want to have the option of having macros at some point in
time, that leads me to conclude that the main entry point for libraries will
be headers, whether modules exist or not.

--
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/14279655.CnXZ0uvWmv%40tjmaciei-mobl1.

.

On 4 July 2017 at 23:37, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, June 28, 2017 at 3:51:10 PM UTC-4, Micha=C5=82 W. Urba=C5=
=84czyk wrote:
>>
>> Hi everyone,
>> I saw recent paper on feature test macros (p0697r0 [1]) and I'd like to
>> share my very recent experience in that matter as a plain C++ user =E2=
=80=94 SD-6
>> presence and its unclear status proved harmful to me.
>
>
> I think the best solution to the SD-6 problem is to take the implementati=
on
> 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 macr=
os.
> Each compiler vendor can provide pull-requests for each version of their
> compiler. If a compiler vendor doesn't do so, then concerned citizens can=
 do
> the job. Basically, it would be Boost.Config, but without being part of
> Boost.
>
> This way, we no longer have to worry about major vendors not complying.
> Because it won't be up to them.


There's nothing stopping the work for step 2 from happening well
before step 1 is taken, so let's
see how this experiment goes.

--=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/CAFk2RUatb7fV%3D543tZouiiycDmqrgzS2suSW8TsbTBKMw=
F5RAw%40mail.gmail.com.

.

On 07/04/17 23:37, Nicol Bolas wrote:
> On Wednesday, June 28, 2017 at 3:51:10 PM UTC-4, Micha=C5=82 W. Urba=C5=
=84czyk wrote:
>=20
>     Hi everyone,
>     I saw recent paper on feature test macros (p0697r0 [1]) and I'd like
>     to share my very recent experience in that matter as a plain C++
>     user =E2=80=94 SD-6 presence and its unclear status proved harmful to=
 me.
>=20
> I think the best solution to the SD-6 problem is to take the=20
> implementation out of the hands of implementers.
>=20
> Step 1: actively /forbid/ implementations from providing these macros.

What about the compilers that already ship SD-6 macros and the code that=20
checks for them?

> Step 2: create a publicly-accessible project that does provide these=20
> macros. Each compiler vendor can provide pull-requests for each version=
=20
> of their compiler. If a compiler vendor doesn't do so, then concerned=20
> citizens can do the job. Basically, it would be Boost.Config, but=20
> without being part of Boost.
>=20
> This way, we no longer have to worry about major vendors not complying.=
=20
> Because it won't be up to them.

This means that this library is becoming a dependency for other=20
libraries and user's code, which may be a problem. For instance, in=20
Boost it is problematic to depend on anything external, so unless there=20
is no way around assume no external dependencies. I suspect in many=20
other projects the position may be similar. The result will likely be=20
the status quo - every project does its own feature checking.

You may say that this is already the case with Boost.Config, and that=20
would be true. Only that Boost.Config comes for free with Boost, which=20
is often used in projects anyway.

I think if this approach is taken then SD-6 can be considered a failure=20
and we can return to our legacy compiler checks. Which may not be such a=20
bad thing.

IMO for SD-6 to be useful, it should be provided with compilers out of=20
the box. Using it should add zero external dependencies and as little=20
overhead as possible.

--=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/25143498-028e-fa31-e7aa-0478f10b73d8%40gmail.com=
..

.

On Tuesday, 4 July 2017 13:37:16 PDT Nicol Bolas wrote:
> Step 2: create a publicly-accessible project that does provide these
> macros. Each compiler vendor can provide pull-requests for each version of
> their compiler. If a compiler vendor doesn't do so, then concerned citizens
> can do the job. Basically, it would be Boost.Config, but without being part
> of Boost.

That cannot be implemented unless the libraries provide at least one
monotonically increasing macro we can rely upon. Last I checked, libstdc++ had
no such thing.

--
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/6003841.c2tWBBSgrF%40tjmaciei-mobl1.

.

--001a1138eb9a263b86055384c26e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On 4 July 2017 at 13:37, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, June 28, 2017 at 3:51:10 PM UTC-4, Micha=C5=82 W. Urba=C5=
=84czyk wrote:
>>
>> Hi everyone,
>> I saw recent paper on feature test macros (p0697r0 [1]) and I'd like to
>> share my very recent experience in that matter as a plain C++ user =E2=
=80=94 SD-6
>> presence and its unclear status proved harmful to me.
>>
>
> I think the best solution to the SD-6 problem is to take the
> implementation out of the hands of implementers.
>
> Step 1: actively *forbid* implementations from providing these macros.
>

You seem to have a misapprehension about how this works. The committee does
not get to demand or forbid vendors from doing anything. The committee
produces a standard, and vendors choose to what extent they want to conform
to that standard. Most vendors choose some form of non-conformance as their
default mode, with additional conformance enabled by a flag, and for
various reasons, 100% conformance is an ideal rather than a reality.

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

I don't think this needs to in any way depend on step 1. A vendor-specific
library can do whatever it needs to do to correct cases where it believes a
vendor misidentifies their implementation's support for a feature (such as
#undef'ing a macro for a feature that doesn't actually work). You'd need to
cope with compilers that don't "implement" step 1 anyway, to cope with
pre-step-1 compilers.

This way, we no longer have to worry about major vendors not complying.
> Because it won't be up to them.
>
> --
> 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/e75afa3d-a28f-480f-
> bcff-00696b4def37%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e75afa3d-a2=
8f-480f-bcff-00696b4def37%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=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/CAOfiQqmzki7qQVzZyOVjUH3j5NQLgDKjq7uCne5s9CK8%3D=
qSJeA%40mail.gmail.com.

--001a1138eb9a263b86055384c26e
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 4=
 July 2017 at 13:37, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jm=
ckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">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"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi everyone=
,<br>I saw recent paper on feature test macros (p0697r0 [1]) and I&#39;d li=
ke to share my very recent experience in that matter as a plain C++ user =
=E2=80=94 SD-6 presence and its unclear status proved harmful to me.<br></d=
iv></blockquote></span><div><br>I think the best solution to the SD-6 probl=
em is to take the implementation out of the hands of implementers.<br><br>S=
tep 1: actively <i>forbid</i> implementations from providing these macros.<=
br></div></div></blockquote><div><br></div><div>You seem to have a misappre=
hension about how this works. The committee does not get to demand or forbi=
d vendors from doing anything. The committee produces a standard, and vendo=
rs choose to what extent they want to conform to that standard. Most vendor=
s choose some form of non-conformance as their default mode, with additiona=
l conformance enabled by a flag, and for various reasons, 100% conformance =
is an ideal rather than a reality.</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>Step 2: create a publicly-accessible proje=
ct that does provide these macros. Each compiler vendor can provide pull-re=
quests for each version of their compiler. If a compiler vendor doesn&#39;t=
 do so, then concerned citizens can do the job. Basically, it would be Boos=
t.Config, but without being part of Boost.<br></div></div></blockquote><div=
><br></div><div>I don&#39;t think this needs to in any way depend on step 1=
.. A vendor-specific library can do whatever it needs to do to correct cases=
 where it believes a vendor misidentifies their implementation&#39;s suppor=
t for a feature (such as #undef&#39;ing a macro for a feature that doesn&#3=
9;t actually work). You&#39;d need to cope with compilers that don&#39;t &q=
uot;implement&quot; step 1 anyway, to cope with pre-step-1 compilers.</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>This wa=
y, we no longer have to worry about major vendors not complying. Because it=
 won&#39;t be up to them.<br></div></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
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&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e75a=
fa3d-a28f-480f-<wbr>bcff-00696b4def37%40isocpp.org</a><wbr>.<br>
</blockquote></div><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/CAOfiQqmzki7qQVzZyOVjUH3j5NQLgDKjq7uC=
ne5s9CK8%3DqSJeA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmzki7qQV=
zZyOVjUH3j5NQLgDKjq7uCne5s9CK8%3DqSJeA%40mail.gmail.com</a>.<br />

--001a1138eb9a263b86055384c26e--

.

------=_Part_2792_1052632708.1499207555185
Content-Type: multipart/alternative;
 boundary="----=_Part_2793_1924578933.1499207555185"

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

On Tuesday, July 4, 2017 at 5:14:07 PM UTC-4, Andrey Semashev wrote:
>
> On 07/04/17 23:37, Nicol Bolas wrote:=20
> > On Wednesday, June 28, 2017 at 3:51:10 PM UTC-4, Micha=C5=82 W. Urba=C5=
=84czyk=20
> wrote:=20
> >=20
> >     Hi everyone,=20
> >     I saw recent paper on feature test macros (p0697r0 [1]) and I'd lik=
e=20
> >     to share my very recent experience in that matter as a plain C++=20
> >     user =E2=80=94 SD-6 presence and its unclear status proved harmful =
to me.=20
> >=20
> > I think the best solution to the SD-6 problem is to take the=20
> > implementation out of the hands of implementers.=20
> >=20
> > Step 1: actively /forbid/ implementations from providing these macros.=
=20
>
> What about the compilers that already ship SD-6 macros and the code that=
=20
> checks for them?
>

That code was relying on non-standard features. That they could go away at=
=20
some point is to be expected.

> Step 2: create a publicly-accessible project that does provide these=20
> > macros. Each compiler vendor can provide pull-requests for each version=
=20
> > of their compiler. If a compiler vendor doesn't do so, then concerned=
=20
> > citizens can do the job. Basically, it would be Boost.Config, but=20
> > without being part of Boost.=20
> >=20
> > This way, we no longer have to worry about major vendors not complying.=
=20
> > Because it won't be up to them.=20
>
> This means that this library is becoming a dependency for other=20
> libraries and user's code, which may be a problem. For instance, in=20
> Boost it is problematic to depend on anything external, so unless there=
=20
> is no way around assume no external dependencies. I suspect in many=20
> other projects the position may be similar. The result will likely be=20
> the status quo - every project does its own feature checking.
>
> You may say that this is already the case with Boost.Config, and that=20
> would be true. Only that Boost.Config comes for free with Boost, which=20
> is often used in projects anyway.
>

Except that incorporating Boost is a lot more complicated that including a=
=20
few headers. Boost is *gigantic*, and you generally can't ship gigantic=20
things. So if you depend on Boost, then so does everyone who uses your=20
code. Even if you extract *just* Boost.Config, you're talking about dozens=
=20
of headers.

Whereas this would be a small collection of headers. That'd be perfectly=20
valid to be shipped with your project.

I think if this approach is taken then SD-6 can be considered a failure=20
> and we can return to our legacy compiler checks. Which may not be such a=
=20
> bad thing.=20
>
> IMO for SD-6 to be useful, it should be provided with compilers out of=20
> the box. Using it should add zero external dependencies and as little=20
> overhead as possible.
>

--=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/7470b44a-66fb-4b44-a9ff-1f4975146bde%40isocpp.or=
g.

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

<div dir=3D"ltr">On Tuesday, July 4, 2017 at 5:14:07 PM UTC-4, Andrey Semas=
hev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 07/04/17 23:37, N=
icol Bolas wrote:
<br>&gt; On Wednesday, June 28, 2017 at 3:51:10 PM UTC-4, Micha=C5=82 W. Ur=
ba=C5=84czyk wrote:
<br>&gt;=20
<br>&gt; =C2=A0 =C2=A0 Hi everyone,
<br>&gt; =C2=A0 =C2=A0 I saw recent paper on feature test macros (p0697r0 [=
1]) and I&#39;d like
<br>&gt; =C2=A0 =C2=A0 to share my very recent experience in that matter as=
 a plain C++
<br>&gt; =C2=A0 =C2=A0 user =E2=80=94 SD-6 presence and its unclear status =
proved harmful to me.
<br>&gt;=20
<br>&gt; I think the best solution to the SD-6 problem is to take the=20
<br>&gt; implementation out of the hands of implementers.
<br>&gt;=20
<br>&gt; Step 1: actively /forbid/ implementations from providing these mac=
ros.
<br>
<br>What about the compilers that already ship SD-6 macros and the code tha=
t=20
<br>checks for them?<br></blockquote><div><br>That code was relying on non-=
standard features. That they could go away at some point is to be expected.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Step 2: cre=
ate a publicly-accessible project that does provide these=20
<br>&gt; macros. Each compiler vendor can provide pull-requests for each ve=
rsion=20
<br>&gt; of their compiler. If a compiler vendor doesn&#39;t do so, then co=
ncerned=20
<br>&gt; citizens can do the job. Basically, it would be Boost.Config, but=
=20
<br>&gt; without being part of Boost.
<br>&gt;=20
<br>&gt; This way, we no longer have to worry about major vendors not compl=
ying.=20
<br>&gt; Because it won&#39;t be up to them.
<br>
<br>This means that this library is becoming a dependency for other=20
<br>libraries and user&#39;s code, which may be a problem. For instance, in=
=20
<br>Boost it is problematic to depend on anything external, so unless there=
=20
<br>is no way around assume no external dependencies. I suspect in many=20
<br>other projects the position may be similar. The result will likely be=
=20
<br>the status quo - every project does its own feature checking.<br>
<br>You may say that this is already the case with Boost.Config, and that=
=20
<br>would be true. Only that Boost.Config comes for free with Boost, which=
=20
<br>is often used in projects anyway.<br></blockquote><div><br>Except that =
incorporating Boost is a lot more complicated that including a few headers.=
 Boost is <i>gigantic</i>, and you generally can&#39;t ship gigantic things=
.. So if you depend on Boost, then so does everyone who uses your code. Even=
 if you extract <i>just</i> Boost.Config, you&#39;re talking about dozens o=
f headers.<br><br>Whereas this would be a small collection of headers. That=
&#39;d be perfectly valid to be shipped with your project.<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">
I think if this approach is taken then SD-6 can be considered a failure=20
<br>and we can return to our legacy compiler checks. Which may not be such =
a=20
<br>bad thing.
<br>
<br>IMO for SD-6 to be useful, it should be provided with compilers out of=
=20
<br>the box. Using it should add zero external dependencies and as little=
=20
<br>overhead as possible.<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/7470b44a-66fb-4b44-a9ff-1f4975146bde%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7470b44a-66fb-4b44-a9ff-1f4975146bde=
%40isocpp.org</a>.<br />

------=_Part_2793_1924578933.1499207555185--

------=_Part_2792_1052632708.1499207555185--

.

On Tuesday, 4 July 2017 15:32:35 PDT Nicol Bolas wrote:
> On Tuesday, July 4, 2017 at 5:14:07 PM UTC-4, Andrey Semashev wrote:
> > What about the compilers that already ship SD-6 macros and the code that
> > checks for them?
>
> That code was relying on non-standard features. That they could go away at
> some point is to be expected.

That's exactly the point we're making here: for SD-6 to be useful at all, it
must be implemented by most compilers and cannot go away.

If either proposition isn't true, then the document is not useful. We need at
the very least to know which compilers are committing to using SD-6
recommendations for the long haul.

--
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/5820912.XTZrDY279i%40tjmaciei-mobl1.

.

On 2017-07-04 22:37, Nicol Bolas wrote:
[...]
> Step 1: actively _forbid_ implementations from providing these macros.

This step is actually not necessary, since...

> Step 2: create a publicly-accessible project that does provide these
> macros.

.... a non-vendor library cannot define double-underscore names, as they
are reserved for implementation use.

That means such a project would have to use different names, anyway,
e.g. __cxx_foo -> SD6_CXX_FOO, thus making point (1) moot.

Thanks,
Marc

--
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/75347dc112b17b9ec22750bb02e6e62b%40kdab.com.

.

On 2017-07-04 23:40, Thiago Macieira wrote:
> On Tuesday, 4 July 2017 13:37:16 PDT Nicol Bolas wrote:
>> Step 2: create a publicly-accessible project that does provide these
>> macros. Each compiler vendor can provide pull-requests for each
>> version of
>> their compiler. If a compiler vendor doesn't do so, then concerned
>> citizens
>> can do the job. Basically, it would be Boost.Config, but without being
>> part
>> of Boost.
>
> That cannot be implemented unless the libraries provide at least one
> monotonically increasing macro we can rely upon. Last I checked,
> libstdc++ had
> no such thing.

It cannot be done _easily_. You can always enumerate the versions one by
one instead of relying on >=, though.

--
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/290806df8515ec60d853b67e757dec0a%40kdab.com.

.

On quarta-feira, 5 de julho de 2017 04:37:01 PDT Marc Mutz wrote:
> On 2017-07-04 23:40, Thiago Macieira wrote:
> > That cannot be implemented unless the libraries provide at least one
> > monotonically increasing macro we can rely upon. Last I checked,
> > libstdc++ had
> > no such thing.
>
> It cannot be done _easily_. You can always enumerate the versions one by
> one instead of relying on >=, though.

To be clear, I didn't mean that the libraries had to use the same identifier.
Each library has its own.

You can't enumerate all release dates of libstdc++ because you cannot know
when it will release the versions it hasn't released yet. And that's not
including Linux distributions building and releasing older branches with
updates.

--
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/1510705.ETDiXY1D4j%40tjmaciei-mobl1.

.

On 2017-07-05 17:07, Thiago Macieira wrote:
> On quarta-feira, 5 de julho de 2017 04:37:01 PDT Marc Mutz wrote:
>> On 2017-07-04 23:40, Thiago Macieira wrote:
>> > That cannot be implemented unless the libraries provide at least one
>> > monotonically increasing macro we can rely upon. Last I checked,
>> > libstdc++ had
>> > no such thing.
>>
>> It cannot be done _easily_. You can always enumerate the versions one
>> by
>> one instead of relying on >=, though.
>
> To be clear, I didn't mean that the libraries had to use the same
> identifier.
> Each library has its own.
>
> You can't enumerate all release dates of libstdc++ because you cannot
> know
> when it will release the versions it hasn't released yet. And that's
> not
> including Linux distributions building and releasing older branches
> with
> updates.

That is true. So the external project would have to track releases as
they happen. But to a lesser extent, you have the same problem with
version numbers. Given GCC 8, we don't know what the next version will
be. GCC 8.1? GCC 9.0? Yes, it will be numerically larger, but it might
also drop -fconcepts. So any such external project will only be able to
give accurate results for released versions of compiler and library.

That said, GCC is pretty simple: afaik, you can't use libstdc++ with
MSVC, and both libstdc++ and the other compilers with which you can use
it support SD-6 macros, even if the usability leaves something to be
desired. But this is what the external project is all about: papering
over such idiosyncrasies.

--
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/2e76d3b987e1da51ac2d5c27edfe95aa%40kdab.com.

.

On quarta-feira, 5 de julho de 2017 09:32:15 PDT Marc Mutz wrote:
> > You can't enumerate all release dates of libstdc++ because you cannot
> > know
> > when it will release the versions it hasn't released yet. And that's
> > not
> > including Linux distributions building and releasing older branches
> > with
> > updates.
>
> That is true. So the external project would have to track releases as
> they happen.

It wouldn't be sufficient. What should that file conclude about the support for
std::unique_ptr, for example, for an unknown release? That it does support or
that it doesn't?

> But to a lesser extent, you have the same problem with
> version numbers. Given GCC 8, we don't know what the next version will
> be. GCC 8.1? GCC 9.0? Yes, it will be numerically larger, but it might
> also drop -fconcepts. So any such external project will only be able to
> give accurate results for released versions of compiler and library.

-fconcepts is enabling something not yet part of the standard. You can rely on
a newer compiler version not being worse than a previous version when it comes
to standardised parts.

Experimental parts are a whole different matter. Code meant to be portable and
long-term supported should never use it. (Note how this applies to TR1!)

> That said, GCC is pretty simple: afaik, you can't use libstdc++ with
> MSVC, and both libstdc++ and the other compilers with which you can use
> it support SD-6 macros, even if the usability leaves something to be
> desired. But this is what the external project is all about: papering
> over such idiosyncrasies.

Right.

--
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/1802255.uORySKpkFq%40tjmaciei-mobl1.

.

On 2017-07-05 23:23, Thiago Macieira wrote:
> On quarta-feira, 5 de julho de 2017 09:32:15 PDT Marc Mutz wrote:
>> > You can't enumerate all release dates of libstdc++ because you cannot
>> > know
>> > when it will release the versions it hasn't released yet. And that's
>> > not
>> > including Linux distributions building and releasing older branches
>> > with
>> > updates.
>>
>> That is true. So the external project would have to track releases as
>> they happen.
>
> It wouldn't be sufficient. What should that file conclude about the
> support for
> std::unique_ptr, for example, for an unknown release? That it does
> support or
> that it doesn't?

Undefined? #error? "Not available"?

It does not matter, because the detection of unreleased stuff is but a
guess at the future, anyway. Sometimes, that guess is accurate,
sometimes not so much. But a *correct* answer from an external project
you can only expect once the upstream release is done.

>> But to a lesser extent, you have the same problem with
>> version numbers. Given GCC 8, we don't know what the next version will
>> be. GCC 8.1? GCC 9.0? Yes, it will be numerically larger, but it might
>> also drop -fconcepts. So any such external project will only be able
>> to
>> give accurate results for released versions of compiler and library.
>
> -fconcepts is enabling something not yet part of the standard. You can
> rely on
> a newer compiler version not being worse than a previous version when
> it comes
> to standardised parts.
>
> Experimental parts are a whole different matter. Code meant to be
> portable and
> long-term supported should never use it. (Note how this applies to
> TR1!)

I don't agree here, but this, too, does not matter: SD-6 does cover
experimental features like <experimental/string_view>, so regardless of
what any of us thinks about use of these feature in "portable and
long-term supported" code, these features need to be supported by any
SD-6 replacement/amendment/fixup, too.

Thanks,
Marc

--
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/7e96d705cee4e0ea53bf9233be056f07%40kdab.com.

.

On quarta-feira, 5 de julho de 2017 23:39:52 PDT Marc Mutz wrote:
> On 2017-07-05 23:23, Thiago Macieira wrote:
> > It wouldn't be sufficient. What should that file conclude about the
> > support for
> > std::unique_ptr, for example, for an unknown release? That it does
> > support or
> > that it doesn't?
>
> Undefined? #error? "Not available"?

None of those options are acceptable. If the GCC team issues a hot-fix for GCC
6.x and you install it, should your libraries stop compiling?

The only correct answer is that your application must continue compiling
exactly as before, with no loss of functionality. If you can't implement a
header that provides this information, then you can't implement it.

> It does not matter, because the detection of unreleased stuff is but a
> guess at the future, anyway. Sometimes, that guess is accurate,
> sometimes not so much. But a *correct* answer from an external project
> you can only expect once the upstream release is done.

The problem is not the guess at the future. It's the upgrade. See above.

> > Experimental parts are a whole different matter. Code meant to be
> > portable and
> > long-term supported should never use it. (Note how this applies to
> > TR1!)
>
> I don't agree here, but this, too, does not matter: SD-6 does cover
> experimental features like <experimental/string_view>, so regardless of
> what any of us thinks about use of these feature in "portable and
> long-term supported" code, these features need to be supported by any
> SD-6 replacement/amendment/fixup, too.

That's just information saying "this experimental feature is supported", but
there's no long-term commitment to whether the experimental feature will
continue being there. For one thing, when it's standardised and no longer
experimental, it will not be there.

I'm not against having experimental features' availability. But we need to
augment that with the information on which "revision" of the feature it may be
talking about.

I am against using them in Qt. Not going to happen.


--
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/7731034.JcGQH5rjMq%40tjmaciei-mobl1.

.