Topic: In support of Revisiting Concepts and P0587R0.
Author: gmisocpp@gmail.com
Date: Wed, 15 Feb 2017 13:09:54 -0800 (PST)
Raw View
------=_Part_5483_998190635.1487192994994
Content-Type: multipart/alternative;
boundary="----=_Part_5484_357174527.1487192994994"
------=_Part_5484_357174527.1487192994994
Content-Type: text/plain; charset=UTF-8
I would like to say I really like the new concepts syntax proposed
in P0587R0 more than the syntax of the alternative papers.
However, I am only just trying to come to terms with Concepts so take that
with a pinch of salt.
I note paper P0587R0 plays safe with the common template<typename T>
concept X = ... lead in, in the first paragraph, but suggests concept
X<typename T> = ... could be an option. May I say I find that latter option
appealing as it really makes the concept name stand out and seeing the word
concept early immediately alerts my eyes for what to expect next. It's also
shorter.
I don't know if there is some technical reason to prefer the first option,
but I imagine a consistency reason might be seen by some. I would not see
that myself as I personally see the latter option as having more of a
consistency with a class declaration which appeals to me more. However this
is minor, I'd be happy with either option. But I overall like this
syntax direction that this proposal takes than that of the other papers.
Can I say thank you to all the authors of the various concepts proposals
though and everyone who is working hard to push Concepts forward. I'm
excited to see Concepts in C++, and I hope this paper moves the hard work
of the previous papers forward again.
I am keen to see this paper debated and contrasted with the other papers by
those more concept aware than myself, and I hope this post encourages
that. I'm sure things will improve even more.
--
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/aa54c14d-ed24-4eb2-86ea-1bccdff70094%40isocpp.org.
------=_Part_5484_357174527.1487192994994
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><font lang=3D"JA" face=3D"ArialMT" size=3D"3"><font lang=
=3D"JA" face=3D"ArialMT" size=3D"3"><div>I would like to say I really like =
the=C2=A0new=C2=A0concepts=C2=A0syntax proposed in=C2=A0P0587R0 more than t=
he syntax of the alternative papers.</div><div><font face=3D"CourierNewPSMT=
" size=3D"3"><font face=3D"CourierNewPSMT" size=3D"3"><font lang=3D"JA" fac=
e=3D"ArialMT" size=3D"3"><font lang=3D"JA" face=3D"ArialMT" size=3D"3">Howe=
ver,=C2=A0I=C2=A0am=C2=A0only just trying to come to terms with Concepts so=
take that with a pinch of salt.</font></font></font></font></div><font fac=
e=3D"CourierNewPSMT" size=3D"3"><font face=3D"CourierNewPSMT" size=3D"3"><f=
ont lang=3D"JA" face=3D"ArialMT" size=3D"3"><font lang=3D"JA" face=3D"Arial=
MT" size=3D"3"><div><br></div></font></font></font></font><font face=3D"Cou=
rierNewPSMT" size=3D"3"><font face=3D"CourierNewPSMT" size=3D"3"><div>I not=
e paper P0587R0 plays safe with the common=C2=A0template<typename T> =
concept X =3D ... lead in, in the first paragraph, but suggests concept X&l=
t;typename T> =3D ... could be an option. May I say I=C2=A0find that lat=
ter option appealing as it really makes the concept name stand out and=C2=
=A0seeing the word concept=C2=A0early immediately=C2=A0alerts my=C2=A0eyes =
for what to expect next. It's also shorter.</div><div><br></div><div>I =
don't know if there is some technical reason to prefer the first option=
, but I imagine a consistency=C2=A0reason might=C2=A0be seen by some.=C2=A0=
I would not see that myself as I personally=C2=A0see the latter option as h=
aving more of a consistency with a class=C2=A0declaration=C2=A0which appeal=
s to me more. However this is minor, I'd be happy with either option. B=
ut I overall like this syntax=C2=A0direction that this proposal takes than =
that of the=C2=A0other papers.</div><div><br></div><div>Can I say thank you=
to all the authors of the various concepts proposals though and everyone w=
ho is working hard to push Concepts forward. I'm excited to see Concept=
s in C++, and I hope this paper=C2=A0moves the hard work of the previous pa=
pers forward again.</div><div><br></div><div><font face=3D"CourierNewPSMT" =
size=3D"3"><font face=3D"CourierNewPSMT" size=3D"3"><font lang=3D"JA" face=
=3D"ArialMT" size=3D"3"><font lang=3D"JA" face=3D"ArialMT" size=3D"3">I am =
keen to see this paper debated and contrasted with the other papers by thos=
e more concept aware than myself, and I hope this post encourages that.=C2=
=A0I'm sure things will improve even more.</font></font></font></font><=
/div><div><br></div></font></font></font></font></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/aa54c14d-ed24-4eb2-86ea-1bccdff70094%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aa54c14d-ed24-4eb2-86ea-1bccdff70094=
%40isocpp.org</a>.<br />
------=_Part_5484_357174527.1487192994994--
------=_Part_5483_998190635.1487192994994--
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Thu, 16 Feb 2017 13:53:31 -0600
Raw View
On 2/15/2017 3:09 PM, gmisocpp@gmail.com wrote:
> I would like to say I really like the new concepts syntax proposed
> in P0587R0 more than the syntax of the alternative papers.
At the risk of just saying "me too", well... Me too! P0587R0's syntax is
immensely clearer, and it feels much more in keeping with existing C++
syntax.
> I note paper P0587R0 plays safe with the common template<typename T>
> concept X = ... lead in, in the first paragraph, but suggests concept
> X<typename T> = ... could be an option.
I'm not a fan of the `concept X<typename T> = ...` since the `X<typename
T>` reminds me more of a partial template specialization than a primary
template. I do like `concept<typename T> X = ...` though. I guess it
comes down to whether you think `concept` is more like `template` or
like `class`. It seems to me it's more like the former.
- 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/o85007%24ijf%241%40blaine.gmane.org.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 16 Feb 2017 15:34:44 -0500
Raw View
--001a114e36e841b1a10548abba11
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 16, 2017 at 2:53 PM, Jim Porter <jvp4846@g.rit.edu> wrote:
> On 2/15/2017 3:09 PM, gmisocpp@gmail.com wrote:
>
>> I would like to say I really like the new concepts syntax proposed
>> in P0587R0 more than the syntax of the alternative papers.
>>
>
> At the risk of just saying "me too", well... Me too! P0587R0's syntax is
> immensely clearer, and it feels much more in keeping with existing C++
> syntax.
>
> I note paper P0587R0 plays safe with the common template<typename T>
>> concept X = ... lead in, in the first paragraph, but suggests concept
>> X<typename T> = ... could be an option.
>>
>
> I'm not a fan of the `concept X<typename T> = ...` since the `X<typename
> T>` reminds me more of a partial template specialization than a primary
> template. I do like `concept<typename T> X = ...` though. I guess it comes
> down to whether you think `concept` is more like `template` or like
> `class`. It seems to me it's more like the former.
>
> - Jim
>
>
template<typename T> concept X = ...
implies to me that
concept X = true;
would be valid. (ie like struct vs templatized struct). Is that good or
bad?
I appreciate the before/after tables in the paper. Thanks!
--
Be seeing you,
Tony
--
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/CAOHCbis%2B0kwzp9Ezu-fJEoZ0rFFQc_5F2GS9m4jExY5NF-JzMA%40mail.gmail.com.
--001a114e36e841b1a10548abba11
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Feb 16, 2017 at 2:53 PM, Jim Porter <span dir=3D"ltr"><<a hr=
ef=3D"mailto:jvp4846@g.rit.edu" target=3D"_blank">jvp4846@g.rit.edu</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span c=
lass=3D"gmail-">On 2/15/2017 3:09 PM, <a href=3D"mailto:gmisocpp@gmail.com"=
target=3D"_blank">gmisocpp@gmail.com</a> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
I would like to say I really like the new concepts syntax proposed<br>
in P0587R0 more than the syntax of the alternative papers.<br>
</blockquote>
<br></span>
At the risk of just saying "me too", well... Me too! P0587R0'=
s syntax is immensely clearer, and it feels much more in keeping with exist=
ing C++ syntax.<span class=3D"gmail-"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
I note paper P0587R0 plays safe with the common template<typename T><=
br>
concept X =3D ... lead in, in the first paragraph, but suggests concept<br>
X<typename T> =3D ... could be an option.<br>
</blockquote>
<br></span>
I'm not a fan of the `concept X<typename T> =3D ...` since the `X=
<typename T>` reminds me more of a partial template specialization th=
an a primary template. I do like `concept<typename T> X =3D ...` thou=
gh. I guess it comes down to whether you think `concept` is more like `temp=
late` or like `class`. It seems to me it's more like the former.<br>
<br>
- Jim<span class=3D"gmail-"><br>
</span><br></blockquote></div><br></div><div class=3D"gmail_extra">=C2=A0=
=C2=A0=C2=A0 template<typename T> concept X =3D ...<br><br></div><div=
class=3D"gmail_extra">implies to me that <br><br></div><div class=3D"gmail=
_extra">=C2=A0=C2=A0=C2=A0 concept X =3D true;<br><br></div><div class=3D"g=
mail_extra">would be valid.=C2=A0 (ie like struct vs templatized struct).=
=C2=A0 Is that good or bad?<br><br></div><div class=3D"gmail_extra">I appre=
ciate the before/after tables in the paper. Thanks!<br><br clear=3D"all"></=
div><div class=3D"gmail_extra"><br>-- <br><div class=3D"gmail_signature"><d=
iv dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></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/CAOHCbis%2B0kwzp9Ezu-fJEoZ0rFFQc_5F2G=
S9m4jExY5NF-JzMA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbis%2B0kwz=
p9Ezu-fJEoZ0rFFQc_5F2GS9m4jExY5NF-JzMA%40mail.gmail.com</a>.<br />
--001a114e36e841b1a10548abba11--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 16 Feb 2017 12:42:05 -0800 (PST)
Raw View
------=_Part_1387_245017278.1487277725572
Content-Type: multipart/alternative;
boundary="----=_Part_1388_883873693.1487277725572"
------=_Part_1388_883873693.1487277725572
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 15, 2017 at 4:09:55 PM UTC-5, gmis...@gmail.com
wrote:
>
> I would like to say I really like the new concepts syntax proposed
> in P0587R0 more than the syntax of the alternative papers.
>
While there are some things to like in that paper (like elements of the
syntax for defining a concept, getting rid of template induction syntax,
etc), there is a really good reason why `requires` is basically its own
language with novel constructs and decomposibility.
Though Concepts TS doesn't require it, the design of the feature recognizes
the eventual possibility of definition checking for concepts. And being
able to do that requires being able to match individual uses of a
conceptualized type with specific expressions used in the actual functions.
If you use the type outside of that list of expressions, then your code
fails to compile long before template instantiation time.
By defining concepts as expressions, it's much easier for a compiler to
come along and verify that a particular expression matches the concept. If
you use arbitrary statements, it becomes rather more difficult for a
compiler to decide if something is being used correctly.
Decomposition for concepts is absolutely critical for that, as it allows
interoperability between codebases that don't share concepts.
Logically, if my function requires a type to adhere to certain expressions,
I should be able to call *any other function* with an object of that type,
so long as that function similarly restricts that particular type to the
same expressions, or any subset of them (and if my call does not provoke an
operation that is not one of the valid expressions).
By allowing generic, arbitrary code to appear in `requires` clauses, it
makes this sort of thing completely impossible. Not without both functions
explicitly referencing the same concepts. And that's one of the most
important differences between compile-time polymorphism and runtime
polymorphism: runtime requires an explicit prototype, while compile-time
requires an *implicit* prototype.
These changes to `requires` effectively makes definition checking
impossible. Or a lot less practical, both from a user perspective and a
compiler implementation perspective.
Of course, if you just see concepts as nothing more than a sane form of
SFINAE, then you won't care.
That being said, it does solve a couple of problems. The example P0587 gave
of using a type as a range in a range-based `for`. The Concepts TS version
is actually *wrong*; that's not how the C++ standard defines how it gets
the begin/end iterators from the range. It never calls a function when
given an array type. And when it does look up functions, the lookup rules
*cannot* be emulated exactly using user-written C++ expressions. The
non-member `begin/end` lookup rules say that they only apply ADL; they
*never* look it up in the global namespace. There's no way for a user to
write an equivalent to that kind of lookup.
As such, the only way to get the equivalent of it is to either add a trait
type to test it (`is_range_for` or somesuch) or to allow statements.
--
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/1e1529d0-aab8-4c63-959c-3772b58f094c%40isocpp.org.
------=_Part_1388_883873693.1487277725572
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, February 15, 2017 at 4:09:55 PM UTC-5, gmis.=
...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><font size=3D"3" lang=3D"JA" face=3D"ArialMT"><font size=3D"3" lang=
=3D"JA" face=3D"ArialMT"><div>I would like to say I really like the=C2=A0ne=
w=C2=A0concepts=C2=A0syntax proposed in=C2=A0P0587R0 more than the syntax o=
f the alternative papers.</div></font></font></div></blockquote><div><br>Wh=
ile there are some things to like in that paper (like elements of the synta=
x for defining a concept, getting rid of template induction syntax, etc), t=
here is a really good reason why `requires` is basically its own language w=
ith novel constructs and decomposibility.<br><br>Though Concepts TS doesn&#=
39;t require it, the design of the feature recognizes the eventual possibil=
ity of definition checking for concepts. And being able to do that requires=
being able to match individual uses of a conceptualized type with specific=
expressions used in the actual functions. If you use the type outside of t=
hat list of expressions, then your code fails to compile long before templa=
te instantiation time.<br><br>By defining concepts as expressions, it's=
much easier for a compiler to come along and verify that a particular expr=
ession matches the concept. If you use arbitrary statements, it becomes rat=
her more difficult for a compiler to decide if something is being used corr=
ectly.<br><br>Decomposition for concepts is absolutely critical for that, a=
s it allows interoperability between codebases that don't share concept=
s.<br><br>Logically, if my function requires a type to adhere to certain ex=
pressions, I should be able to call <i>any other function</i> with an objec=
t of that type, so long as that function similarly restricts that particula=
r type to the same expressions, or any subset of them (and if my call does =
not provoke an operation that is not one of the valid expressions).<br><br>=
By allowing generic, arbitrary code to appear in `requires` clauses, it mak=
es this sort of thing completely impossible. Not without both functions exp=
licitly referencing the same concepts. And that's one of the most impor=
tant differences between compile-time polymorphism and runtime polymorphism=
: runtime requires an explicit prototype, while compile-time requires an <i=
>implicit</i> prototype.<br><br>These changes to `requires` effectively mak=
es definition checking impossible. Or a lot less practical, both from a use=
r perspective and a compiler implementation perspective.<br><br>Of course, =
if you just see concepts as nothing more than a sane form of SFINAE, then y=
ou won't care.<br><br>That being said, it does solve a couple of proble=
ms. The example P0587 gave of using a type as a range in a range-based `for=
`. The Concepts TS version is actually <i>wrong</i>; that's not how the=
C++ standard defines how it gets the begin/end iterators from the range. I=
t never calls a function when given an array type. And when it does look up=
functions, the lookup rules <i>cannot</i> be emulated exactly using user-w=
ritten C++ expressions. The non-member `begin/end` lookup rules say that th=
ey only apply ADL; they <i>never</i> look it up in the global namespace. Th=
ere's no way for a user to write an equivalent to that kind of lookup.<=
br><br>As such, the only way to get the equivalent of it is to either add a=
trait type to test it (`is_range_for` or somesuch) or to allow statements.=
<br></div></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/1e1529d0-aab8-4c63-959c-3772b58f094c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e1529d0-aab8-4c63-959c-3772b58f094c=
%40isocpp.org</a>.<br />
------=_Part_1388_883873693.1487277725572--
------=_Part_1387_245017278.1487277725572--
.
Author: G M <gmisocpp@gmail.com>
Date: Fri, 17 Feb 2017 10:06:18 +1300
Raw View
--f40304353cf427790b0548ac2bb4
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 17, 2017 at 8:53 AM, Jim Porter <jvp4846@g.rit.edu> wrote:
> On 2/15/2017 3:09 PM, gmisocpp@gmail.com wrote:
>
>> I would like to say I really like the new concepts syntax proposed
>> in P0587R0 more than the syntax of the alternative papers.
>>
>
> At the risk of just saying "me too", well... Me too! P0587R0's syntax is
> immensely clearer, and it feels much more in keeping with existing C++
> syntax.
>
> I note paper P0587R0 plays safe with the common template<typename T>
>> concept X = ... lead in, in the first paragraph, but suggests concept
>> X<typename T> = ... could be an option.
>>
>
> I'm not a fan of the `concept X<typename T> = ...` since the `X<typename
> T>` reminds me more of a partial template specialization than a primary
> template. I do like `concept<typename T> X = ...` though. I guess it comes
> down to whether you think `concept` is more like `template` or like
> `class`. It seems to me it's more like the former.
>
> - Jim
>
>
>
I thought this too, but...
Ok small challenge! Open up some simple concepts example, maybe from Ranges
on github or
from here http://en.cppreference.com/w/cpp/language/constraints
Then rewrite (well re-arrange) them so that you see concept X<whatever>
instead of concept<whatever> X (doesn't matter if the rest is text after
your change is the old syntax) and put them in one file.
Then report back if you still feel the same way.
There's a good chance you might, but I'm curious.
--
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/CAGxCow11Ts-UL76jhnJzkv5FEAGp1uKKxMQ5zY1BKHXw5y7_aw%40mail.gmail.com.
--f40304353cf427790b0548ac2bb4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Feb 17, 2017 at 8:53 AM, Jim Porter <span dir=3D"ltr"><<a hr=
ef=3D"mailto:jvp4846@g.rit.edu" target=3D"_blank">jvp4846@g.rit.edu</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid"><span>On 2/15/2017 3:09 PM, <a href=3D"m=
ailto:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a> wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
I would like to say I really like the new concepts syntax proposed<br>
in P0587R0 more than the syntax of the alternative papers.<br>
</blockquote>
<br></span>
At the risk of just saying "me too", well... Me too! P0587R0'=
s syntax is immensely clearer, and it feels much more in keeping with exist=
ing C++ syntax.<span><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
I note paper P0587R0 plays safe with the common template<typename T><=
br>
concept X =3D ... lead in, in the first paragraph, but suggests concept<br>
X<typename T> =3D ... could be an option.<br>
</blockquote>
<br></span>
I'm not a fan of the `concept X<typename T> =3D ...` since the `X=
<typename T>` reminds me more of a partial template specialization th=
an a primary template. I do like `concept<typename T> X =3D ...` thou=
gh. I guess it comes down to whether you think `concept` is more like `temp=
late` or like `class`. It seems to me it's more like the former.<br>
<br>
- Jim<span><br>
<br>
</span><br></blockquote><div><br></div><div>I thought this too, but...</div=
><div><br></div><div>Ok small challenge! Open up some simple concepts examp=
le, maybe=C2=A0from Ranges on github=C2=A0or</div><div>from here <a href=3D=
"http://en.cppreference.com/w/cpp/language/constraints">http://en.cpprefere=
nce.com/w/cpp/language/constraints</a></div><div>Then rewrite (well re-arra=
nge)=C2=A0them so that you see concept X<whatever> instead of concept=
<whatever> X (doesn't matter if the rest is text after your chang=
e is=C2=A0the old syntax) and put them in one file.</div><div><br></div><di=
v>Then report back if you still feel the same way.</div><div>There's a =
good chance you might, but I'm curious.</div><div><br></div><div><br></=
div><div><br></div></div></div></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/CAGxCow11Ts-UL76jhnJzkv5FEAGp1uKKxMQ5=
zY1BKHXw5y7_aw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGxCow11Ts-UL76j=
hnJzkv5FEAGp1uKKxMQ5zY1BKHXw5y7_aw%40mail.gmail.com</a>.<br />
--f40304353cf427790b0548ac2bb4--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 16 Feb 2017 13:54:35 -0800
Raw View
--001a1142605205f09a0548acd91d
Content-Type: text/plain; charset=UTF-8
On 16 February 2017 at 12:42, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, February 15, 2017 at 4:09:55 PM UTC-5, gmis...@gmail.com
> wrote:
>>
>> I would like to say I really like the new concepts syntax proposed
>> in P0587R0 more than the syntax of the alternative papers.
>>
>
> While there are some things to like in that paper (like elements of the
> syntax for defining a concept, getting rid of template induction syntax,
> etc), there is a really good reason why `requires` is basically its own
> language with novel constructs and decomposibility.
>
> Though Concepts TS doesn't require it, the design of the feature
> recognizes the eventual possibility of definition checking for concepts.
> And being able to do that requires being able to match individual uses of a
> conceptualized type with specific expressions used in the actual functions.
> If you use the type outside of that list of expressions, then your code
> fails to compile long before template instantiation time.
>
> By defining concepts as expressions, it's much easier for a compiler to
> come along and verify that a particular expression matches the concept. If
> you use arbitrary statements, it becomes rather more difficult for a
> compiler to decide if something is being used correctly.
>
Citation needed.
Here's the thing: the existing requires-expression syntax already allows
arbitrarily complex expressions to appear. A definition checking system
would need to essentially collect all of the subexpressions, build a
catalogue of them, and then pattern-match those against the template
definition. That is not made materially different by allowing the
expressions to live within statements.
Decomposition for concepts is absolutely critical for that, as it allows
> interoperability between codebases that don't share concepts.
>
As the paper notes, if you depend on this, your program works by fragile
coincidence; we should not complicate language features in order to make
more programs work by coincidence. A programming language that encourages
you to depend on other people's implementation details is simply
inappropriate for large-scale development.
> Logically, if my function requires a type to adhere to certain
> expressions, I should be able to call *any other function* with an object
> of that type, so long as that function similarly restricts that particular
> type to the same expressions, or any subset of them (and if my call does
> not provoke an operation that is not one of the valid expressions).
>
> By allowing generic, arbitrary code to appear in `requires` clauses, it
> makes this sort of thing completely impossible.
>
Note that the Concepts TS already permits that for arbitrary expressions.
You seem to be arguing for something closer to the original concepts
approach, where only atomic expression pieces (in its case, presented as
function declarations) can be constrained. Perhaps that would be a good
thing, perhaps not, but you should be aware that you're not arguing about a
difference between the Concepts TS and the approach proposed in P0587R0.
Not without both functions explicitly referencing the same concepts. And
> that's one of the most important differences between compile-time
> polymorphism and runtime polymorphism: runtime requires an explicit
> prototype, while compile-time requires an *implicit* prototype.
>
> These changes to `requires` effectively makes definition checking
> impossible. Or a lot less practical, both from a user perspective and a
> compiler implementation perspective.
>
> Of course, if you just see concepts as nothing more than a sane form of
> SFINAE, then you won't care.
>
> That being said, it does solve a couple of problems. The example P0587
> gave of using a type as a range in a range-based `for`. The Concepts TS
> version is actually *wrong*; that's not how the C++ standard defines how
> it gets the begin/end iterators from the range. It never calls a function
> when given an array type. And when it does look up functions, the lookup
> rules *cannot* be emulated exactly using user-written C++ expressions.
> The non-member `begin/end` lookup rules say that they only apply ADL; they
> *never* look it up in the global namespace. There's no way for a user to
> write an equivalent to that kind of lookup.
>
> As such, the only way to get the equivalent of it is to either add a trait
> type to test it (`is_range_for` or somesuch) or to allow statements.
>
> --
> 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/1e1529d0-aab8-4c63-
> 959c-3772b58f094c%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1e1529d0-aab8-4c63-959c-3772b58f094c%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAOfiQq%3DsBO9mgZ3e6RGqDje0s5tU9zn%3DVcpqOVddEJ2dydNi7Q%40mail.gmail.com.
--001a1142605205f09a0548acd91d
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 1=
6 February 2017 at 12:42, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mail=
to:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"=
">On Wednesday, February 15, 2017 at 4:09:55 PM UTC-5, <a href=3D"mailto:gm=
is...@gmail.com" target=3D"_blank">gmis...@gmail.com</a> wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><font size=3D"3" lang=3D"JA" f=
ace=3D"ArialMT"><font size=3D"3" lang=3D"JA" face=3D"ArialMT"><div>I would =
like to say I really like the=C2=A0new=C2=A0concepts=C2=A0syntax proposed i=
n=C2=A0P0587R0 more than the syntax of the alternative papers.</div></font>=
</font></div></blockquote></span><div><br>While there are some things to li=
ke in that paper (like elements of the syntax for defining a concept, getti=
ng rid of template induction syntax, etc), there is a really good reason wh=
y `requires` is basically its own language with novel constructs and decomp=
osibility.<br><br>Though Concepts TS doesn't require it, the design of =
the feature recognizes the eventual possibility of definition checking for =
concepts. And being able to do that requires being able to match individual=
uses of a conceptualized type with specific expressions used in the actual=
functions. If you use the type outside of that list of expressions, then y=
our code fails to compile long before template instantiation time.<br><br>B=
y defining concepts as expressions, it's much easier for a compiler to =
come along and verify that a particular expression matches the concept. If =
you use arbitrary statements, it becomes rather more difficult for a compil=
er to decide if something is being used correctly.<br></div></div></blockqu=
ote><div><br></div><div>Citation needed.</div><div><br></div><div>Here'=
s the thing: the existing requires-expression syntax already allows arbitra=
rily complex expressions to appear. A definition checking system would need=
to essentially collect all of the subexpressions, build a catalogue of the=
m, and then pattern-match those against the template definition. That is no=
t made materially different by allowing the expressions to live within stat=
ements.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>Decomposition for concepts is absolutely critical for that, as it all=
ows interoperability between codebases that don't share concepts.<br></=
div></div></blockquote><div><br></div><div>As the paper notes, if you depen=
d on this, your program works by fragile coincidence; we should not complic=
ate language features in order to make more programs work by coincidence. A=
programming language that encourages you to depend on other people's i=
mplementation details is simply inappropriate for large-scale development.<=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
Logically, if my function requires a type to adhere to certain expressions,=
I should be able to call <i>any other function</i> with an object of that =
type, so long as that function similarly restricts that particular type to =
the same expressions, or any subset of them (and if my call does not provok=
e an operation that is not one of the valid expressions).<br><br>By allowin=
g generic, arbitrary code to appear in `requires` clauses, it makes this so=
rt of thing completely impossible.</div></div></blockquote><div><br></div><=
div>Note that the Concepts TS already permits that for arbitrary expression=
s. You seem to be arguing for something closer to the original concepts app=
roach, where only atomic expression pieces (in its case, presented as funct=
ion declarations) can be constrained. Perhaps that would be a good thing, p=
erhaps not, but you should be aware that you're not arguing about a dif=
ference between the Concepts TS and the approach proposed in P0587R0.</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Not wit=
hout both functions explicitly referencing the same concepts. And that'=
s one of the most important differences between compile-time polymorphism a=
nd runtime polymorphism: runtime requires an explicit prototype, while comp=
ile-time requires an <i>implicit</i> prototype.<br><br>These changes to `re=
quires` effectively makes definition checking impossible. Or a lot less pra=
ctical, both from a user perspective and a compiler implementation perspect=
ive.<br><br>Of course, if you just see concepts as nothing more than a sane=
form of SFINAE, then you won't care.<br><br>That being said, it does s=
olve a couple of problems. The example P0587 gave of using a type as a rang=
e in a range-based `for`. The Concepts TS version is actually <i>wrong</i>;=
that's not how the C++ standard defines how it gets the begin/end iter=
ators from the range. It never calls a function when given an array type. A=
nd when it does look up functions, the lookup rules <i>cannot</i> be emulat=
ed exactly using user-written C++ expressions. The non-member `begin/end` l=
ookup rules say that they only apply ADL; they <i>never</i> look it up in t=
he global namespace. There's no way for a user to write an equivalent t=
o that kind of lookup.<br><br>As such, the only way to get the equivalent o=
f it is to either add a trait type to test it (`is_range_for` or somesuch) =
or to allow statements.<br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1e1529d0-aab8-4c63-959c-3772b58f094c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/1e15=
29d0-aab8-4c63-<wbr>959c-3772b58f094c%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAOfiQq%3DsBO9mgZ3e6RGqDje0s5tU9zn%3D=
VcpqOVddEJ2dydNi7Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DsBO=
9mgZ3e6RGqDje0s5tU9zn%3DVcpqOVddEJ2dydNi7Q%40mail.gmail.com</a>.<br />
--001a1142605205f09a0548acd91d--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 16 Feb 2017 15:37:32 -0800 (PST)
Raw View
------=_Part_10_1959913954.1487288253070
Content-Type: multipart/alternative;
boundary="----=_Part_11_1165468980.1487288253071"
------=_Part_11_1165468980.1487288253071
Content-Type: text/plain; charset=UTF-8
On Thursday, February 16, 2017 at 4:54:58 PM UTC-5, Richard Smith wrote:
>
> On 16 February 2017 at 12:42, Nicol Bolas <jmck...@gmail.com <javascript:>
> > wrote:
>
>> On Wednesday, February 15, 2017 at 4:09:55 PM UTC-5, gmis...@gmail.com
>> wrote:
>>>
>>> I would like to say I really like the new concepts syntax proposed
>>> in P0587R0 more than the syntax of the alternative papers.
>>>
>>
>> While there are some things to like in that paper (like elements of the
>> syntax for defining a concept, getting rid of template induction syntax,
>> etc), there is a really good reason why `requires` is basically its own
>> language with novel constructs and decomposibility.
>>
>> Though Concepts TS doesn't require it, the design of the feature
>> recognizes the eventual possibility of definition checking for concepts.
>> And being able to do that requires being able to match individual uses of a
>> conceptualized type with specific expressions used in the actual functions.
>> If you use the type outside of that list of expressions, then your code
>> fails to compile long before template instantiation time.
>>
>> By defining concepts as expressions, it's much easier for a compiler to
>> come along and verify that a particular expression matches the concept. If
>> you use arbitrary statements, it becomes rather more difficult for a
>> compiler to decide if something is being used correctly.
>>
>
> Citation needed.
>
> Here's the thing: the existing requires-expression syntax already allows
> arbitrarily complex expressions to appear.
>
Arbitrarily complex *expressions* may appear. Not arbitrarily complex code.
> A definition checking system would need to essentially collect all of the
> subexpressions, build a catalogue of them, and then pattern-match those
> against the template definition. That is not made materially different by
> allowing the expressions to live within statements.
>
I rather disagree. By permitting arbitrary statements, you now have to
match *statements*, not subexpressions. If you declare that a type can be
used in a range-based `for` as part of a concept, then you're not allowed
to do `begin()` or whatever on the type. The only thing that having
range-based `for` in a concept should allow you to do is use it in a
range-based `for`. Not parts of ranged-based `for`; the whole thing.
Just as `{*it = some_value};` should not mean that it's OK to invoke `*it`
*without* the assignment; you have to use the whole expression, not just
part of it.
Decomposition for concepts is absolutely critical for that, as it allows
>> interoperability between codebases that don't share concepts.
>>
>
> As the paper notes, if you depend on this, your program works by fragile
> coincidence; we should not complicate language features in order to make
> more programs work by coincidence. A programming language that encourages
> you to depend on other people's implementation details is simply
> inappropriate for large-scale development.
>
This leads to the main conclusion of going down this road: you make
definition checking completely non-workable. Why?
Because concepts isn't going to ship with a conceptualized standard
library. As such, everyone's going to have to roll their own basic
concepts. This means that once definition checking comes online, everyone's
concepts libraries become non-interoperable. And if everyone's code is
non-interoperable, then nobody's going to use definition checking. So
there's no point in having it.
The `requires` clause in Concepts TS was designed to make definition
checking a reasonable thing to eventually do. Without decomposibility and
equivalence, definition checking prevents interop between different code
bases.
I do not agree that such interop constitutes a "fragile coincidence" or
"other people's implementation details". Concepts are not implementation
details; they're part of a function's interface. Indeed, being part of a
function's interface is half the point of the feature.
If you write a template function that requires a moveable type, then it
requires a moveable type. How you choose to spell "moveable type" is as
irrelevant as whether `f->some_func()` will call a function with default
arguments or a function with no arguments. If someone defines a function
that requires a moveable type, and you have a type which is required to be
a moveable type, you should be able to call that function, no matter how
either side chooses to spell "moveable type".
What matters is the behavior, not how you declare it. Indeed, that's one of
the defining aspects of template code: what matters is that it fits
together, not that it fits a prototype.
That's why concepts are not like virtual functions. They don't say "this
function has this exact return type and these exact parameters". They say
"there will be a function with this name that I can call with these
parameters and returns something that I can use like this." What matters in
templates are fitting patterns, not fitting prototypes.
Concept decomposition is *not* optional. Not if we ever want definition
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ac8aceec-432e-4cc9-9f1f-a139eacdee77%40isocpp.org.
------=_Part_11_1165468980.1487288253071
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, February 16, 2017 at 4:54:58 PM UTC-5, Richar=
d Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On 16 February 2017 at 12:42, Nicol Bolas =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"FLShs5GHBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;javascript:';return true;" onclick=3D"this.href=3D'javascript:=
9;;return true;">jmck...@gmail.com</a>></span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><span>On Wednesday, February 15, 2017 at 4=
:09:55 PM UTC-5, <a>gmis...@gmail.com</a> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><font size=3D"3" lang=3D"JA" face=3D"ArialMT"=
><font size=3D"3" lang=3D"JA" face=3D"ArialMT"><div>I would like to say I r=
eally like the=C2=A0new=C2=A0concepts=C2=A0syntax proposed in=C2=A0P0587R0 =
more than the syntax of the alternative papers.</div></font></font></div></=
blockquote></span><div><br>While there are some things to like in that pape=
r (like elements of the syntax for defining a concept, getting rid of templ=
ate induction syntax, etc), there is a really good reason why `requires` is=
basically its own language with novel constructs and decomposibility.<br><=
br>Though Concepts TS doesn't require it, the design of the feature rec=
ognizes the eventual possibility of definition checking for concepts. And b=
eing able to do that requires being able to match individual uses of a conc=
eptualized type with specific expressions used in the actual functions. If =
you use the type outside of that list of expressions, then your code fails =
to compile long before template instantiation time.<br><br>By defining conc=
epts as expressions, it's much easier for a compiler to come along and =
verify that a particular expression matches the concept. If you use arbitra=
ry statements, it becomes rather more difficult for a compiler to decide if=
something is being used correctly.<br></div></div></blockquote><div><br></=
div><div>Citation needed.</div><div><br></div><div>Here's the thing: th=
e existing requires-expression syntax already allows arbitrarily complex ex=
pressions to appear.</div></div></div></div></blockquote><div><br>Arbitrari=
ly complex <i>expressions</i> may appear. Not arbitrarily complex code.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote"><div>A definition checking system would need=
to essentially collect all of the subexpressions, build a catalogue of the=
m, and then pattern-match those against the template definition. That is no=
t made materially different by allowing the expressions to live within stat=
ements.</div></div></div></div></blockquote><div><br>I rather disagree. By =
permitting arbitrary statements, you now have to match <i>statements</i>, n=
ot subexpressions. If you declare that a type can be used in a range-based =
`for` as part of a concept, then you're not allowed to do `begin()` or =
whatever on the type. The only thing that having range-based `for` in a con=
cept should allow you to do is use it in a range-based `for`. Not parts of =
ranged-based `for`; the whole thing.<br><br>Just as `{*it =3D some_value};`=
should not mean that it's OK to invoke `*it` <i>without</i> the assign=
ment; you have to use the whole expression, not just part of it.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>Decomposition for concepts is absolutely critical for that, as i=
t allows interoperability between codebases that don't share concepts.<=
br></div></div></blockquote><div><br></div><div>As the paper notes, if you =
depend on this, your program works by fragile coincidence; we should not co=
mplicate language features in order to make more programs work by coinciden=
ce. A programming language that encourages you to depend on other people=
9;s implementation details is simply inappropriate for large-scale developm=
ent.</div></div></div></div></blockquote><div><br>This leads to the main co=
nclusion of going down this road: you make definition checking completely n=
on-workable. Why?<br><br>Because concepts isn't going to ship with a co=
nceptualized standard library. As such, everyone's going to have to rol=
l their own basic concepts. This means that once definition checking comes =
online, everyone's concepts libraries become non-interoperable. And if =
everyone's code is non-interoperable, then nobody's going to use de=
finition checking. So there's no point in having it.<br><br>The `requir=
es` clause in Concepts TS was designed to make definition checking a reason=
able thing to eventually do. Without decomposibility and equivalence, defin=
ition checking prevents interop between different code bases.<br><br>I do n=
ot agree that such interop constitutes a "fragile coincidence" or=
"other people's implementation details". Concepts are not im=
plementation details; they're part of a function's interface. Indee=
d, being part of a function's interface is half the point of the featur=
e.<br><br>If you write a template function that requires a moveable type, t=
hen it requires a moveable type. How you choose to spell "moveable typ=
e" is as irrelevant as whether `f->some_func()` will call a functio=
n with default arguments or a function with no arguments. If someone define=
s a function that requires a moveable type, and you have a type which is re=
quired to be a moveable type, you should be able to call that function, no =
matter how either side chooses to spell "moveable type".<br><br>W=
hat matters is the behavior, not how you declare it. Indeed, that's one=
of the defining aspects of template code: what matters is that it fits tog=
ether, not that it fits a prototype.<br><br>That's why concepts are not=
like virtual functions. They don't say "this function has this ex=
act return type and these exact parameters". They say "there will=
be a function with this name that I can call with these parameters and ret=
urns something that I can use like this." What matters in templates ar=
e fitting patterns, not fitting prototypes.<br><br>Concept decomposition is=
<i>not</i> optional. Not if we ever want definition checking.<br></div></d=
iv>
<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/ac8aceec-432e-4cc9-9f1f-a139eacdee77%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac8aceec-432e-4cc9-9f1f-a139eacdee77=
%40isocpp.org</a>.<br />
------=_Part_11_1165468980.1487288253071--
------=_Part_10_1959913954.1487288253070--
.
Author: Tom Honermann <tom@honermann.net>
Date: Fri, 17 Feb 2017 12:11:00 -0500
Raw View
This is a multi-part message in MIME format.
--------------F88ECA11CCB543946CC63906
Content-Type: text/plain; charset=UTF-8; format=flowed
On 02/16/2017 04:54 PM, Richard Smith wrote:
>
> Decomposition for concepts is absolutely critical for that, as it
> allows interoperability between codebases that don't share concepts.
>
>
> As the paper notes, if you depend on this, your program works by
> fragile coincidence; we should not complicate language features in
> order to make more programs work by coincidence. A programming
> language that encourages you to depend on other people's
> implementation details is simply inappropriate for large-scale
> development.
While I agree that there is potential for unintended concept matching, I
think the benefits of concept decomposition and implicit refinement
outweigh the concerns. Requiring explicit refinement introduces the
downsides of class hierarchies. The Ranges work illustrates the
difficulty in defining useful concepts well. I fear requiring explicit
refinement may have the effect of locking us in to complex concept
hierarchies that don't work well in practice.
I do think it would be ok to drop partial ordering for entities
constrained with independent requires clauses rather than concept
definitions. This would make use of standalone requires clauses
effectively equivalent to SFINAE today - such declarations would have to
be mutually exclusive to avoid ambiguity.
Tom.
--
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/ee6d07a8-a640-1b6b-33f0-1d72bfbc1707%40honermann.net.
--------------F88ECA11CCB543946CC63906
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">On 02/16/2017 04:54 PM, Richard Smith
wrote:<br>
</div>
<blockquote
cite=3D"mid:CAOfiQq=3DsBO9mgZ3e6RGqDje0s5tU9zn=3DVcpqOVddEJ2dydNi7Q@mail.gm=
ail.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>Decomposition for concepts is absolutely critical
for that, as it allows interoperability between
codebases that don't share concepts.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>As the paper notes, if you depend on this, your program
works by fragile coincidence; we should not complicate
language features in order to make more programs work by
coincidence. A programming language that encourages you to
depend on other people's implementation details is simply
inappropriate for large-scale development.</div>
</div>
</div>
</div>
</blockquote>
While I agree that there is potential for unintended concept
matching, I think the benefits of concept decomposition and implicit
refinement outweigh the concerns.=C2=A0 Requiring explicit refinement
introduces the downsides of class hierarchies.=C2=A0 The Ranges work
illustrates the difficulty in defining useful concepts well.=C2=A0 I fe=
ar
requiring explicit refinement may have the effect of locking us in
to complex concept hierarchies that don't work well in practice.<br>
<br>
I do think it would be ok to drop partial ordering for entities
constrained with independent requires clauses rather than concept
definitions.=C2=A0 This would make use of standalone requires clauses
effectively equivalent to SFINAE today - such declarations would
have to be mutually exclusive to avoid ambiguity.<br>
<br>
Tom.<br>
</body>
</html>
<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/ee6d07a8-a640-1b6b-33f0-1d72bfbc1707%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/ee6d07a8-a640-1b6b-33f0-1d72bfbc1=
707%40honermann.net</a>.<br />
--------------F88ECA11CCB543946CC63906--
.
Author: Tom Honermann <tom@honermann.net>
Date: Fri, 17 Feb 2017 12:20:40 -0500
Raw View
This is a multi-part message in MIME format.
--------------54B35726FE1D2496AF452A22
Content-Type: text/plain; charset=UTF-8; format=flowed
On 02/16/2017 06:37 PM, Nicol Bolas wrote:
>
> Just as `{*it = some_value};` should not mean that it's OK to invoke
> `*it` /without/ the assignment; you have to use the whole expression,
> not just part of it.
I don't necessarily agree with that. If the requirement is that the
full expression be well-formed, then its decomposed expressions must
likewise be well-formed and I think it would be fair for a definition
checking implementation to allow independent uses of those
subexpressions, presumably with additional inferred constraints (e.g.,
that the uses would suffice to avoid potential ambiguity).
Tom.
--
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/e617a6fd-19f8-2d0d-e906-c09ab33f50ad%40honermann.net.
--------------54B35726FE1D2496AF452A22
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">On 02/16/2017 06:37 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote
cite=3D"mid:ac8aceec-432e-4cc9-9f1f-a139eacdee77@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<div>Just as `{*it =3D some_value};` should not mean that it's OK
to invoke `*it` <i>without</i> the assignment; you have to
use the whole expression, not just part of it.</div>
</div>
</blockquote>
<br>
I don't necessarily agree with that.=C2=A0 If the requirement is that t=
he
full expression be well-formed, then its decomposed expressions must
likewise be well-formed and I think it would be fair for a
definition checking implementation to allow independent uses of
those subexpressions, presumably with additional inferred
constraints (e.g., that the uses would suffice to avoid potential
ambiguity).<br>
<br>
Tom.<br>
</body>
</html>
<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/e617a6fd-19f8-2d0d-e906-c09ab33f50ad%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/e617a6fd-19f8-2d0d-e906-c09ab33f5=
0ad%40honermann.net</a>.<br />
--------------54B35726FE1D2496AF452A22--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 17 Feb 2017 11:47:18 -0800 (PST)
Raw View
------=_Part_1119_542817281.1487360838113
Content-Type: multipart/alternative;
boundary="----=_Part_1120_1349802911.1487360838113"
------=_Part_1120_1349802911.1487360838113
Content-Type: text/plain; charset=UTF-8
On Friday, February 17, 2017 at 12:20:43 PM UTC-5, Tom Honermann wrote:
>
> On 02/16/2017 06:37 PM, Nicol Bolas wrote:
>
>
> Just as `{*it = some_value};` should not mean that it's OK to invoke `*it`
> *without* the assignment; you have to use the whole expression, not just
> part of it.
>
>
> I don't necessarily agree with that. If the requirement is that the full
> expression be well-formed, then its decomposed expressions must likewise be
> well-formed and I think it would be fair for a definition checking
> implementation to allow independent uses of those subexpressions,
> presumably with additional inferred constraints (e.g., that the uses would
> suffice to avoid potential ambiguity).
>
My example was bad because OutputIterator is an Iterator, which defines
that `*it` by itself is legal. Indeed, the Range TS apparently doesn't
bother to list `*it++ = val;` for OutputIterator, as that is a natural
out-growth of the combination of Writeable and Iterator.
My point is that, while each of the expressions may be well-formed, the
*results* of those expressions need not be. Or more specifically, how you
use those results is not specified if you use them in any way other than
what is specified in the concept.
Let's pretend that OutputIterator specifically only specified `*it++ =
val;` as the only valid expression to use such an iterator.
This means that I could have `it++` return a temporary iterator, and have
`*` return a reference/proxy to something in that iterator. If I do that,
then `auto &&v = *it++;` is going to yield a reference/proxy to a temporary
that is destroyed at the end of the expression. Thus making any later `v =
val;` call fail.
So, does having `*it++ = val;` in an concept mean that the concept requires
that storing the intermediate values will work? If so, then that means I
have to design my type as if all three operations (post-increment,
dereference, assign) were individually specified in the concept, with firm
definitions of how the results of those expressions can be used (whether
they can be stored, etc).
It seems to me that, if the writer of the concept wanted the individual
forms to work, the writer would have simply stated each expression
individually. By putting them all in one expression, the intent should be
that the whole expression must be used as is.
--
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/8a9669ed-2f89-42e1-8947-1aacd327a98a%40isocpp.org.
------=_Part_1120_1349802911.1487360838113
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, February 17, 2017 at 12:20:43 PM UTC-5, Tom Hon=
ermann wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>On 02/16/2017 06:37 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<div>Just as `{*it =3D some_value};` should not mean that it's =
OK
to invoke `*it` <i>without</i> the assignment; you have to
use the whole expression, not just part of it.</div>
</div>
</blockquote>
<br>
I don't necessarily agree with that.=C2=A0 If the requirement is th=
at the
full expression be well-formed, then its decomposed expressions must
likewise be well-formed and I think it would be fair for a
definition checking implementation to allow independent uses of
those subexpressions, presumably with additional inferred
constraints (e.g., that the uses would suffice to avoid potential
ambiguity).<br></div></blockquote><div><br></div>My example was bad bec=
ause OutputIterator is an Iterator, which defines that `*it` by itself is l=
egal. Indeed, the Range TS apparently doesn't bother to list `*it++ =3D=
val;` for OutputIterator, as that is a natural out-growth of the combinati=
on of Writeable and Iterator.<br><br>My point is that, while each of the ex=
pressions may be well-formed, the *results* of those expressions need not b=
e. Or more specifically, how you use those results is not specified if you =
use them in any way other than what is specified in the concept.<br><br>Let=
's pretend that OutputIterator specifically only specified `*it++ =3D v=
al;` as the only valid expression to use such an iterator.<br><br>This mean=
s that I could have `it++` return a temporary iterator, and have `*` return=
a reference/proxy to something in that iterator. If I do that, then `auto =
&&v =3D *it++;` is going to yield a reference/proxy to a temporary =
that is destroyed at the end of the expression. Thus making any later `v =
=3D val;` call fail.<br><br>So, does having `*it++ =3D val;` in an concept =
mean that the concept requires that storing the intermediate values will wo=
rk? If so, then that means I have to design my type as if all three operati=
ons (post-increment, dereference, assign) were individually specified in th=
e concept, with firm definitions of how the results of those expressions ca=
n be used (whether they can be stored, etc).<br><br>It seems to me that, if=
the writer of the concept wanted the individual forms to work, the writer =
would have simply stated each expression individually. By putting them all =
in one expression, the intent should be that the whole expression must be u=
sed as is.<br></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/8a9669ed-2f89-42e1-8947-1aacd327a98a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8a9669ed-2f89-42e1-8947-1aacd327a98a=
%40isocpp.org</a>.<br />
------=_Part_1120_1349802911.1487360838113--
------=_Part_1119_542817281.1487360838113--
.
Author: Tom Honermann <tom@honermann.net>
Date: Sat, 18 Feb 2017 11:15:18 -0500
Raw View
This is a multi-part message in MIME format.
--------------E9D99836D297CCAFE6E35271
Content-Type: text/plain; charset=UTF-8; format=flowed
On 02/17/2017 02:47 PM, Nicol Bolas wrote:
> On Friday, February 17, 2017 at 12:20:43 PM UTC-5, Tom Honermann wrote:
>
> On 02/16/2017 06:37 PM, Nicol Bolas wrote:
>>
>> Just as `{*it = some_value};` should not mean that it's OK to
>> invoke `*it` /without/ the assignment; you have to use the whole
>> expression, not just part of it.
>
> I don't necessarily agree with that. If the requirement is that
> the full expression be well-formed, then its decomposed
> expressions must likewise be well-formed and I think it would be
> fair for a definition checking implementation to allow independent
> uses of those subexpressions, presumably with additional inferred
> constraints (e.g., that the uses would suffice to avoid potential
> ambiguity).
>
>
> My example was bad because OutputIterator is an Iterator, which
> defines that `*it` by itself is legal. Indeed, the Range TS apparently
> doesn't bother to list `*it++ = val;` for OutputIterator, as that is a
> natural out-growth of the combination of Writeable and Iterator.
>
> My point is that, while each of the expressions may be well-formed,
> the *results* of those expressions need not be. Or more specifically,
> how you use those results is not specified if you use them in any way
> other than what is specified in the concept.
This is why I suggested that uses of those subexpressions may imply
additional inferred constraints (inferred from the full expression in
the requirements).
>
> Let's pretend that OutputIterator specifically only specified `*it++ =
> val;` as the only valid expression to use such an iterator.
>
> This means that I could have `it++` return a temporary iterator, and
> have `*` return a reference/proxy to something in that iterator. If I
> do that, then `auto &&v = *it++;` is going to yield a reference/proxy
> to a temporary that is destroyed at the end of the expression. Thus
> making any later `v = val;` call fail.
Indeed. However, that isn't something that I would expect definition
checking to diagnose; just as I wouldn't expect definition checking to
diagnose dereferencing a singular or past-the-end iterator.
>
> So, does having `*it++ = val;` in an concept mean that the concept
> requires that storing the intermediate values will work?
I don't read it that way.
> If so, then that means I have to design my type as if all three
> operations (post-increment, dereference, assign) were individually
> specified in the concept, with firm definitions of how the results of
> those expressions can be used (whether they can be stored, etc).
I don't agree. I view concept definitions as defining the set of
required well-formed expressions and that is basically it. Given an
input iterator i, `*i; *i;` is well-formed, but invokes UB. I don't
view concept definitions as a means for diagnosing UB.
>
> It seems to me that, if the writer of the concept wanted the
> individual forms to work, the writer would have simply stated each
> expression individually. By putting them all in one expression, the
> intent should be that the whole expression must be used as is.
I do think that we have yet to see best practices emerge. But I don't
agree with the notion that the required full expressions must be used in
their entirety; at least, not yet. I think this needs more exploration
in the context of definition checking.
Tom.
--
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/67d02ec0-b1a3-b8e0-dd46-e23cb8cdfa44%40honermann.net.
--------------E9D99836D297CCAFE6E35271
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">On 02/17/2017 02:47 PM, Nicol Bolas
wrote:<br>
</div>
<blockquote
cite=3D"mid:8a9669ed-2f89-42e1-8947-1aacd327a98a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On Friday, February 17, 2017 at 12:20:43 PM UTC-5,
Tom Honermann wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>On 02/16/2017 06:37 PM, Nicol Bolas wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<div>Just as `{*it =3D some_value};` should not mean that
it's OK to invoke `*it` <i>without</i> the
assignment; you have to use the whole expression, not
just part of it.</div>
</div>
</blockquote>
<br>
I don't necessarily agree with that.=C2=A0 If the requirement i=
s
that the full expression be well-formed, then its decomposed
expressions must likewise be well-formed and I think it
would be fair for a definition checking implementation to
allow independent uses of those subexpressions, presumably
with additional inferred constraints (e.g., that the uses
would suffice to avoid potential ambiguity).<br>
</div>
</blockquote>
<div><br>
</div>
My example was bad because OutputIterator is an Iterator, which
defines that `*it` by itself is legal. Indeed, the Range TS
apparently doesn't bother to list `*it++ =3D val;` for
OutputIterator, as that is a natural out-growth of the
combination of Writeable and Iterator.<br>
<br>
My point is that, while each of the expressions may be
well-formed, the *results* of those expressions need not be. Or
more specifically, how you use those results is not specified if
you use them in any way other than what is specified in the
concept.<br>
</div>
</blockquote>
This is why I suggested that uses of those subexpressions may imply
additional inferred constraints (inferred from the full expression
in the requirements).<br>
<blockquote
cite=3D"mid:8a9669ed-2f89-42e1-8947-1aacd327a98a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
Let's pretend that OutputIterator specifically only specified
`*it++ =3D val;` as the only valid expression to use such an
iterator.<br>
<br>
This means that I could have `it++` return a temporary iterator,
and have `*` return a reference/proxy to something in that
iterator. If I do that, then `auto &&v =3D *it++;` is
going to yield a reference/proxy to a temporary that is
destroyed at the end of the expression. Thus making any later `v
=3D val;` call fail.<br>
</div>
</blockquote>
Indeed.=C2=A0 However, that isn't something that I would expect
definition checking to diagnose; just as I wouldn't expect
definition checking to diagnose dereferencing a singular or
past-the-end iterator.<br>
<blockquote
cite=3D"mid:8a9669ed-2f89-42e1-8947-1aacd327a98a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
So, does having `*it++ =3D val;` in an concept mean that the
concept requires that storing the intermediate values will work?</d=
iv>
</blockquote>
I don't read it that way.<br>
<blockquote
cite=3D"mid:8a9669ed-2f89-42e1-8947-1aacd327a98a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"> If so, then that means I have to design my type as
if all three operations (post-increment, dereference, assign)
were individually specified in the concept, with firm
definitions of how the results of those expressions can be used
(whether they can be stored, etc).<br>
</div>
</blockquote>
I don't agree.=C2=A0 I view concept definitions as defining the set of
required well-formed expressions and that is basically it.=C2=A0 Given =
an
input iterator i, `*i; *i;` is well-formed, but invokes UB.=C2=A0 I don=
't
view concept definitions as a means for diagnosing UB.<br>
<blockquote
cite=3D"mid:8a9669ed-2f89-42e1-8947-1aacd327a98a@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
It seems to me that, if the writer of the concept wanted the
individual forms to work, the writer would have simply stated
each expression individually. By putting them all in one
expression, the intent should be that the whole expression must
be used as is.</div>
</blockquote>
I do think that we have yet to see best practices emerge.=C2=A0 But I
don't agree with the notion that the required full expressions must
be used in their entirety; at least, not yet.=C2=A0 I think this needs
more exploration in the context of definition checking.<br>
<br>
Tom.<br>
</body>
</html>
<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/67d02ec0-b1a3-b8e0-dd46-e23cb8cdfa44%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/67d02ec0-b1a3-b8e0-dd46-e23cb8cdf=
a44%40honermann.net</a>.<br />
--------------E9D99836D297CCAFE6E35271--
.