------=_Part_313_2088166014.1501427012423
Content-Type: multipart/alternative;
 boundary="----=_Part_314_548996503.1501427012424"

------=_Part_314_548996503.1501427012424
Content-Type: text/plain; charset="UTF-8"

Now that Concepts TS is part of the C++ standard going forward, the next
question is what to do about the standard library. The thing I want to
focus on in this thread is *not* big things like iterator/algorithm
concepts. Ranges TS already has perfectly good solutions to those.

My primary concern is with the specification of functions where the
standard currently says something to the effect of, "This function does not
participate in overload resolution if...", followed by some list of
requirements. At present, that logically translates into some kind of
`std::enable_if` or `std::void_t` gymnastics. But the standard doesn't
specify exactly what kind of gymnastics are used; it just lets the
implementation work it out (within the bounds that implementations are
provided).

Concepts TS gives the language the ability to express "This function does
not participate in overload resolution if..." directly in the function
definition, via a requires clause. So, should someone go through the
standard library and change all of those definitions to explicitly use a
requires clause? Would there be any downsides to doing so? Could it make
implementations more difficult?

And equally importantly, some of those requirements are logically concepts,
which other people will want to use. And the standard library doesn't
define any concepts yet. Should we add some very basic utility concepts,
perhaps concepts that match existing type-traits? Should we add more than
just type-trait concepts? Again, not iterator/range/etc concepts, just
smaller things.

And on a process note, if it doesn't look like Ranges TS will make it into
C++20, should we fast-track some of its utility concepts, so that we can
have them available?

--
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/405ca072-30f3-45e6-b6b1-4e09d3bd459f%40isocpp.org.

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

<div dir=3D"ltr">Now that Concepts TS is part of the C++ standard going for=
ward, the next question is what to do about the standard library. The thing=
 I want to focus on in this thread is <i>not</i> big things like iterator/a=
lgorithm concepts. Ranges TS already has perfectly good solutions to those.=
<br><br>My primary concern is with the specification of functions where the=
 standard currently says something to the effect of, &quot;This function do=
es not participate in overload resolution if...&quot;, followed by some lis=
t of requirements. At present, that logically translates into some kind of =
`std::enable_if` or `std::void_t` gymnastics. But the standard doesn&#39;t =
specify exactly what kind of gymnastics are used; it just lets the implemen=
tation work it out (within the bounds that implementations are provided).<b=
r><br>Concepts TS gives the language the ability to express &quot;This func=
tion does not participate in overload resolution if...&quot; directly in th=
e function definition, via a requires clause. So, should someone go through=
 the standard library and change all of those definitions to explicitly use=
 a requires clause? Would there be any downsides to doing so? Could it make=
 implementations more difficult? <br><br>And equally importantly, some of t=
hose requirements are logically concepts, which other people will want to u=
se. And the standard library doesn&#39;t define any concepts yet. Should we=
 add some very basic utility concepts, perhaps concepts that match existing=
 type-traits? Should we add more than just type-trait concepts? Again, not =
iterator/range/etc concepts, just smaller things.<br><br>And on a process n=
ote, if it doesn&#39;t look like Ranges TS will make it into C++20, should =
we fast-track some of its utility concepts, so that we can have them availa=
ble?<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/405ca072-30f3-45e6-b6b1-4e09d3bd459f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/405ca072-30f3-45e6-b6b1-4e09d3bd459f=
%40isocpp.org</a>.<br />

------=_Part_314_548996503.1501427012424--

------=_Part_313_2088166014.1501427012423--

.

------=_Part_3325_4473548.1501427700473
Content-Type: multipart/alternative;
 boundary="----=_Part_3326_226800837.1501427700473"

------=_Part_3326_226800837.1501427700473
Content-Type: text/plain; charset="UTF-8"

On Monday, 31 July 2017 01:03:32 UTC+10, Nicol Bolas wrote:
>
> Concepts TS gives the language the ability to express "This function does
> not participate in overload resolution if..." directly in the function
> definition, via a requires clause. So, should someone go through the
> standard library and change all of those definitions to explicitly use a
> requires clause? Would there be any downsides to doing so? Could it make
> implementations more difficult?
>

This seems like a really good thing to do. I assumed this was going to be
done as part of Concepts delivery, to prove workability.

The one question that comes to mind: Assuming the *meaning* doesn't change,
would existing implementations be "conforming" via the 'as-if' rule? ( I
assume so, but also assume I may be wrong)

Conversely, it *seems* to me that a conceptified implementation would
conform with the current language, so doing it first and then proposing the
changes seems viable and somewhat desirable.

If it's going to be done for C++20, it probably needs to be code-complete
in the next six months or so, to give the committee meetings a couple of
years to discuss the names used for the concepts that it is decided are
useful to given names to.

--
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/1cec39de-0ad4-4d20-8327-8f242d6f4c04%40isocpp.org.

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

<div dir=3D"ltr">On Monday, 31 July 2017 01:03:32 UTC+10, Nicol Bolas  wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Concepts TS=
 gives the language the ability to express &quot;This function does not par=
ticipate in overload resolution if...&quot; directly in the function defini=
tion, via a requires clause. So, should someone go through the standard lib=
rary and change all of those definitions to explicitly use a requires claus=
e? Would there be any downsides to doing so? Could it make implementations =
more difficult? </div></blockquote><div><br></div><div>This seems like a re=
ally good thing to do. I assumed this was going to be done as part of Conce=
pts delivery, to prove workability.</div><div><br></div><div>The one questi=
on that comes to mind: Assuming the *meaning* doesn&#39;t change, would exi=
sting implementations be &quot;conforming&quot; via the &#39;as-if&#39; rul=
e? ( I assume so, but also assume I may be wrong)</div><div><br></div><div>=
Conversely, it *seems* to me that a conceptified implementation would confo=
rm with the current language, so doing it first and then proposing the chan=
ges seems viable and somewhat desirable.</div><div><br></div><div>If it&#39=
;s going to be done for C++20, it probably needs to be code-complete in the=
 next six months or so, to give the committee meetings a couple of years to=
 discuss the names used for the concepts that it is decided are useful to g=
iven names to.</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/1cec39de-0ad4-4d20-8327-8f242d6f4c04%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1cec39de-0ad4-4d20-8327-8f242d6f4c04=
%40isocpp.org</a>.<br />

------=_Part_3326_226800837.1501427700473--

------=_Part_3325_4473548.1501427700473--

.

On 30 July 2017 at 18:15, Paul Hampson <paul.hampson@pobox.com> wrote:
> On Monday, 31 July 2017 01:03:32 UTC+10, Nicol Bolas wrote:
>>
>> Concepts TS gives the language the ability to express "This function does
>> not participate in overload resolution if..." directly in the function
>> definition, via a requires clause. So, should someone go through the
>> standard library and change all of those definitions to explicitly use a
>> requires clause? Would there be any downsides to doing so? Could it make
>> implementations more difficult?
>
>
> This seems like a really good thing to do. I assumed this was going to be
> done as part of Concepts delivery, to prove workability.

There have been experiments that do that in the standard library. To
me, they prove
Concepts to be amply workable.

> The one question that comes to mind: Assuming the *meaning* doesn't change,
> would existing implementations be "conforming" via the 'as-if' rule? ( I
> assume so, but also assume I may be wrong)

Yes.

> Conversely, it *seems* to me that a conceptified implementation would
> conform with the current language, so doing it first and then proposing the
> changes seems viable and somewhat desirable.

Also yes.

> If it's going to be done for C++20, it probably needs to be code-complete in
> the next six months or so, to give the committee meetings a couple of years
> to discuss the names used for the concepts that it is decided are useful to
> given names to.


There's no need to change the current specification, it's already
concepts-compatible.
As far as utility concepts go, the Ranges TS has those.

--
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/CAFk2RUa4FaL717SsWF3QcmnXaspkPw2Np%2BdKOLhMa4uDtJixHg%40mail.gmail.com.

.

Yep, we need one or more papers for the Albuquerque meeting (mailing
deadline in October) describing the tradeoffs of different techniques
of starting to use Concepts in the standard library, and proposing
that a particular technique is the best. We already have proposals
specified in terms of Concepts, and the lack of a policy means those
proposals draw objections.

I definitely want us to be willing to merge parts of the Ranges TS
before we merge the whole thing, but I can't make that decision
unilaterally. :)

I believe Beman is also working on this kind of paper, so please
coordinate with him, at least to understand the downsides of the
obvious "just use Concepts" option.

Jeffrey

On Sun, Jul 30, 2017 at 8:03 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Now that Concepts TS is part of the C++ standard going forward, the next
> question is what to do about the standard library. The thing I want to focus
> on in this thread is not big things like iterator/algorithm concepts. Ranges
> TS already has perfectly good solutions to those.
>
> My primary concern is with the specification of functions where the standard
> currently says something to the effect of, "This function does not
> participate in overload resolution if...", followed by some list of
> requirements. At present, that logically translates into some kind of
> `std::enable_if` or `std::void_t` gymnastics. But the standard doesn't
> specify exactly what kind of gymnastics are used; it just lets the
> implementation work it out (within the bounds that implementations are
> provided).
>
> Concepts TS gives the language the ability to express "This function does
> not participate in overload resolution if..." directly in the function
> definition, via a requires clause. So, should someone go through the
> standard library and change all of those definitions to explicitly use a
> requires clause? Would there be any downsides to doing so? Could it make
> implementations more difficult?
>
> And equally importantly, some of those requirements are logically concepts,
> which other people will want to use. And the standard library doesn't define
> any concepts yet. Should we add some very basic utility concepts, perhaps
> concepts that match existing type-traits? Should we add more than just
> type-trait concepts? Again, not iterator/range/etc concepts, just smaller
> things.
>
> And on a process note, if it doesn't look like Ranges TS will make it into
> C++20, should we fast-track some of its utility concepts, so that we can
> have them available?
>
> --
> 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/405ca072-30f3-45e6-b6b1-4e09d3bd459f%40isocpp.org.

--
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/CANh-dXmimQvvEibqbNpCkMXurmZOk5Qgi%2BU6C7ThfT9pHETGNQ%40mail.gmail.com.

.

--Apple-Mail-C605E4E3-172D-42F4-AEF9-0232FCC8C5B0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

My chief concern is whether there are any ABI implications.  The current wo=
rding allows vendors to experiment with concepts to achieve the expected ef=
fects, but does not force them to ship that form if there turn out to be AB=
I-breaking implications once we have implementation experience.

Note that ABI breakage is not a show stopper for me personally, but I know =
(and support) folks for who it is.  If they tell me there is no big deal he=
re, I will keep quiet and look into the most effective concepts to support =
the library - but I would like an affirmative from the 3 main library vendo=
rs (if possible) before I am comfortable myself.

Sent from my iPhone

> On Jul 30, 2017, at 11:03 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>=20
> Now that Concepts TS is part of the C++ standard going forward, the next =
question is what to do about the standard library. The thing I want to focu=
s on in this thread is not big things like iterator/algorithm concepts. Ran=
ges TS already has perfectly good solutions to those.
>=20
> My primary concern is with the specification of functions where the stand=
ard currently says something to the effect of, "This function does not part=
icipate in overload resolution if...", followed by some list of requirement=
s. At present, that logically translates into some kind of `std::enable_if`=
 or `std::void_t` gymnastics. But the standard doesn't specify exactly what=
 kind of gymnastics are used; it just lets the implementation work it out (=
within the bounds that implementations are provided).
>=20
> Concepts TS gives the language the ability to express "This function does=
 not participate in overload resolution if..." directly in the function def=
inition, via a requires clause. So, should someone go through the standard =
library and change all of those definitions to explicitly use a requires cl=
ause? Would there be any downsides to doing so? Could it make implementatio=
ns more difficult?=20
>=20
> And equally importantly, some of those requirements are logically concept=
s, which other people will want to use. And the standard library doesn't de=
fine any concepts yet. Should we add some very basic utility concepts, perh=
aps concepts that match existing type-traits? Should we add more than just =
type-trait concepts? Again, not iterator/range/etc concepts, just smaller t=
hings.
>=20
> And on a process note, if it doesn't look like Ranges TS will make it int=
o C++20, should we fast-track some of its utility concepts, so that we can =
have them available?
> --=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.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/405ca072-30f3-45e6-b6b1-4e09d3bd459f%40isocpp.=
org.

--=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/676DF8B6-4752-404A-9A4A-B2C3436499B8%40me.com.

--Apple-Mail-C605E4E3-172D-42F4-AEF9-0232FCC8C5B0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>My chief concern is whether there =
are any ABI implications. &nbsp;The current wording allows vendors to exper=
iment with concepts to achieve the expected effects, but does not force the=
m to ship that form if there turn out to be ABI-breaking implications once =
we have implementation experience.</div><div id=3D"AppleMailSignature"><br>=
</div><div id=3D"AppleMailSignature">Note that ABI breakage is not a show s=
topper for me personally, but I know (and support) folks for who it is. &nb=
sp;If they tell me there is no big deal here, I will keep quiet and look in=
to the most effective concepts to support the library - but I would like an=
 affirmative from the 3 main library vendors (if possible) before I am comf=
ortable myself.<br><br>Sent from my iPhone</div><div><br>On Jul 30, 2017, a=
t 11:03 AM, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesso=
n@gmail.com</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><div=
 dir=3D"ltr">Now that Concepts TS is part of the C++ standard going forward=
, the next question is what to do about the standard library. The thing I w=
ant to focus on in this thread is <i>not</i> big things like iterator/algor=
ithm concepts. Ranges TS already has perfectly good solutions to those.<br>=
<br>My primary concern is with the specification of functions where the sta=
ndard currently says something to the effect of, "This function does not pa=
rticipate in overload resolution if...", followed by some list of requireme=
nts. At present, that logically translates into some kind of `std::enable_i=
f` or `std::void_t` gymnastics. But the standard doesn't specify exactly wh=
at kind of gymnastics are used; it just lets the implementation work it out=
 (within the bounds that implementations are provided).<br><br>Concepts TS =
gives the language the ability to express "This function does not participa=
te in overload resolution if..." directly in the function definition, via a=
 requires clause. So, should someone go through the standard library and ch=
ange all of those definitions to explicitly use a requires clause? Would th=
ere be any downsides to doing so? Could it make implementations more diffic=
ult? <br><br>And equally importantly, some of those requirements are logica=
lly concepts, which other people will want to use. And the standard library=
 doesn't define any concepts yet. Should we add some very basic utility con=
cepts, perhaps concepts that match existing type-traits? Should we add more=
 than just type-trait concepts? Again, not iterator/range/etc concepts, jus=
t smaller things.<br><br>And on a process note, if it doesn't look like Ran=
ges TS will make it into C++20, should we fast-track some of its utility co=
ncepts, so that we can have them available?<br></div>

<p></p>

-- <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 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/405ca072-30f3-45e6-b6b1-4e09d3bd459f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/405ca072-30f3-45e6-b6b1-4e09d3bd=
459f%40isocpp.org</a>.<br>
</div></blockquote></body></html>

<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/676DF8B6-4752-404A-9A4A-B2C3436499B8%=
40me.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/676DF8B6-4752-404A-9A4A-B2C3436499B8%40m=
e.com</a>.<br />

--Apple-Mail-C605E4E3-172D-42F4-AEF9-0232FCC8C5B0--

.

On 31 July 2017 at 00:22, Alisdair Meredith <alisdairm@me.com> wrote:
> My chief concern is whether there are any ABI implications.  The current
> wording allows vendors to experiment with concepts to achieve the expected
> effects, but does not force them to ship that form if there turn out to be
> ABI-breaking implications once we have implementation experience.
>
> Note that ABI breakage is not a show stopper for me personally, but I know
> (and support) folks for who it is.  If they tell me there is no big deal
> here, I will keep quiet and look into the most effective concepts to support
> the library - but I would like an affirmative from the 3 main library
> vendors (if possible) before I am comfortable myself.


There could possibly be ABI breakage if an implementation vendor would implement
a library function with exactly the concepts you would specify in the
standard. An example
being a tuple constructor that currently has 5 template parameters,
but would have rather
fewer with a constraint spelled exactly like the one I'd envision the
library specification having.
That might have an ABI impact, I haven't looked.

Implementation vendors are not, however, going to write the
constraints verbatim the way you
specify them. They don't need to - they can achieve the same effect
via other means (the current enable_if)
with no way for a program to detect the difference. Implementations go
to great lengths to make it impossible
for you to know how many constraints and what sort of constraints are
applied on a library function signature;
the template parameters on a constructor are something you can't
provide, so that's invisible, except perhaps in the ABI.
The non-constructor constraints are placed on the return type. If an
implementation turns those constraints
into concepts, you won't be able to tell the difference, programmatically.

Turning the current "shall not participate in overload resolution
unless..." clauses into concepts doesn't change
anything in an existing implementation. It doesn't help any library
implementation in any way. Whether it helps
casual readers of the standard is another matter. This will of course
mean that implementation vendors will
have little to no interest in verifying that pointless changes from
"shall not participate.." into concepts don't
break anything, and we might spend our time better elsewhere.

The "shall not participate in overload resolution" clauses were
designed to be compatible with concepts,
and they are. Changing them into requires-clauses is an exercise that
causes an incredible amount of churn
with no practical effect. Changing them into multiple micro-concepts
is a downright mistake, and takes
us back to the quagmire of having teeny tiny micro-concepts for every
possible individual constraint part
of every library function, and worse, mini-concepts that capture the
combinations thereof.

Leave the specification alone, and use concepts when it actually
brings a benefit.

--
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/CAFk2RUZ%2B_2UJVEsUGtUTfwYzwKLyy3-5JJoh%2B_dLVkdcusy8YA%40mail.gmail.com.

.