Topic: P0225, Concepts, and The Elephant in the Room
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 8 Feb 2016 20:05:14 -0800 (PST)
Raw View
------=_Part_3054_697603632.1454990714224
Content-Type: multipart/alternative;
boundary="----=_Part_3055_779217756.1454990714225"
------=_Part_3055_779217756.1454990714225
Content-Type: text/plain; charset=UTF-8
P0225 was released recently. It's a discussion about how C++17 needs to
have concepts in it, and we shouldn't delay integrating the Concepts TS
into the standard just because of minor things like having little
experience in using it in exactly the kinds of systems it was designed for
(ie: the standard library).
It's an interesting argument. However, I find one key point missing.
Namely, there is no mention of the fact that Concepts *isn't finished yet*.
When the "concepts-lite" direction was announced, it was done so on the
idea that it would be one part of a full Concepts whole. It was starting
with "constraints", which would be applied to template arguments, making it
possible to give more reasonable error messages and so forth. But this was
only ever half of the "Concepts" package.
Constraints only constrain the instantiation of concepts; they never
properly constrained the *implementation*. But that was fine; we all knew
that concepts-lite was only part of the package, and we assumed that the
full package would eventually happen.
So... where is it?
Years ago, I asked a question on the Concepts forum
<https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/2y6WkcfI0Mk>
about one of the earlier forms of "concepts-lite". My biggest concern at
the time was the transition from the minimal "concepts-lite" to the
full-blown "Concepts" solution, particularly in terms of implementation
checking. My concern then was whether the
"concepts-as-constexpr-function-calls" approach would be something that the
compiler could effectively turn into an implementation check. Could the
compiler actually go through a function call and check each use of a
template parameter, or group of them, against the expressions defined by a
mere constexpr function?
Everyone's focused on constraints because it allows us to bypass that
Godawful `enable_if` crap. But nobody seems to care about actually
completing the feature called "Concepts".
I'm concerned about the fact that the Concepts Study Group doesn't really
seem to care about implementation checking. I'm concerned that there does
not appear to have been any research done about whether the design of
Concepts TS would still allow compilers to be able to implement
implementation checking. Does the Concepts SG even *meet* anymore?
Basically, I get the very strong feeling that the Concepts SG said, "Here's
basic concept checking. We're done now."
Unless we have some reasonable assurance that the concepts feature as
designed can still be completed, unless we know that a Concepts TS 2 could
be written that provides implementation checking, it would be a mistake to
adopt Concepts into C++. We need to know that the feature as designed can
be completed.
I'm not saying that we should wait until there is a TS that has
implementation checking. But I am saying that we should wait until we have
reasonable assurances that such a TS is *possible*, that the current
concepts design is compatible with the idea. Has anyone done the research
here?
Until said research is done, I would say that adoption of the Concepts TS
is premature, no matter how useful it might be in the short term. The
absolute *last* thing we need from C++17 is yet another short-sighted
feature with a built-in flaw.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3055_779217756.1454990714225
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">P0225 was released recently. It's a discussion about h=
ow C++17 needs to have concepts in it, and we shouldn't delay integrati=
ng the Concepts TS into the standard just because of minor things like havi=
ng little experience in using it in exactly the kinds of systems it was des=
igned for (ie: the standard library).<br><br>It's an interesting argume=
nt. However, I find one key point missing. Namely, there is no mention of t=
he fact that Concepts <i>isn't finished yet</i>.<br><br>When the "=
concepts-lite" direction was announced, it was done so on the idea tha=
t it would be one part of a full Concepts whole. It was starting with "=
;constraints", which would be applied to template arguments, making it=
possible to give more reasonable error messages and so forth. But this was=
only ever half of the "Concepts" package.<br><br>Constraints onl=
y constrain the instantiation of concepts; they never properly constrained =
the <i>implementation</i>. But that was fine; we all knew that concepts-lit=
e was only part of the package, and we assumed that the full package would =
eventually happen.<br><br>So... where is it?<br><br>Years ago, <a href=3D"h=
ttps://groups.google.com/a/isocpp.org/forum/#!topic/concepts/2y6WkcfI0Mk">I=
asked a question on the Concepts forum</a> about one of the earlier forms =
of "concepts-lite". My biggest concern at the time was the transi=
tion from the minimal "concepts-lite" to the full-blown "Con=
cepts" solution, particularly in terms of implementation checking. My =
concern then was whether the "concepts-as-constexpr-function-calls&quo=
t; approach would be something that the compiler could effectively turn int=
o an implementation check. Could the compiler actually go through a functio=
n call and check each use of a template parameter, or group of them, agains=
t the expressions defined by a mere constexpr function?<br><br>Everyone'=
;s focused on constraints because it allows us to bypass that Godawful `ena=
ble_if` crap. But nobody seems to care about actually completing the featur=
e called "Concepts".<br><br>I'm concerned about the fact that=
the Concepts Study Group doesn't really seem to care about implementat=
ion checking. I'm concerned that there does not appear to have been any=
research done about whether the design of Concepts TS would still allow co=
mpilers to be able to implement implementation checking. Does the Concepts =
SG even <i>meet</i> anymore? Basically, I get the very strong feeling that =
the Concepts SG said, "Here's basic concept checking. We're do=
ne now."<br><br>Unless we have some reasonable assurance that the conc=
epts feature as=20
designed can still be completed, unless we know that a Concepts TS 2=20
could be written that provides implementation checking, it would be a=20
mistake to adopt Concepts into C++. We need to know that the feature as=20
designed can be completed.<br><br>I'm not saying that we should wait un=
til there is a TS that has implementation checking. But I am saying that we=
should wait until we have reasonable assurances that such a TS is <i>possi=
ble</i>, that the current concepts design is compatible with the idea. Has =
anyone done the research here?<br><br>Until said research is done, I would =
say that adoption of the Concepts TS is premature, no matter how useful it =
might be in the short term. The absolute <i>last</i> thing we need from C++=
17 is yet another short-sighted feature with a built-in flaw.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_3055_779217756.1454990714225--
------=_Part_3054_697603632.1454990714224--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Tue, 09 Feb 2016 09:46:14 +0100
Raw View
On 02/09/2016 05:05 AM, Nicol Bolas wrote:
> P0225 was released recently. It's a discussion about how C++17 needs
> to have concepts in it, and we shouldn't delay integrating the
> Concepts TS into the standard just because of minor things like
> having little experience in using it in exactly the kinds of systems
> it was designed for (ie: the standard library).
>
> It's an interesting argument. However, I find one key point missing.
> Namely, there is no mention of the fact that Concepts /isn't finished
> yet/.
>
> When the "concepts-lite" direction was announced, it was done so on
> the idea that it would be one part of a full Concepts whole. It was
> starting with "constraints", which would be applied to template
> arguments, making it possible to give more reasonable error messages
> and so forth. But this was only ever half of the "Concepts" package.
>
> Constraints only constrain the instantiation of concepts; they never
> properly constrained the /implementation/. But that was fine; we all
> knew that concepts-lite was only part of the package, and we assumed
> that the full package would eventually happen.
>
> So... where is it?
Well, Doug Gregor's earlier concepts work did provide the full package.
Of course, it was substantially more involved than what we have now.
That said, maybe I overlooked something, but I never had the
understanding that a full concepts package was promised for the
future. And given the experience with Doug's proposal, I'm doubtful
we can turn on implementation checking with today's concepts on
real-world code without massive breakage.
Jens
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Tue, 9 Feb 2016 12:46:53 -0600
Raw View
On 2/8/2016 10:05 PM, Nicol Bolas wrote:
> P0225 was released recently. It's a discussion about how C++17 needs to
> have concepts in it, and we shouldn't delay integrating the Concepts TS
> into the standard just because of minor things like having little
> experience in using it in exactly the kinds of systems it was designed
> for (ie: the standard library).
I'm a bit unclear on why Concepts needs to be in C++17 rather than
merely a (finalized) TS. The important part is whether compilers support
it, right? While having them in a TS would probably make people more
hesitant to use Concepts (for fear they might change dramatically), I
don't think it would completely stop them. The benefits of Concepts are
clear enough that people would probably walk over broken glass to use them.
While I was saddened to see Concepts dropped from C++11, I completely
understand why that happened. I still hope to see something similar in
the future of C++ (concept maps and axioms were especially interesting),
and like you, I'm not totally sure that Concepts Lite can form a basis
for the rest of C++11's concept features.
- Jim
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 9 Feb 2016 11:30:27 -0800
Raw View
--001a1136988c8db828052b5b595d
Content-Type: text/plain; charset=UTF-8
On Mon, Feb 8, 2016 at 8:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> P0225 was released recently. It's a discussion about how C++17 needs to
> have concepts in it, and we shouldn't delay integrating the Concepts TS
> into the standard just because of minor things like having little
> experience in using it in exactly the kinds of systems it was designed for
> (ie: the standard library).
>
> It's an interesting argument. However, I find one key point missing.
> Namely, there is no mention of the fact that Concepts *isn't finished yet*
> .
>
I agree with you. We've been wanting language-level concepts for 15-20
years. We've had more complete iterations (C++0x concepts) that were cut
last minute, which included implementation-checking and complete standard
library integration. Ultimately, while I admittedly favor C++0x-style
concepts over current concepts, it really was huge and would have been
risky to all go into C++11 at once -- scaling back probably was needed for
the sake of being conservative, spreading out additions over a couple of
standards (instead, though, it was effectively scrapped). Let's not make
the opposite class of mistake this time and rush to get this alternate take
on Concepts in too early. People who want to use Concepts in its current
state can do so. There's little stopping them. It doesn't need to be in
C++17 for that and I don't think Concepts will be greatly hurt by that. At
the moment, not only do we not have a standard library that uses them, nor
implementation checking, but there isn't even really a clear path *forward*
for implementation checking. In my personal opinion, we likely will not
ever get it due to the approach to concept specification and the fact that
it is not changing how lookup is done from within a constrained function,
and that the constraints aren't isomorphic with pseudo-signatures. The only
sensible way for doing implementation-checking, in my opinion, is the way
that people have done it for years -- archetypes.
On Mon, Feb 8, 2016 at 8:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Constraints only constrain the instantiation of concepts; they never
> properly constrained the *implementation*. But that was fine; we all knew
> that concepts-lite was only part of the package, and we assumed that the
> full package would eventually happen.
>
This is somewhat of a misconception. While C++0x concepts considered
checking of definitions to be extremely important, Concepts-Lite never
really took that quite so seriously. A lot of people (including one
well-respected generic programmer I consider an authority on the subject)
actually think the lack of implementation-checking is probably fine. I do
not share in that view. I think it is extremely important, both for
existing generic programmers and "Joe Blow" programmer.
On Mon, Feb 8, 2016 at 8:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Everyone's focused on constraints because it allows us to bypass that
> Godawful `enable_if` crap. But nobody seems to care about actually
> completing the feature called "Concepts".
>
+1 Getting rid of SFINAE hacks is great... but that alone is mostly just a
superficial change, as positive of a superficial change as it is. That
aspect does not significantly change what we are able to represent, but I
worry that its chosen approach makes it very difficult to ever get proper
checking of implementations. You really need to be thinking about it from
the start -- we can't just assume that it can be tacked-on later.
On Mon, Feb 8, 2016 at 8:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> I'm concerned about the fact that the Concepts Study Group doesn't really
> seem to care about implementation checking. I'm concerned that there does
> not appear to have been any research done about whether the design of
> Concepts TS would still allow compilers to be able to implement
> implementation checking.
>
There is a little bit of research. Here's one of Larisse's talks on the
topic, from C++Now 2014 https://www.youtube.com/watch?v=bEjtAYIuP94
On Mon, Feb 8, 2016 at 8:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Unless we have some reasonable assurance that the concepts feature as
> designed can still be completed, unless we know that a Concepts TS 2 could
> be written that provides implementation checking, it would be a mistake to
> adopt Concepts into C++.
>
+1 It is my understanding that we are in the minority, though. Or at the
very least, some of the most important people have the opposite opinion. If
you feel strongly about this, I encourage you to write a paper about it
(deadline is Friday) and/or try to make it to Jacksonville.
On Mon, Feb 8, 2016 at 8:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> I'm not saying that we should wait until there is a TS that has
> implementation checking. But I am saying that we should wait until we have
> reasonable assurances that such a TS is *possible*, that the current
> concepts design is compatible with the idea.
>
I agree. This is why I'm extremely frustrated that we didn't just scale
back C++0x concepts as opposed to moving toward a design that doesn't
current;y have a clear path forward with respect to the checking of
definitions. With a scaled-back C++0x concepts, we would have had a very
clear path forward, as it was actually implemented and usable and had a
fully constrained standard library. There's not really any chance for that
happening now, but at the very least we shouldn't settle for something that
may potentially preclude implementation checking.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a1136988c8db828052b5b595d
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 M=
on, Feb 8, 2016 at 8:05 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr">P0225 was released recently=
.. It's a discussion about how C++17 needs to have concepts in it, and w=
e shouldn't delay integrating the Concepts TS into the standard just be=
cause of minor things like having little experience in using it in exactly =
the kinds of systems it was designed for (ie: the standard library).<br><br=
>It's an interesting argument. However, I find one key point missing. N=
amely, there is no mention of the fact that Concepts <i>isn't finished =
yet</i>.</div></blockquote><div>=C2=A0</div><div>I agree with you. We'v=
e been wanting language-level concepts for 15-20 years. We've had more =
complete iterations (C++0x concepts) that were cut last minute, which inclu=
ded implementation-checking and complete standard library integration. Ulti=
mately, while I admittedly favor C++0x-style concepts over current concepts=
, it really was huge and would have been risky to all go into C++11 at once=
-- scaling back probably was needed for the sake of being conservative, sp=
reading out additions over a couple of standards (instead, though, it was e=
ffectively scrapped). Let's not make the opposite class of mistake this=
time and rush to get this alternate take on Concepts in too early. People =
who want to use Concepts in its current state can do so. There's little=
stopping them. It doesn't need to be in C++17 for that and I don't=
think Concepts will be greatly hurt by that. At the moment, not only do we=
not have a standard library that uses them, nor implementation checking, b=
ut there isn't even really a clear path <i>forward</i> for implementati=
on checking. In my personal opinion, we likely will not ever get it due to =
the approach to concept specification and the fact that it is not changing =
how lookup is done from within a constrained function, and that the constra=
ints aren't isomorphic with pseudo-signatures. The only sensible way fo=
r doing implementation-checking, in my opinion, is the way that people have=
done it for years -- archetypes.</div><div><br></div><div>On Mon, Feb 8, 2=
016 at 8:05 PM, Nicol Bolas=C2=A0<span dir=3D"ltr"><<a href=3D"mailto:jm=
ckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span>=C2=
=A0wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr">Constraints only constrain=
the instantiation of concepts; they never properly constrained the <i>impl=
ementation</i>. But that was fine; we all knew that concepts-lite was only =
part of the package, and we assumed that the full package would eventually =
happen.<br></div></blockquote><div><br></div><div>This is somewhat of a mis=
conception. While C++0x concepts considered checking of definitions to be e=
xtremely important, Concepts-Lite never really took that quite so seriously=
.. A lot of people (including one well-respected generic programmer I consid=
er an authority on the subject) actually think the lack of implementation-c=
hecking is probably fine. I do not share in that view. I think it is extrem=
ely important, both for existing generic programmers and "Joe Blow&quo=
t; programmer.</div><div><br></div><div>On Mon, Feb 8, 2016 at 8:05 PM, Nic=
ol Bolas=C2=A0<span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" =
target=3D"_blank">jmckesson@gmail.com</a>></span>=C2=A0wrote:=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr">Everyone's focused on constraints be=
cause it allows us to bypass that Godawful `enable_if` crap. But nobody see=
ms to care about actually completing the feature called "Concepts"=
;.<br></div></blockquote><div><br></div><div>+1 Getting rid of SFINAE hacks=
is great... but that alone is mostly just a superficial change, as positiv=
e of a superficial change as it is. That aspect does not significantly chan=
ge what we are able to represent, but I worry that its chosen approach make=
s it very difficult to ever get proper checking of implementations. You rea=
lly need to be thinking about it from the start -- we can't just assume=
that it can be tacked-on later.</div><div><br></div><div><div>On Mon, Feb =
8, 2016 at 8:05 PM, Nicol Bolas=C2=A0<span dir=3D"ltr"><<a href=3D"mailt=
o:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span>=
=C2=A0wrote:=C2=A0</div></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">I'm con=
cerned about the fact that the Concepts Study Group doesn't really seem=
to care about implementation checking. I'm concerned that there does n=
ot appear to have been any research done about whether the design of Concep=
ts TS would still allow compilers to be able to implement implementation ch=
ecking.</div></blockquote><div><br></div><div>There is a little bit of rese=
arch. Here's one of Larisse's talks on the topic, from C++Now 2014 =
<a href=3D"https://www.youtube.com/watch?v=3DbEjtAYIuP94">https://www.youtu=
be.com/watch?v=3DbEjtAYIuP94</a></div><div><br></div><div>On Mon, Feb 8, 20=
16 at 8:05 PM, Nicol Bolas=C2=A0<span dir=3D"ltr"><<a href=3D"mailto:jmc=
kesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span>=C2=
=A0wrote:=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Unless we have some =
reasonable assurance that the concepts feature as=20
designed can still be completed, unless we know that a Concepts TS 2=20
could be written that provides implementation checking, it would be a=20
mistake to adopt Concepts into C++.</div></blockquote><div><br></div><div>+=
1 It is my understanding that we are in the minority, though. Or at the ver=
y least, some of the most important people have the opposite opinion. If yo=
u feel strongly about this, I encourage you to write a paper about it (dead=
line is Friday) and/or try to make it to Jacksonville.</div><div><br></div>=
<div>On Mon, Feb 8, 2016 at 8:05 PM, Nicol Bolas=C2=A0<span dir=3D"ltr"><=
;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.c=
om</a>></span>=C2=A0wrote:=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">=
I'm not saying that we should wait until there is a TS that has impleme=
ntation checking. But I am saying that we should wait until we have reasona=
ble assurances that such a TS is <i>possible</i>, that the current concepts=
design is compatible with the idea.<br></div></blockquote><div><br></div><=
div>I agree. This is why I'm extremely frustrated that we didn't ju=
st scale back C++0x concepts as opposed to moving toward a design that does=
n't current;y have a clear path forward with respect to the checking of=
definitions. With a scaled-back C++0x concepts, we would have had a very c=
lear path forward, as it was actually implemented and usable and had a full=
y constrained standard library. There's not really any chance for that =
happening now, but at the very least we shouldn't settle for something =
that may potentially preclude implementation checking.</div></div></div></d=
iv>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a1136988c8db828052b5b595d--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 9 Feb 2016 14:14:04 -0600
Raw View
On Tue, Feb 9, 2016 at 12:46 PM, Jim Porter <jvp4846@g.rit.edu> wrote:
> I'm a bit unclear on why Concepts needs to be in C++17 rather than merely a
> (finalized) TS. The important part is whether compilers support it, right?
> While having them in a TS would probably make people more hesitant to use
> Concepts (for fear they might change dramatically), I don't think it would
> completely stop them.
IIUC, P0225's point is that, the immediate standardization of the
Concept-lite's interface is more important, which gives the library
designers the power to specify the concepts across their libraries
and to specify the signatures of their functions using Concepts-lite's
notion.
But whether the interface portion of Concepts-lite is ready is also
questionable, see n4434
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4434.pdf
section 3. We spotted the issue caused by dual-syntax right in
the Ranges TS, and Ranges TS switched to use the function style
concepts everywhere. The two syntax are not fully composable.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Tue, 09 Feb 2016 21:45:55 +0100
Raw View
On 02/09/2016 09:14 PM, Zhihao Yuan wrote:
> But whether the interface portion of Concepts-lite is ready is also
> questionable, see n4434
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4434.pdf
>
> section 3. We spotted the issue caused by dual-syntax right in
> the Ranges TS, and Ranges TS switched to use the function style
> concepts everywhere.
Hm... N4434 says:
"We chose to keep the variable concept style, as it has less syntactic noise
(no return; no argument list, . . . ) than function concepts."
Were there any particular reasons why function-style concepts
were chosen for the Ranges TS, given this argument for variable
concepts in N4434?
Thanks,
Jens
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Zhihao Yuan <zy@miator.net>
Date: Tue, 9 Feb 2016 14:56:14 -0600
Raw View
On Tue, Feb 9, 2016 at 2:45 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
>
> Hm... N4434 says:
>
> "We chose to keep the variable concept style, as it has less syntactic noise
> (no return; no argument list, . . . ) than function concepts."
>
> Were there any particular reasons why function-style concepts
> were chosen for the Ranges TS, given this argument for variable
> concepts in N4434?
Because in the current specification, only function-style concepts
can be overloaded (on template arguments), and Range TS
needs this. Variable concepts cannot.
I would like to see one way to define concepts, it uses variable
style, hopefully with the `bool` specifier, and can be overloaded.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Christopher Jefferson <chris@bubblescope.net>
Date: Tue, 9 Feb 2016 23:47:03 +0000
Raw View
--001a114023863bde6d052b5eef26
Content-Type: text/plain; charset=UTF-8
On 9 Feb 2016 7:30 pm, "'Matt Calabrese' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:
>
> On Mon, Feb 8, 2016 at 8:05 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>> Constraints only constrain the instantiation of concepts; they never
properly constrained the implementation. But that was fine; we all knew
that concepts-lite was only part of the package, and we assumed that the
full package would eventually happen.
>
>
> This is somewhat of a misconception. While C++0x concepts considered
checking of definitions to be extremely important, Concepts-Lite never
really took that quite so seriously. A lot of people (including one
well-respected generic programmer I consider an authority on the subject)
actually think the lack of implementation-checking is probably fine. I do
not share in that view. I think it is extremely important, both for
existing generic programmers and "Joe Blow" programmer.
I put a lot of work into conceptising both the C++ standard library in GCC,
and some of my own code, with C++0x concepts.
Personally, I feel they will never work well in C++, and concepts lite is a
good tradeoff. The problem with checking concepts is that C++ is such a
complicated language, that writing concepts which exactly capture use cases
is almost impossible, and often larger than the function being concepted.
For example, one issue among many is making sure you don't block efficient
overloads (such as move constructors) is easy to miss, and hard to debug
later. This problem doesn't arise in concepts lite. Of course, some stupid
set of overloads might cause a function which passes concepts then fail to
compile, but that is the tradeoff.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a114023863bde6d052b5eef26
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On 9 Feb 2016 7:30 pm, "'Matt Calabrese' via ISO C++ Standard =
- Future Proposals" <<a href=3D"mailto:std-proposals@isocpp.org">st=
d-proposals@isocpp.org</a>> wrote:<br>
><br>
> On Mon, Feb 8, 2016 at 8:05 PM, Nicol Bolas=C2=A0<<a href=3D"mailto=
:jmckesson@gmail.com">jmckesson@gmail.com</a>>=C2=A0wrote:<br>
>><br>
>> Constraints only constrain the instantiation of concepts; they nev=
er properly constrained the implementation. But that was fine; we all knew =
that concepts-lite was only part of the package, and we assumed that the fu=
ll package would eventually happen.<br>
><br>
><br>
> This is somewhat of a misconception. While C++0x concepts considered c=
hecking of definitions to be extremely important, Concepts-Lite never reall=
y took that quite so seriously. A lot of people (including one well-respect=
ed generic programmer I consider an authority on the subject) actually thin=
k the lack of implementation-checking is probably fine. I do not share in t=
hat view. I think it is extremely important, both for existing generic prog=
rammers and "Joe Blow" programmer.</p>
<p dir=3D"ltr">I put a lot of work into conceptising both the C++ standard =
library in GCC, and some of my own code, with C++0x concepts.</p>
<p dir=3D"ltr">Personally, I feel they will never work well in C++, and con=
cepts lite is a good tradeoff. The problem with checking concepts is that C=
++ is such a complicated language, that writing concepts which exactly capt=
ure use cases is almost impossible, and often larger than the function bein=
g concepted.</p>
<p dir=3D"ltr">For example, one issue among many is making sure you don'=
;t block efficient overloads (such as move constructors) is easy to miss, a=
nd hard to debug later. This problem doesn't arise in concepts lite. Of=
course, some stupid set of overloads might cause a function which passes c=
oncepts then fail to compile, but that is the tradeoff.</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a114023863bde6d052b5eef26--
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 9 Feb 2016 17:17:43 -0800
Raw View
--e89a8fb1fca8775135052b6033d8
Content-Type: text/plain; charset=UTF-8
On Tue, Feb 9, 2016 at 3:47 PM, Christopher Jefferson <chris@bubblescope.net
> wrote:
> The problem with checking concepts is that C++ is such a complicated
> language, that writing concepts which exactly capture use cases is almost
> impossible, and often larger than the function being concepted.
>
I think "almost impossible" is a bit of an overstatement, but yes it's
hard. To me, that's precisely one of the reasons why I think it is
important that we actually get such checking. It's very hard to correctly
specify concept requirements properly and so I want the compiler to help,
otherwise I have to manually (and in an error prone manner) create an
archetype, and instantiate my templates. In practice, that process is
burdensome enough that I rarely do it, and I know that I'm far from unique
in this respect. For the most part, the only people I know who are
disciplined enough to do it all of the time are hardcore Boost fellows. As
I personally see it, a concepts language feature should help write properly
constrained code, and while on a superficial level Concepts TS does this by
improving syntax over direct SFINAE and aiding in overloading, a lot of the
complexity is still there, even for day-to-day uses, and I worry that its
current design prevents us from getting much beyond that.
When I write generic code in current C++, I constrain it using (bad word
warning) SFINAE. Yes, it really, really stinks, but I get by... however,
the disgusting syntax and tricks that are required for that are not, in my
opinion, the *really* bad part of writing generic code in this way in C++.
The really scary part is that I may incorrectly specify the constraints,
and it's very subtle if that's the case. As well, if and when I screw it
up, users can potentially go back to seeing a pretty nasty template error
spew. Implementation-checking eliminates this class of mistake.
So while the Concepts TS is pretty good at removing manual, nasty SFINAE
hacks, I'm hesitant to put it into the language at this time if it
precludes ever getting definition checking, and given how constraints are
specified, I personally do not see a clear path forward for such checking
actually coming. This compounded by the lack of a conceptified standard
library makes it really scary that we would seriously consider (IMO)
rushing it into C++17. It's fine as a TS at the moment. People will use it
in its current form and we can revisit it in 2020 when it will undoubtedly
have a conceptified standard library, and either implementation-checking
will be more formally addressed, or people will be less under the
misconception that implementation-checking will definitely be coming.
On Tue, Feb 9, 2016 at 3:47 PM, Christopher Jefferson <chris@bubblescope.net
> wrote:
> For example, one issue among many is making sure you don't block efficient
> overloads (such as move constructors) is easy to miss, and hard to debug
> later.
>
Assuming you go through a concept map when in a constrained template, then
yeah, that can come up (this isn't necessarily the case, although I do
personally believe this is how it would be done, though even 0x concepts
strayed or considered straying from this in some contexts for that reason,
iirc). Even if when going through a map you accidentally pull in a copy
where a move would have been okay due to how the concept was specified,
your constrained template is at least still correct (short of violating
complexity constraints), it just has a copy instead of a move. It's like if
you needlessly copy in unconstrained code when a move would have been fine
(though admittedly more subtle in the cases we're talking about). Yeah,
that's unfortunate, but I'd favor having something correct, first and
foremost.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--e89a8fb1fca8775135052b6033d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 9, 2016 at 3:47 PM, Christopher Jefferson <span dir=3D"ltr"><<a =
href=3D"mailto:chris@bubblescope.net" target=3D"_blank">chris@bubblescope.n=
et</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr=
">The problem with checking concepts is that C++ is such a complicated lang=
uage, that writing concepts which exactly capture use cases is almost impos=
sible, and often larger than the function being concepted.<br></p></span></=
blockquote><div>I think "almost impossible" is a bit of an overst=
atement, but yes it's hard. To me, that's precisely one of the reas=
ons why I think it is important that we actually get such checking. It'=
s very hard to correctly specify concept requirements properly and so I wan=
t the compiler to help, otherwise I have to manually (and in an error prone=
manner) create an archetype, and instantiate my templates. In practice, th=
at process is burdensome enough that I rarely do it, and I know that I'=
m far from unique in this respect. For the most part, the only people I kno=
w who are disciplined enough to do it all of the time are hardcore Boost fe=
llows. As I personally see it, a concepts language feature should help writ=
e properly constrained code, and while on a superficial level Concepts TS d=
oes this by improving syntax over direct SFINAE and aiding in overloading, =
a lot of the complexity is still there, even for day-to-day uses, and I wor=
ry that its current design prevents us from getting much beyond that.</div>=
<div><br></div><div>When I write generic code in current C++, I constrain i=
t using (bad word warning) SFINAE. Yes, it really, really stinks, but I get=
by... however, the disgusting syntax and tricks that are required for that=
are not, in my opinion, the <i>really</i>=C2=A0bad part of writing generic=
code in this way in C++. The really scary part is that I may incorrectly s=
pecify the constraints, and it's very subtle if that's the case. As=
well, if and when I screw it up, users can potentially go back to seeing a=
pretty nasty template error spew. Implementation-checking eliminates this =
class of mistake.</div><div><br></div><div>So while the Concepts TS is pret=
ty good at removing manual, nasty SFINAE hacks, I'm hesitant to put it =
into the language at this time if it precludes ever getting definition chec=
king, and given how constraints are specified, I personally do not see a cl=
ear path forward for such checking actually coming. This compounded by the =
lack of a conceptified standard library makes it really scary that we would=
seriously consider (IMO) rushing it into C++17. It's fine as a TS at t=
he moment. People will use it in its current form and we can revisit it in =
2020 when it will undoubtedly have a conceptified standard library, and eit=
her implementation-checking will be more formally addressed, or people will=
be less under the misconception that implementation-checking will definite=
ly be coming.</div><div><br></div><div>On Tue, Feb 9, 2016 at 3:47 PM, Chri=
stopher Jefferson=C2=A0<span dir=3D"ltr"><<a href=3D"mailto:chris@bubble=
scope.net" target=3D"_blank">chris@bubblescope.net</a>></span>=C2=A0wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr"></p></span>
<p dir=3D"ltr">For example, one issue among many is making sure you don'=
;t block efficient overloads (such as move constructors) is easy to miss, a=
nd hard to debug later.</p></blockquote><div>Assuming you go through a conc=
ept map when in a constrained template, then yeah, that can come up (this i=
sn't necessarily the case, although I do personally believe this is how=
it would be done, though even 0x concepts strayed or considered straying f=
rom this in some contexts for that reason, iirc). Even if when going throug=
h a map you accidentally pull in a copy where a move would have been okay d=
ue to how the concept was specified, your constrained template is at least =
still correct (short of violating complexity constraints), it just has a co=
py instead of a move. It's like if you needlessly copy in unconstrained=
code when a move would have been fine (though admittedly more subtle in th=
e cases we're talking about). Yeah, that's unfortunate, but I'd=
favor having something correct, first and foremost.<br></div></div></div><=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--e89a8fb1fca8775135052b6033d8--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 10 Feb 2016 18:51:40 +0100
Raw View
This is a multi-part message in MIME format.
--------------010403030406080604090707
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/02/2016 21:56, Zhihao Yuan a =C3=A9crit :
> On Tue, Feb 9, 2016 at 2:45 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
>> Hm... N4434 says:
>>
>> "We chose to keep the variable concept style, as it has less syntactic n=
oise
>> (no return; no argument list, . . . ) than function concepts."
>>
>> Were there any particular reasons why function-style concepts
>> were chosen for the Ranges TS, given this argument for variable
>> concepts in N4434?
> Because in the current specification, only function-style concepts
> can be overloaded (on template arguments), and Range TS
> needs this. Variable concepts cannot.
>
> I would like to see one way to define concepts, it uses variable
> style, hopefully with the `bool` specifier, and can be overloaded.
>
I believe that there is a simple solution, concepts are a different=20
thing than nullary functions or variables that can be specialized as=20
structs does. I see a concept as a short hand of a boolean type trait.
I don't see the added value of stating explicitly bool as it can not be=20
another type.
Vicente
P.S. but this is out of the scope of the PO
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------010403030406080604090707
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 09/02/2016 21:56, Zhihao Yuan a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAGsORuC=3D=3D+rb1O59fky=3D4VzVVte6CeoZUkzDB-DgOoEWJtJSqg@mail.=
gmail.com"
type=3D"cite">
<pre wrap=3D"">On Tue, Feb 9, 2016 at 2:45 PM, Jens Maurer <a class=
=3D"moz-txt-link-rfc2396E" href=3D"mailto:Jens.Maurer@gmx.net"><Jens.Mau=
rer@gmx.net></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">
Hm... N4434 says:
"We chose to keep the variable concept style, as it has less syntactic nois=
e
(no return; no argument list, . . . ) than function concepts."
Were there any particular reasons why function-style concepts
were chosen for the Ranges TS, given this argument for variable
concepts in N4434?
</pre>
</blockquote>
<pre wrap=3D"">
Because in the current specification, only function-style concepts
can be overloaded (on template arguments), and Range TS
needs this. Variable concepts cannot.
I would like to see one way to define concepts, it uses variable
style, hopefully with the `bool` specifier, and can be overloaded.
</pre>
</blockquote>
<font size=3D"+1">I believe that there is a simple solution, concepts
are a different thing than nullary functions or variables that can
be specialized as structs does. I see a concept as a short hand of
a boolean type trait.<br>
=C2=A0<br>
I don't see the added value of stating explicitly bool as it can
not be another type.<br>
<br>
Vicente<br>
<br>
P.S. but this is out of the scope of the PO<br>
<br>
</font>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------010403030406080604090707--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 10 Feb 2016 12:15:32 -0600
Raw View
--001a113ed58a6c26ee052b6e6b8b
Content-Type: text/plain; charset=UTF-8
On Feb 10, 2016 11:53 AM, "Vicente J. Botet Escriba" <
vicente.botet@wanadoo.fr> wrote:
>
>> style, hopefully with the `bool` specifier, and can be overloaded.
>>
> I don't see the added value of stating explicitly bool as it can not be
another type.
>
I find that I missed the "out" in my "without" in my typing... Sorry about
that.
Agreed.
>
> P.S. but this is out of the scope of the PO
>
Yes.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113ed58a6c26ee052b6e6b8b
Content-Type: text/html; charset=UTF-8
<p dir="ltr"><br>
On Feb 10, 2016 11:53 AM, "Vicente J. Botet Escriba" <<a href="mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a>> wrote:<br>
><br>
>> style, hopefully with the `bool` specifier, and can be overloaded.<br>
>><br>
> I don't see the added value of stating explicitly bool as it can not be another type.<br>
></p>
<p dir="ltr">I find that I missed the "out" in my "without" in my typing... Sorry about that.</p>
<p dir="ltr">Agreed.</p>
<p dir="ltr">><br>
> P.S. but this is out of the scope of the PO<br>
></p>
<p dir="ltr">Yes.</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="https://groups.google.com/a/isocpp.org/group/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--001a113ed58a6c26ee052b6e6b8b--
.
Author: Nevin Liber <nevin@cplusplusguy.com>
Date: Wed, 10 Feb 2016 12:19:10 -0600
Raw View
--001a113f5facdb5706052b6e7a3d
Content-Type: text/plain; charset=UTF-8
On 10 February 2016 at 11:51, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> I believe that there is a simple solution, concepts are a different thing
> than nullary functions or variables that can be specialized as structs
> does. I see a concept as a short hand of a boolean type trait.
>
> I don't see the added value of stating explicitly bool as it can not be
> another type.
>
And if that turns out to be true we can address that in a backwards
compatible way in the future.
Otherwise, we are in the situation we had with constexpr.
--
Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>>
+1-847-691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113f5facdb5706052b6e7a3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 10 February 2016 at 11:51, Vicente J. Botet Escriba <sp=
an dir=3D"ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_b=
lank">vicente.botet@wanadoo.fr</a>></span> wrote:<br><div class=3D"gmail=
_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><span>
<div><span style=3D"font-size:large">I believe that there is a simple s=
olution, concepts
are a different thing than nullary functions or variables that can
be specialized as structs does. I see a concept as a short hand of
a boolean type trait.</span><br></div></span><font size=3D"+1">
=C2=A0<br>
I don't see the added value of stating explicitly bool as it can
not be another type.</font></div></blockquote><div><br></div><div>And=
if that turns out to be true we can address that in a backwards compatible=
way in the future.</div><div><br></div><div>Otherwise, we are in the situa=
tion we had with constexpr.<br clear=3D"all"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature"><div dir=3D"ltr">=C2=A0Nevin ":-)" Liber=
=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@cplusplusguy.com</a>>=C2=A0 +1-847-691-1404<br></div></div>
</div></div></div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a113f5facdb5706052b6e7a3d--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 10 Feb 2016 22:29:12 +0100
Raw View
This is a multi-part message in MIME format.
--------------030708030505010108040403
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 10/02/2016 19:19, Nevin Liber a =C3=A9crit :
> On 10 February 2016 at 11:51, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
> I believe that there is a simple solution, concepts are a
> different thing than nullary functions or variables that can be
> specialized as structs does. I see a concept as a short hand of a
> boolean type trait.
>
> I don't see the added value of stating explicitly bool as it can
> not be another type.
>
>
> And if that turns out to be true we can address that in a backwards=20
> compatible way in the future.
>
Right. But why do we need it now?
> Otherwise, we are in the situation we had with constexpr.
>
>
Could you elaborate?
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------030708030505010108040403
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 10/02/2016 19:19, Nevin Liber a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAGg_6+M-m=3D7HFVYP7RJ4ZJMkB8N4wdEY=3DrDtobpnRHyFUutUVQ@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">On 10 February 2016 at 11:51, Vicente J. Botet
Escriba <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span>
wrote:<br>
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><span>
<div><span style=3D"font-size:large">I believe that
there is a simple solution, concepts are a
different thing than nullary functions or
variables that can be specialized as structs does.
I see a concept as a short hand of a boolean type
trait.</span><br>
</div>
</span><font size=3D"+1"> =C2=A0<br>
I don't see the added value of stating explicitly bool
as it can not be another type.</font></div>
</blockquote>
<div><br>
</div>
<div>And if that turns out to be true we can address that in
a backwards compatible way in the future.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
Right. But why do we need it now?<br>
<blockquote
cite=3D"mid:CAGg_6+M-m=3D7HFVYP7RJ4ZJMkB8N4wdEY=3DrDtobpnRHyFUutUVQ@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>Otherwise, we are in the situation we had with
constexpr.<br clear=3D"all">
<div><br>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
Could you elaborate?<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------030708030505010108040403--
.
Author: Nevin Liber <nevin@cplusplusguy.com>
Date: Wed, 10 Feb 2016 17:07:30 -0600
Raw View
--001a11c3db70f813c2052b728157
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 10 February 2016 at 15:29, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 10/02/2016 19:19, Nevin Liber a =C3=A9crit :
>
> On 10 February 2016 at 11:51, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> I believe that there is a simple solution, concepts are a different thin=
g
>> than nullary functions or variables that can be specialized as structs
>> does. I see a concept as a short hand of a boolean type trait.
>>
>> I don't see the added value of stating explicitly bool as it can not be
>> another type.
>>
>
> And if that turns out to be true we can address that in a backwards
> compatible way in the future.
>
> Right. But why do we need it now?
>
Why do we need yet another snowflake (a function that is slightly different
than other functions to save typing five characters) in the language?
"Because we can" is fairly weak motivation.
> Otherwise, we are in the situation we had with constexpr.
>
>
> Could you elaborate?
>
To quote Wikipedia <https://en.wikipedia.org/wiki/C%2B%2B14>: "Also, C++11
stated that all non-static member functions that were declared constexpr we=
re
also implicitly declared const, with respect to this. That has since been
removed; non-static member functions may be non-const.[7]
<https://en.wikipedia.org/wiki/C%2B%2B14#cite_note-7> However, per the
above restrictions, a non-const constexpr member function can only modify a
class member if that object's lifetime began within the constant expression
evaluation."
That was a *breaking* change. Luckily, constexpr hadn't been around all
that long, the breakage was at compile time, and "const" was optional there
was a way to write code that conformed to both C++11 and C++14. I also
think that some vendors back ported this into their C++11 compilers so
people could future-proof their code early, but I may be mistaken about
that.
While I haven't followed concepts that closely, I'm fairly sure the "bool"
issue was thoroughly debated, so if you want it to change, you'll have to
write and present a paper addressing all the concerns that came up.
Personally, I feel the committee has far better things to do (this seems
like one of those "perfect is the enemy of good" issues), but you may feel
differently.
--=20
Nevin ":-)" Liber <mailto:nevin@cplusplusguy.com <nevin@eviloverlord.com>=
>
+1-847-691-1404
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--001a11c3db70f813c2052b728157
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 10 February 2016 at 15:29, Vicente J. Botet Escriba <sp=
an dir=3D"ltr"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_b=
lank">vicente.botet@wanadoo.fr</a>></span> wrote:<br><div class=3D"gmail=
_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
<div>Le 10/02/2016 19:19, Nevin Liber a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On 10 February 2016 at 11:51, Vicente J. Botet
Escriba <span dir=3D"ltr"><<a href=3D"mailto:vicente.botet@wanad=
oo.fr" target=3D"_blank">vicente.botet@wanadoo.fr</a>></span>
wrote:<br>
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><span>
<div><span style=3D"font-size:large">I believe that
there is a simple solution, concepts are a
different thing than nullary functions or
variables that can be specialized as structs does.
I see a concept as a short hand of a boolean type
trait.</span><br>
</div>
</span><font size=3D"+1"> =C2=A0<br>
I don't see the added value of stating explicitly boo=
l
as it can not be another type.</font></div>
</blockquote>
<div><br>
</div>
<div>And if that turns out to be true we can address that in
a backwards compatible way in the future.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote></span>
Right. But why do we need it now?</div></blockquote><div><br></div><div=
>Why do we need yet another snowflake (a function that is slightly differen=
t than other functions to save typing five characters) in the language? =C2=
=A0"Because we can" is fairly weak motivation.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=
=3D""><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><div>Otherwise, we are in the situation we had =
with
constexpr.<br clear=3D"all">
<div><br>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote></span>
Could you elaborate?</div></blockquote><div><br></div><div>To quote <a =
href=3D"https://en.wikipedia.org/wiki/C%2B%2B14">Wikipedia</a>: =C2=A0"=
;<span style=3D"color:rgb(37,37,37);font-family:sans-serif;font-size:14px">=
Also, C++11 stated that all non-static member functions that were declared=
=C2=A0</span><code style=3D"font-family:monospace,Courier;color:black;backg=
round-color:rgb(249,249,249);border:1px solid rgb(221,221,221);border-top-l=
eft-radius:2px;border-top-right-radius:2px;border-bottom-right-radius:2px;b=
order-bottom-left-radius:2px;padding:1px 4px;font-size:14px">constexpr</cod=
e><span style=3D"color:rgb(37,37,37);font-family:sans-serif;font-size:14px"=
>=C2=A0were also implicitly declared=C2=A0</span><code style=3D"font-family=
:monospace,Courier;color:black;background-color:rgb(249,249,249);border:1px=
solid rgb(221,221,221);border-top-left-radius:2px;border-top-right-radius:=
2px;border-bottom-right-radius:2px;border-bottom-left-radius:2px;padding:1p=
x 4px;font-size:14px">const</code><span style=3D"color:rgb(37,37,37);font-f=
amily:sans-serif;font-size:14px">, with respect to=C2=A0</span><code style=
=3D"font-family:monospace,Courier;color:black;background-color:rgb(249,249,=
249);border:1px solid rgb(221,221,221);border-top-left-radius:2px;border-to=
p-right-radius:2px;border-bottom-right-radius:2px;border-bottom-left-radius=
:2px;padding:1px 4px;font-size:14px">this</code><span style=3D"color:rgb(37=
,37,37);font-family:sans-serif;font-size:14px">. That has since been remove=
d; non-static member functions may be non-</span><code style=3D"font-family=
:monospace,Courier;color:black;background-color:rgb(249,249,249);border:1px=
solid rgb(221,221,221);border-top-left-radius:2px;border-top-right-radius:=
2px;border-bottom-right-radius:2px;border-bottom-left-radius:2px;padding:1p=
x 4px;font-size:14px">const</code><span style=3D"color:rgb(37,37,37);font-f=
amily:sans-serif;font-size:14px">.</span><sup id=3D"cite_ref-7" class=3D"" =
style=3D"line-height:1;font-size:11px;color:rgb(37,37,37);font-family:sans-=
serif"><a href=3D"https://en.wikipedia.org/wiki/C%2B%2B14#cite_note-7" styl=
e=3D"text-decoration:none;color:rgb(11,0,128);background-image:none;white-s=
pace:nowrap">[7]</a></sup><span style=3D"color:rgb(37,37,37);font-family:sa=
ns-serif;font-size:14px">=C2=A0However, per the above restrictions, a non-<=
/span><code style=3D"font-family:monospace,Courier;color:black;background-c=
olor:rgb(249,249,249);border:1px solid rgb(221,221,221);border-top-left-rad=
ius:2px;border-top-right-radius:2px;border-bottom-right-radius:2px;border-b=
ottom-left-radius:2px;padding:1px 4px;font-size:14px">const</code><span sty=
le=3D"color:rgb(37,37,37);font-family:sans-serif;font-size:14px">=C2=A0</sp=
an><code style=3D"font-family:monospace,Courier;color:black;background-colo=
r:rgb(249,249,249);border:1px solid rgb(221,221,221);border-top-left-radius=
:2px;border-top-right-radius:2px;border-bottom-right-radius:2px;border-bott=
om-left-radius:2px;padding:1px 4px;font-size:14px">constexpr</code><span st=
yle=3D"color:rgb(37,37,37);font-family:sans-serif;font-size:14px">=C2=A0mem=
ber function can only modify a class member if that object's lifetime b=
egan within the constant expression evaluation."</span></div><div><br>=
</div><div>That was a <i>breaking</i> change.=C2=A0 Luckily, constexpr hadn=
't been around all that long, the breakage was at compile time, and &qu=
ot;const" was optional there was a way to write code that conformed to=
both C++11 and C++14.=C2=A0 I also think that some vendors back ported thi=
s into their C++11 compilers so people could future-proof their code early,=
but I may be mistaken about that.</div><div><br></div><div>While I haven&#=
39;t followed concepts that closely, I'm fairly sure the "bool&quo=
t; issue was thoroughly debated, so if you want it to change, you'll ha=
ve to write and present a paper addressing all the concerns that came up.=
=C2=A0 Personally, I feel the committee has far better things to do (this s=
eems like one of those "perfect is the enemy of good" issues), bu=
t you may feel differently.<br>-- <br><div class=3D"gmail_signature"><div d=
ir=3D"ltr">=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@cplusplusguy.com</a>&g=
t;=C2=A0 +1-847-691-1404<br></div></div>
</div></div></div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11c3db70f813c2052b728157--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 10 Feb 2016 18:35:20 -0600
Raw View
On Wed, Feb 10, 2016 at 5:07 PM, Nevin Liber <nevin@cplusplusguy.com> wrote:
>
> Why do we need yet another snowflake (a function that is slightly different
> than other functions to save typing five characters) in the language?
> "Because we can" is fairly weak motivation.
>
Concepts in concepts-lite are type functions,
not normal functions, do not take normal functions'
arguments. I see no value in interpreting them
as functions with zero arity or variables.
And they need not to use function's syntax.
If you want to use function's syntax,
concept bool Please(put, your, type, parameters, here);
Moreover, does evolving the syntax from
template <typename T>
using Integral = std::is_integral<T>;
to
template <typename T>
concept Integral = std::is_integral_v<T>;
looks more natural to you?
It's not "saving five characters", but asking for a first class
construct.
> While I haven't followed concepts that closely, I'm fairly sure the "bool"
> issue was thoroughly debated, so if you want it to change, you'll have to
> write and present a paper addressing all the concerns that came up.
Bjarne defends the current syntax with the argument
as same as yours.
There was also US 23 in
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4550.pdf
but rejected by saying "... no consensus ... an issue will be opened".
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 11 Feb 2016 08:15:26 +0100
Raw View
This is a multi-part message in MIME format.
--------------090706070708050208090304
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/02/2016 00:07, Nevin Liber a =C3=A9crit :
> On 10 February 2016 at 15:29, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
> Le 10/02/2016 19:19, Nevin Liber a =C3=A9crit :
>> On 10 February 2016 at 11:51, Vicente J. Botet Escriba
>> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>>
>> I believe that there is a simple solution, concepts are a
>> different thing than nullary functions or variables that can
>> be specialized as structs does. I see a concept as a short
>> hand of a boolean type trait.
>>
>> I don't see the added value of stating explicitly bool as it
>> can not be another type.
>>
>>
>> And if that turns out to be true we can address that in a
>> backwards compatible way in the future.
>>
> Right. But why do we need it now?
>
>
> Why do we need yet another snowflake (a function that is slightly=20
> different than other functions to save typing five characters) in the=20
> language? "Because we can" is fairly weak motivation.
Walter paper contains already most of these concerns and was rejected.
>
>> Otherwise, we are in the situation we had with constexpr.
>>
>>
> Could you elaborate?
>
>
> To quote Wikipedia <https://en.wikipedia.org/wiki/C%2B%2B14>: "Also,=20
> C++11 stated that all non-static member functions that were declared=20
> |constexpr| were also implicitly declared |const|, with respect to=20
> |this|. That has since been removed; non-static member functions may=20
> be non-|const|.^[7]=20
> <https://en.wikipedia.org/wiki/C%2B%2B14#cite_note-7> However, per=20
> the above restrictions, a non-|const||constexpr| member function can=20
> only modify a class member if that object's lifetime began within the=20
> constant expression evaluation."
>
> That was a /breaking/ change. Luckily, constexpr hadn't been around=20
> all that long, the breakage was at compile time, and "const" was=20
> optional there was a way to write code that conformed to both C++11=20
> and C++14. I also think that some vendors back ported this into their=20
> C++11 compilers so people could future-proof their code early, but I=20
> may be mistaken about that.
Thanks for the explanation.
>
> While I haven't followed concepts that closely, I'm fairly sure the=20
> "bool" issue was thoroughly debated, so if you want it to change,=20
> you'll have to write and present a paper addressing all the concerns=20
> that came up. Personally, I feel the committee has far better things=20
> to do (this seems like one of those "perfect is the enemy of good"=20
> issues), but you may feel differently.
I believe that is is not only a four characters concern, as Walter=20
described in N4434 it is also simplified syntax.
But it is only that syntax. I believe that Ville is right. The current=20
proposal is already quite useful and having it in C++17 will help us to=20
add new libraries that use them.
I don't want to continue using enable_if everywhere, this doesn't helps=20
beginners, this doesn't helps me.
This doesn't mean that mapping concepts to type traits couldn't be an=20
option to re-consider (see US23 in N4550) if adoption of Concepts for=20
C++17 is on the table. Maybe an follow up of N4434 should be presented=20
if it is decided to adopt the Concept TS for C++17.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--------------090706070708050208090304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/02/2016 00:07, Nevin Liber a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAGg_6+PicAKdwk70Me-pf6eQ3PFhaJWG-ZDiOVHgkxeSkhajDA@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">On 10 February 2016 at 15:29, Vicente J. Botet
Escriba <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vice=
nte.botet@wanadoo.fr</a>></span>
wrote:<br>
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
<div>Le 10/02/2016 19:19, Nevin Liber a =C3=A9crit=C2=A0:=
<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">On 10 February 2016 at 11:51, Vicente
J. Botet Escriba <span dir=3D"ltr"><<a
moz-do-not-send=3D"true"
href=3D"mailto:vicente.botet@wanadoo.fr"
target=3D"_blank"><a class=3D"moz-txt-link-abbrev=
iated" href=3D"mailto:vicente.botet@wanadoo.fr">vicente.botet@wanadoo.fr</a=
></a>></span>
wrote:<br>
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote"
style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><span=
>
<div><span style=3D"font-size:large">I
believe that there is a simple
solution, concepts are a different
thing than nullary functions or
variables that can be specialized as
structs does. I see a concept as a
short hand of a boolean type trait.</sp=
an><br>
</div>
</span><font size=3D"+1"> =C2=A0<br>
I don't see the added value of stating
explicitly bool as it can not be another
type.</font></div>
</blockquote>
<div><br>
</div>
<div>And if that turns out to be true we can
address that in a backwards compatible way
in the future.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</span> Right. But why do we need it now?</div>
</blockquote>
<div><br>
</div>
<div>Why do we need yet another snowflake (a function that
is slightly different than other functions to save typing
five characters) in the language? =C2=A0"Because we can" is
fairly weak motivation.</div>
</div>
</div>
</div>
</blockquote>
Walter paper contains already most of these concerns and was
rejected.<br>
<blockquote
cite=3D"mid:CAGg_6+PicAKdwk70Me-pf6eQ3PFhaJWG-ZDiOVHgkxeSkhajDA@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><span class=3D"">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>Otherwise, we are in the situation we had
with constexpr.<br clear=3D"all">
<div><br>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</span> Could you elaborate?</div>
</blockquote>
<div><br>
</div>
<div>To quote <a moz-do-not-send=3D"true"
href=3D"https://en.wikipedia.org/wiki/C%2B%2B14">Wikipedia<=
/a>:
=C2=A0"<span
style=3D"color:rgb(37,37,37);font-family:sans-serif;font-si=
ze:14px">Also,
C++11 stated that all non-static member functions that
were declared=C2=A0</span><code
style=3D"font-family:monospace,Courier;color:black;backgrou=
nd-color:rgb(249,249,249);border:1px
solid
rgb(221,221,221);border-top-left-radius:2px;border-top-righ=
t-radius:2px;border-bottom-right-radius:2px;border-bottom-left-radius:2px;p=
adding:1px
4px;font-size:14px">constexpr</code><span
style=3D"color:rgb(37,37,37);font-family:sans-serif;font-si=
ze:14px">=C2=A0were
also implicitly declared=C2=A0</span><code
style=3D"font-family:monospace,Courier;color:black;backgrou=
nd-color:rgb(249,249,249);border:1px
solid
rgb(221,221,221);border-top-left-radius:2px;border-top-righ=
t-radius:2px;border-bottom-right-radius:2px;border-bottom-left-radius:2px;p=
adding:1px
4px;font-size:14px">const</code><span
style=3D"color:rgb(37,37,37);font-family:sans-serif;font-si=
ze:14px">,
with respect to=C2=A0</span><code
style=3D"font-family:monospace,Courier;color:black;backgrou=
nd-color:rgb(249,249,249);border:1px
solid
rgb(221,221,221);border-top-left-radius:2px;border-top-righ=
t-radius:2px;border-bottom-right-radius:2px;border-bottom-left-radius:2px;p=
adding:1px
4px;font-size:14px">this</code><span
style=3D"color:rgb(37,37,37);font-family:sans-serif;font-si=
ze:14px">.
That has since been removed; non-static member functions
may be non-</span><code
style=3D"font-family:monospace,Courier;color:black;backgrou=
nd-color:rgb(249,249,249);border:1px
solid
rgb(221,221,221);border-top-left-radius:2px;border-top-righ=
t-radius:2px;border-bottom-right-radius:2px;border-bottom-left-radius:2px;p=
adding:1px
4px;font-size:14px">const</code><span
style=3D"color:rgb(37,37,37);font-family:sans-serif;font-si=
ze:14px">.</span><sup
id=3D"cite_ref-7" class=3D""
style=3D"line-height:1;font-size:11px;color:rgb(37,37,37);font-family:sans-=
serif"><a
moz-do-not-send=3D"true"
href=3D"https://en.wikipedia.org/wiki/C%2B%2B14#cite_note=
-7"
style=3D"text-decoration:none;color:rgb(11,0,128);background-image:none;whi=
te-space:nowrap">[7]</a></sup><span
style=3D"color:rgb(37,37,37);font-family:sans-serif;font-size:14px">=C2=A0H=
owever,
per the above restrictions, a non-</span><code
style=3D"font-family:monospace,Courier;color:black;backgrou=
nd-color:rgb(249,249,249);border:1px
solid
rgb(221,221,221);border-top-left-radius:2px;border-top-righ=
t-radius:2px;border-bottom-right-radius:2px;border-bottom-left-radius:2px;p=
adding:1px
4px;font-size:14px">const</code><span
style=3D"color:rgb(37,37,37);font-family:sans-serif;font-si=
ze:14px">=C2=A0</span><code
style=3D"font-family:monospace,Courier;color:black;backgrou=
nd-color:rgb(249,249,249);border:1px
solid
rgb(221,221,221);border-top-left-radius:2px;border-top-righ=
t-radius:2px;border-bottom-right-radius:2px;border-bottom-left-radius:2px;p=
adding:1px
4px;font-size:14px">constexpr</code><span
style=3D"color:rgb(37,37,37);font-family:sans-serif;font-si=
ze:14px">=C2=A0member
function can only modify a class member if that object's
lifetime began within the constant expression
evaluation."</span></div>
<div><br>
</div>
<div>That was a <i>breaking</i> change.=C2=A0 Luckily, constexp=
r
hadn't been around all that long, the breakage was at
compile time, and "const" was optional there was a way to
write code that conformed to both C++11 and C++14.=C2=A0 I al=
so
think that some vendors back ported this into their C++11
compilers so people could future-proof their code early,
but I may be mistaken about that.</div>
</div>
</div>
</div>
</blockquote>
Thanks for the explanation.<br>
<blockquote
cite=3D"mid:CAGg_6+PicAKdwk70Me-pf6eQ3PFhaJWG-ZDiOVHgkxeSkhajDA@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div><br>
</div>
<div>While I haven't followed concepts that closely, I'm
fairly sure the "bool" issue was thoroughly debated, so if
you want it to change, you'll have to write and present a
paper addressing all the concerns that came up.=C2=A0
Personally, I feel the committee has far better things to
do (this seems like one of those "perfect is the enemy of
good" issues), but you may feel differently.<br>
</div>
</div>
</div>
</div>
</blockquote>
I believe that is is not only a four characters concern, as Walter
described in N4434 it is also simplified syntax. <br>
<br>
But it is only that syntax. I believe that Ville is right. The
current proposal is already quite useful and having it in C++17 will
help us to add new libraries that use them.<br>
I don't want to continue using enable_if everywhere, this doesn't
helps beginners, this doesn't helps me.<br>
<br>
This doesn't mean that mapping concepts to type traits couldn't be
an option to re-consider (see US23 in N4550) if adoption of Concepts
for C++17 is on the table. Maybe an follow up of N4434 should be
presented if it is decided to adopt the Concept TS for C++17. <br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--------------090706070708050208090304--
.
Author: Paul Fultz II <pfultz28@gmail.com>
Date: Sun, 21 Feb 2016 22:03:09 -0800 (PST)
Raw View
------=_Part_1848_1561582386.1456120989565
Content-Type: multipart/alternative;
boundary="----=_Part_1849_1864521126.1456120989565"
------=_Part_1849_1864521126.1456120989565
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 10, 2016 at 6:35:25 PM UTC-6, Zhihao Yuan wrote:
>
> On Wed, Feb 10, 2016 at 5:07 PM, Nevin Liber <ne...@cplusplusguy.com
> <javascript:>> wrote:
> >
> > Why do we need yet another snowflake (a function that is slightly
> different
> > than other functions to save typing five characters) in the language?
> > "Because we can" is fairly weak motivation.
> >
>
> Concepts in concepts-lite are type functions,
> not normal functions, do not take normal functions'
> arguments. I see no value in interpreting them
> as functions with zero arity or variables.
>
> And they need not to use function's syntax.
>
> If you want to use function's syntax,
>
> concept bool Please(put, your, type, parameters, here);
>
> Moreover, does evolving the syntax from
>
> template <typename T>
> using Integral = std::is_integral<T>;
>
> to
>
> template <typename T>
> concept Integral = std::is_integral_v<T>;
>
> looks more natural to you?
>
I like the above syntax, for the following reasons:
1) Concepts can be represented directly as a bool_constant, so it doesn't
require wrapping them, which is necessary for many cases(such as using them
to
filter a tuple).
2) They can be passed as a template template parameters just like template
classes and template aliases. Plus, subsuming should still work.
3) Most importantly, all type traits could be upgraded to become concepts
without breaking backwards compatibility and allowing for maximum
interoperability between legacy and modern code.
>
> It's not "saving five characters", but asking for a first class
> construct.
>
> > While I haven't followed concepts that closely, I'm fairly sure the
> "bool"
> > issue was thoroughly debated, so if you want it to change, you'll have
> to
> > write and present a paper addressing all the concerns that came up.
>
> Bjarne defends the current syntax with the argument
> as same as yours.
>
> There was also US 23 in
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4550.pdf
>
> but rejected by saying "... no consensus ... an issue will be opened".
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://bit.ly/blog4bsd
>
--
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/955bbf6c-cc5a-4b16-bfb3-de934fd897ac%40isocpp.org.
------=_Part_1849_1864521126.1456120989565
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, February 10, 2016 at 6:35:25 PM UTC-=
6, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wed, F=
eb 10, 2016 at 5:07 PM, Nevin Liber <<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"jVHvshWOHgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">ne...@cplusplusguy.com</a>> wrote:
<br>>
<br>> Why do we need yet another snowflake (a function that is slightly =
different
<br>> than other functions to save typing five characters) in the langua=
ge?
<br>> "Because we can" is fairly weak motivation.
<br>>
<br>
<br>Concepts in concepts-lite are type functions,
<br>not normal functions, do not take normal functions'
<br>arguments. =C2=A0I see no value in interpreting them
<br>as functions with zero arity or variables.
<br>
<br>And they need not to use function's syntax.
<br>
<br>If you want to use function's syntax,
<br>
<br>=C2=A0 concept bool Please(put, your, type, parameters, here);
<br>
<br>Moreover, does evolving the syntax from
<br>
<br>=C2=A0 template <typename T>
<br>=C2=A0 using Integral =3D std::is_integral<T>;
<br>
<br>to
<br>
<br>=C2=A0 template <typename T>
<br>=C2=A0 concept Integral =3D std::is_integral_v<T>;
<br>
<br>looks more natural to you?
<br></blockquote><div><br>I like the above syntax, for the following reason=
s:<br><br>1) Concepts can be represented directly as a bool_constant, so it=
doesn't<br>require wrapping them, which is necessary for many cases(su=
ch as using them to<br>filter a tuple).<br><br>2) They can be passed as a t=
emplate template parameters just like template<br>classes and template alia=
ses. Plus, subsuming should still work.<br><br>3) Most importantly, all typ=
e traits could be upgraded to become concepts<br>without breaking backwards=
compatibility and allowing for maximum<br>interoperability between legacy =
and modern code.<br><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>It's not "saving five characters", but asking for a first=
class
<br>construct.
<br>
<br>> While I haven't followed concepts that closely, I'm fairly=
sure the "bool"
<br>> issue was thoroughly debated, so if you want it to change, you'=
;ll have to
<br>> write and present a paper addressing all the concerns that came up=
..
<br>
<br>Bjarne defends the current syntax with the argument
<br>as same as yours.
<br>
<br>There was also US 23 in
<br>
<br>=C2=A0 <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/20=
15/n4550.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2FJTC1%=
2FSC22%2FWG21%2Fdocs%2Fpapers%2F2015%2Fn4550.pdf\46sa\75D\46sntz\0751\46usg=
\75AFQjCNFyfeXwqEoazatBPz2wkDmNukaGxw';return true;" onclick=3D"this.hr=
ef=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2FJTC=
1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2015%2Fn4550.pdf\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNFyfeXwqEoazatBPz2wkDmNukaGxw';return true;">http://www.open-=
std.org/JTC1/<wbr>SC22/WG21/docs/papers/2015/<wbr>n4550.pdf</a>
<br>
<br>but rejected by saying "... no consensus ... an issue will be open=
ed".
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3=
A%2F%2Fbit.ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA3DF1H_gEgI=
kwnCr7FAkiCyQ';return true;" onclick=3D"this.href=3D'http://www.goo=
gle.com/url?q\75http%3A%2F%2Fbit.ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNENWZA3DF1H_gEgIkwnCr7FAkiCyQ';return true;">http://bit.ly/blog4b=
sd</a>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/955bbf6c-cc5a-4b16-bfb3-de934fd897ac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/955bbf6c-cc5a-4b16-bfb3-de934fd897ac=
%40isocpp.org</a>.<br />
------=_Part_1849_1864521126.1456120989565--
------=_Part_1848_1561582386.1456120989565--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 22 Feb 2016 00:21:01 -0600
Raw View
On Mon, Feb 22, 2016 at 12:03 AM, Paul Fultz II <pfultz28@gmail.com> wrote:
>>
>> Moreover, does evolving the syntax from
>>
>> template <typename T>
>> using Integral = std::is_integral<T>;
>>
>> to
>>
>> template <typename T>
>> concept Integral = std::is_integral_v<T>;
>>
Notice the ^^^^^^^^^^^^^^^^^^^^^^^^^ "_v" here, which makes
it a bool rather than bool_constant. I'm not asking for
functionally changing the existing Concepts.
>
> I like the above syntax, for the following reasons:
>
> 1) Concepts can be represented directly as a bool_constant, so it doesn't
> require wrapping them, which is necessary for many cases(such as using them
> to
> filter a tuple).
Andrew explained something about this at here:
https://groups.google.com/a/isocpp.org/d/msg/concepts/fALMCb1uJrU/BbaM_EOUsbcJ
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
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/CAGsORuCTU9xHVg1r4nx%3Dxi-Myieuok1QFn%2BDvZLNnRQuBMFYug%40mail.gmail.com.
.