Topic: Why don't concepts look like and get called
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 26 Oct 2018 12:19:07 +0200
Raw View
On Thu, 25 Oct 2018 at 09:04, <mihailnajdenov@gmail.com> wrote:
> Modules and Coroutines don't have good chances for 20.
> The main new features will be Concepts and Contracts.
Quick correction: from what I hear, Modules have good chances as there
have been a strong convergence in the last weeks/months and
apparently.
> As for J. M, proposal - we must see how this would compare with Reflectio=
ns as Reflection will also be able to "emit code" and "return a type".
It would be interesting to have some feedback of this proposal from
the MetaProg/Reflection group, I believe they didn't publicly comment
on it yet.
A. Jo=C3=ABl Lamotte
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OO3t8yeS4ZE6H6QFP2z%2BoNwwTN1doXL8YUBjTJej=
j4Jqw%40mail.gmail.com.
.
Author: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= <gasper.azman@gmail.com>
Date: Sun, 28 Oct 2018 13:27:34 +0200
Raw View
--000000000000da98500579483d1e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
It might be useful to have a SmallerThan<int, int> concept to check whether
a type-erased type whose size is only known numerically can fit into an SBO
buffer.
It's a bit of a stretch, but might be a good case for keeping value
concepts in, even if they only have rare usefulness.
On Sun, Oct 28, 2018 at 12:44 PM <mihailnajdenov@gmail.com> wrote:
> Arthur,
> If you don't think value concepts should not be in, then you should write
> a paper - it is probably worth a careful investigation.
>
> Should be noted, Concepts are *template argument filters* and as such
> people will argue that for consistency alone it is worth having concepts
> over values
> simply because template arguments can be values as well.
>
> That said, concepts over values might have outlived their usefulness with
> the introduction of static assert, constexpr if and contracts.
>
> An investigating where exactly they are still useful will be nice to have=
,
> if for no other reason then teachability.
>
>
> On Saturday, October 27, 2018 at 11:27:58 PM UTC+3, Arthur O'Dwyer wrote:
>>
>> On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis...@gmail.com
>> wrote:
>>>
>>> A few thoughts on Concepts:
>>>
>>> As Concepts have evolved, I have found it difficult to get a handle on
>>> what Concepts actually are.
>>> i.e.: Are Concepts functions, types, or something else?
>>>
>>
>> Something else.
>>
>>
>>> Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming"
>>> <https://www.youtube.com/watch?v=3DHddFGPTAmtU> answers that question
>>> clearly.
>>>
>>> In his talk, Bjarne says:
>>> * Concepts are NOT types of types. They are NOT type classes.
>>>
>>
>> Well, they sort-of are. To a first approximation, they're predicates
>> (type -> bool), which can be understood as partitions of the set of all
>> types.
>> For any type T, either T is-a Range or T is-not-a Range. So the set of
>> Ranges is a subset of the set of all possible types.
>> BUT! Look closer and there are at least three caveats.
>> (1) Concepts have deep structure known as "normal form"; see below.
>> (2) Concepts don't have to map (type -> bool); you can have
>> multi-parameter concepts such as ConvertibleTo<T,U>, which are not as
>> easily to gloss as predicates over single types. (But darned if the
>> Concepts TS doesn't try! For any type T, either T is-a ConvertibleTo<U> =
or
>> T is-not-a ConvertibleTo<U>.)
>> (3) Concepts don't have to accept types at all. For example, you can mak=
e
>> a concept that maps (int -> bool).
>>
>> template<int V>
>> concept EvenValue =3D ((V % 2) =3D=3D 0);
>>
>> I don't think this kind of concept is useful in real code (I'd prefer
>> this kind of concept be kicked out of the Working Draft before C++2a is
>> shipped). But you definitely can't by any mental gymnastics claim that
>> concept `EvenValue` is a "type function" or a "type of types" or anythin=
g
>> remotely like that.
>>
>>
>> At around 1:06:30 in his talk Bjarne says:
>>> * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS".
>>>
>>
>> I believe that was an ad-lib not to be taken 100% literally. To a first
>> approximation, a concept like Mergeable is a function mapping an ordered
>> tuple of types to a bool. But that doesn't mean that *all concepts ever*
>> must be thought of as functions.
>> That way lies functional programming and madness. ;)
>>
>> [...]
>>
>>> The Concepts defined in Bjarne's talk look more like variable
>>> definitions *defined* in what feels (to me) like an odd mix of logic an=
d
>>> type like syntax:
>>>
>>> template<typename X> using Value_type =3D X::value_type;
>>> template<typename X> using Iterator_of =3D X::iterator;
>>>
>>> template<typename For, typename For2, typename Out>
>>> concept Mergable =3D
>>> ForwardIterator<For>
>>> && ForwardIterator<For2>
>>> && OutputIterator<Out>
>>> && Assignable<Value_type<For>,Value_type<Out>>
>>> && Assignable<Value_type<For2>,Value_type<Out>>
>>> && Comparable<Value_type<For>,Value_type<For2>>;
>>>
>>> The above looks like a variable definition. If it is not, then is it
>>> right that it looks like one?
>>> It's a definition, with conditional logic et al. i.e it uses &&. etc.
>>> like an inline function.
>>> So why are we defining it NOT using function like snytax?
>>> Why is this a good thing?
>>>
>>
>> Because of the first caveat I listed above: Concepts are not *just*
>> predicates. They are logical predicates with deep structure, described b=
y
>> their *normal form*. For example, there is no special relationship
>> between the variable templates
>>
>> template<class T> inline constexpr bool is_scalar_v =3D
>> std::is_scalar<T>::value;
>> template<class T> inline constexpr bool is_integral_v =3D
>> is_scalar_v<T> && std::is_integral<T>::value;
>>
>> but there is a very special relationship between the concept( template)s
>>
>> template<class T> concept is_scalar_c =3D std::is_scalar<T>::value;
>> template<class T> concept is_integral_c =3D is_scalar_c<T> &&
>> std::is_integral<T>::value;
>>
>> The special relationship is called *subsumption*, and we say that
>> is_integral_c<X> *subsumes* is_scalar_c<X>.
>> If it weren't for subsumption, there would be no fundamental difference
>> between a concept and a variable template of type `bool`.
>>
>> The compiler determines the subsumption relationships between concepts b=
y
>> cracking open their definitions and peering inside. The definitions are
>> cracked open *only* along the boundaries of the logical `&&` and `||`
>> operators. So it is critically important that the definition of a concep=
t
>> be a single logical expression. If a concept were allowed to be expresse=
d
>> as a function body, the compiler wouldn't be able to crack it open, lift=
it
>> into *normal form*, and figure out the *subsumption* relationships
>> between this concept and all the other concepts in your program.
>>
>> Figuring out these relationships is important to the compiler because
>> these relationships affect overload resolution.
>>
>> Please see my CppCon 2018 talk "Concepts as she is spoke"
>> <https://www.youtube.com/watch?v=3DCXn02MPkn8Y> for a truly painful amou=
nt
>> of information on how Concepts are different from plain old variable
>> templates.
>>
>> [...]
>>
>>> 1. If concepts ARE functions, why aren't we defining and using them wit=
h
>>> function like syntax? And using () not <>.
>>>
>>
>> I hope my answers above have pointed the way on this one.
>>
>>
>>> 2. It seems J. Monnon's proposal is making the same point as I am, only
>>> much better? Can we please address all that he proposes?
>>>
>>
>> I think P0844 "Type functions and beyond"
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html>
>> is thought-provoking. It's very large, though, which I believe is why it=
's
>> targeted at SG7 Compile-Time Programming (formerly SG7 Reflection).
>> P0844 major section 3, "Concepts introducing types," seems to ignore the
>> existence of non-type concepts in the Working Draft. Perhaps there shoul=
d
>> be a concerted effort to *kick non-type concepts out of the Working
>> Draft* in order to gain some freedom of motion for these recurring
>> theories of "concepts =3D=3D types of types."
>> I do not believe that P0844 is making the same points (or, asking for
>> clarification on the same points) as you are. I have only skimmed P0844,
>> but it does not seem to be engaging with Concepts-as-they-are at all; it
>> seems to be trying to reuse Concepty words to refer to elements of the
>> author's more na=C3=AFve "types of types" theory.
>> (More na=C3=AFve is not necessarily bad! I think C++2a Concepts is *far=
* too
>> much of an experts-only feature, and we could use a lot more naivet=C3=
=A9 in
>> this area.)
>>
>> 3. I feel a more formal response to J. Monnon's paper from the main
>>> proponents of Concepts as currently defined should be made before conce=
pts
>>> get wired in any further in it's current direction?
>>>
>>> I know many people would like Concepts be the marquee feature of C++20,
>>> but to me Concepts still seem quite away from where I'd like them to be=
..
>>> Even Bjarne can only 'begrudgingly live' with the current syntax.
>>> All this flux and begrudging really doesn't suggest to me that Concepts
>>> are ready to go for C++20.
>>>
>>
>> FWIW, I agree with your conclusion.
>> The question is, do C++2a Concepts need wholesale kicking-out, as
>> happened in C++11? or can they be rescued by judicious cuts?
>> The other question is, can anyone stop Concepts at this point or are the
>> wise people getting out of the way of the train? (Cynic says: observe th=
e
>> recent formation of EWGI and LEWGI for those people tired of engaging wi=
th
>> C++2a issues and eager to move on to C++2b.)
>>
>> =E2=80=93Arthur
>>
> --
> 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/17eb2726-8fe=
b-4cdf-a58e-43d6dc81549a%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17eb2726-8f=
eb-4cdf-a58e-43d6dc81549a%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAANG%3DkUSFekt__DVJ6VZYeZtrNpk%2BV11FxL%3DWZ4y0=
L0XS5qWxA%40mail.gmail.com.
--000000000000da98500579483d1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It might be useful to have a SmallerThan<int, int> c=
oncept to check whether a type-erased type whose size is only known numeric=
ally can fit into an SBO buffer.<div><br></div><div>It's a bit of a str=
etch, but might be a good case for keeping value concepts in, even if they =
only have rare usefulness.</div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Sun, Oct 28, 2018 at 12:44 PM <<a href=3D"mailto:mihailnaj=
denov@gmail.com">mihailnajdenov@gmail.com</a>> wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr">Arthur,=C2=A0<div>If you don't t=
hink value concepts should not be in, then you should write a paper - it is=
probably worth a careful investigation.=C2=A0<div><br></div><div>Should be=
noted, Concepts are <i>template argument filters</i> and as such people wi=
ll argue that for consistency alone it is worth having concepts over values=
</div><div>simply because template arguments can be values as well.</div><d=
iv><br></div><div>That said,=C2=A0concepts over values might have outlived =
their usefulness with the introduction of static assert, constexpr if and c=
ontracts.</div><div><br></div><div>An investigating where exactly they are =
still useful will be nice to have, if for no other reason then teachability=
..=C2=A0<br><div>=C2=A0<br><br>On Saturday, October 27, 2018 at 11:27:58 PM =
UTC+3, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, <a>gmis..=
..@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>A few thoughts on Concepts:</div><div><br></div><div>As Concepts h=
ave evolved, I have found it difficult to get a handle on what Concepts act=
ually are.<br>i.e.: Are Concepts functions, types, or something else?</div>=
</div></blockquote><div><br></div><div>Something else.</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><a href=3D"=
https://www.youtube.com/watch?v=3DHddFGPTAmtU" rel=3D"nofollow" target=3D"_=
blank">Bjarne's CppCon 2018 talk "Concepts: The Future of Generic =
Programming"</a> answers that question clearly.<br></div><p>In his tal=
k, Bjarne says:<br>* Concepts are NOT types of types. They are NOT type cla=
sses.<br></p></div></blockquote><div><br></div><div>Well, they sort-of are.=
To a first approximation, they're predicates (type -> bool), which =
can be understood as partitions of the set of all types.</div><div>For any =
type T, either T is-a Range or T is-not-a Range. So the set of Ranges is a =
subset of the set of all possible types.</div><div>BUT! Look closer and the=
re are at least three caveats.</div><div>(1) Concepts have deep structure k=
nown as "normal form"; see below.</div><div>(2) Concepts don'=
t have to map (type -> bool); you can have multi-parameter concepts such=
as ConvertibleTo<T,U>, which are not as easily to gloss as predicate=
s over single types. (But darned if the Concepts TS doesn't try! For an=
y type T, either T is-a ConvertibleTo<U> or T is-not-a ConvertibleTo&=
lt;U>.)</div><div>(3) Concepts don't have to accept types at all. Fo=
r example, you can make a concept that maps (int -> bool).</div><div><br=
></div><div>=C2=A0 =C2=A0 template<int V></div><div>=C2=A0 =C2=A0 con=
cept EvenValue =3D ((V % 2) =3D=3D 0);</div><div><br></div><div>I don't=
think this kind of concept is useful in real code (I'd prefer this kin=
d of concept be kicked out of the Working Draft before C++2a is shipped). B=
ut you definitely can't by any mental gymnastics claim that concept `Ev=
enValue`=C2=A0is a "type function" or a "type of types"=
or anything remotely like that.</div><div><br></div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p>At around 1:06:30 in h=
is talk Bjarne says:<br>* "it's just like defining functions, you =
*ARE* DEFINING FUNCTIONS".</p></div></blockquote><div><br></div><div>I=
believe that was an ad-lib not to be taken 100% literally. To a first appr=
oximation, a concept like Mergeable is a function mapping an ordered tuple =
of types to a bool. But that doesn't mean that <i>all concepts ever</i>=
must be thought of as functions.</div><div>That way lies functional progra=
mming and madness. ;)</div><div><br></div><div>[...]</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>The Concepts defined in Bjarne=
's talk look more like variable definitions *defined* in what feels (to=
me) like an odd mix of logic and type like syntax:<br></div><p>template<=
;typename X> using Value_type =3D X::value_type;<br>template<typename=
X> using Iterator_of =3D X::iterator;</p><p>template<typename For, t=
ypename For2, typename Out><br>concept Mergable =3D<br>=C2=A0=C2=A0=C2=
=A0 ForwardIterator<For><br>=C2=A0=C2=A0=C2=A0 && ForwardIter=
ator<For2><br>=C2=A0=C2=A0=C2=A0 && OutputIterator<Out>=
<br>=C2=A0=C2=A0=C2=A0 && Assignable<Value_type<For>,Value=
_type<Out>><br>=C2=A0=C2=A0=C2=A0 && Assignable<Value_t=
ype<For2>,Value_type<Out>><br>=C2=A0=C2=A0=C2=A0 && =
Comparable<Value_type<For>,Value_type<For2>>;</p><div><br=
></div><div>The above looks like a variable definition. If it is not, then =
is it right that it looks like one?<br>It's a definition, with conditio=
nal logic et al. i.e it uses &&. etc. like an inline function.<br><=
/div><div>So why are we defining it NOT using function like snytax?<br>Why =
is this a good thing?</div></div></blockquote><div><br></div><div>Because o=
f the first caveat I listed above: Concepts are not <i>just</i> predicates.=
They are logical predicates with deep structure, described by their <i>nor=
mal form</i>. For example, there is no special relationship between the var=
iable templates</div><div><br></div><div>=C2=A0 =C2=A0 template<class T&=
gt; inline constexpr bool is_scalar_v =3D std::is_scalar<T>::value;</=
div><div>=C2=A0 =C2=A0 template<class T> inline constexpr bool is_int=
egral_v =3D is_scalar_v<T> && std::is_integral<T>::valu=
e;</div><div><br></div><div>but there is a very special relationship betwee=
n the concept( template)s</div><div><br></div><div><div>=C2=A0 =C2=A0 templ=
ate<class T> concept is_scalar_c =3D std::is_scalar<T>::value;<=
/div><div>=C2=A0 =C2=A0 template<class T> concept is_integral_c =3D i=
s_scalar_c<T> && std::is_integral<T>::value;</div></div=
><div><br></div><div>The special relationship is called <i>subsumption</i>,=
and we say that is_integral_c<X> <i>subsumes</i> is_scalar_c<X>=
;.</div><div>If it weren't for subsumption, there would be no fundament=
al difference between a concept and a variable template of type `bool`.</di=
v><div><br></div><div>The compiler determines the subsumption relationships=
between concepts by cracking open their definitions and peering inside. Th=
e definitions are cracked open <i>only</i> along the boundaries of the logi=
cal `&&` and `||` operators. So it is critically important that the=
definition of a concept be a single logical expression. If a concept were =
allowed to be expressed as a function body, the compiler wouldn't be ab=
le to crack it open, lift it into <i>normal form</i>, and figure out the <i=
>subsumption</i> relationships between this concept and all the other conce=
pts in your program.</div><div><br></div><div>Figuring out these relationsh=
ips is important to the compiler because these relationships affect overloa=
d resolution.</div><div><br></div><div>Please see my CppCon 2018 talk <a hr=
ef=3D"https://www.youtube.com/watch?v=3DCXn02MPkn8Y" rel=3D"nofollow" targe=
t=3D"_blank">"Concepts as she is spoke"</a> for a truly painful a=
mount of information on how Concepts are different from plain old variable =
templates.</div><div><br></div><div>[...]</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div>1. If concepts ARE functions, why aren=
9;t we defining and using them with function like syntax? And using () not =
<>.<br></div></div></blockquote><div><br></div><div>I hope my answers=
above have pointed the way on this one.</div><div>=C2=A0</div><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>2. It seems J. Monnon'=
;s proposal is making the same point as I am, only much better? Can we plea=
se address all that he proposes?<br></div></div></blockquote><div><br></div=
><div>I think <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers=
/2018/p0844r0.html" rel=3D"nofollow" target=3D"_blank">P0844 "Type fun=
ctions and beyond"</a> is thought-provoking. It's very large, thou=
gh, which I believe is why it's targeted at SG7 Compile-Time Programmin=
g (formerly SG7 Reflection).</div><div>P0844 major section 3, "Concept=
s introducing types," seems to ignore the existence of non-type concep=
ts in the Working Draft. Perhaps there should be a concerted effort to <i>k=
ick non-type concepts out of the Working Draft</i> in order to gain some fr=
eedom of motion for these recurring theories of "concepts =3D=3D types=
of types."</div><div>I do not believe that P0844 is making the same p=
oints (or, asking for clarification on the same points) as you are. I have =
only skimmed P0844, but it does not seem to be engaging with Concepts-as-th=
ey-are at all; it seems to be trying to reuse Concepty words to refer to el=
ements of the author's more na=C3=AFve "types of types" theor=
y.</div><div>(More na=C3=AFve is not necessarily bad!=C2=A0 I think C++2a C=
oncepts is <i>far</i> too much of an experts-only feature, and we could use=
a lot more naivet=C3=A9 in this area.)</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div>3. I feel a more formal resp=
onse to J. Monnon's paper from the main proponents of Concepts as curre=
ntly defined should be made before concepts get wired in any further in it&=
#39;s current direction?</div><div><br></div><div>I know many people would =
like Concepts be the marquee feature of C++20, but to me Concepts=C2=A0stil=
l seem quite away from where I'd like them to be.<br>Even Bjarne can on=
ly 'begrudgingly live' with the current syntax.<br>All this flux an=
d begrudging really doesn't suggest to me that Concepts are ready to go=
for C++20.<br></div></div></blockquote><div><br></div><div>FWIW, I agree w=
ith your conclusion.</div><div>The question is, do C++2a Concepts need whol=
esale kicking-out, as happened in C++11? or can they be rescued by judiciou=
s cuts?</div><div>The other question is, can anyone stop Concepts at this p=
oint or are the wise people getting out of the way of the train? (Cynic say=
s: observe the recent formation of EWGI and LEWGI for those people tired of=
engaging with C++2a issues and eager to move on to C++2b.)</div><div><br><=
/div><div>=E2=80=93Arthur</div></div></blockquote></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" target=3D"_=
blank">std-proposals+unsubscribe@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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/17eb2726-8feb-4cdf-a58e-43d6dc81549a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17eb2726-8feb-=
4cdf-a58e-43d6dc81549a%40isocpp.org</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/CAANG%3DkUSFekt__DVJ6VZYeZtrNpk%2BV11=
FxL%3DWZ4y0L0XS5qWxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUS=
Fekt__DVJ6VZYeZtrNpk%2BV11FxL%3DWZ4y0L0XS5qWxA%40mail.gmail.com</a>.<br />
--000000000000da98500579483d1e--
.
Author: mihailnajdenov@gmail.com
Date: Sun, 28 Oct 2018 06:10:15 -0700 (PDT)
Raw View
------=_Part_1344_1942991597.1540732215821
Content-Type: multipart/alternative;
boundary="----=_Part_1345_1667251794.1540732215822"
------=_Part_1345_1667251794.1540732215822
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Sunday, October 28, 2018 at 1:27:48 PM UTC+2, Ga=C5=A1per A=C5=BEman wro=
te:
>
> It might be useful to have a SmallerThan<int, int> concept to check=20
> whether a type-erased type whose size is only known numerically can fit=
=20
> into an SBO buffer.
>
> It's a bit of a stretch, but might be a good case for keeping value=20
> concepts in, even if they only have rare usefulness.
>
I just realized, with the downgrade of constexpr if to require a scope=20
there is no other way to check a class template argument.=20
template<GoodValue val>=20
class C
{
// ...
};
Also, things will become genuinely interesting with custom class non-type=
=20
template arguments. =20
=20
>
> On Sun, Oct 28, 2018 at 12:44 PM <mihailn...@gmail.com <javascript:>>=20
> wrote:
>
>> Arthur,=20
>> If you don't think value concepts should not be in, then you should writ=
e=20
>> a paper - it is probably worth a careful investigation.=20
>>
>> Should be noted, Concepts are *template argument filters* and as such=20
>> people will argue that for consistency alone it is worth having concepts=
=20
>> over values
>> simply because template arguments can be values as well.
>>
>> That said, concepts over values might have outlived their usefulness wit=
h=20
>> the introduction of static assert, constexpr if and contracts.
>>
>> An investigating where exactly they are still useful will be nice to=20
>> have, if for no other reason then teachability.=20
>> =20
>>
>> On Saturday, October 27, 2018 at 11:27:58 PM UTC+3, Arthur O'Dwyer wrote=
:
>>>
>>> On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis...@gmail.com=
=20
>>> wrote:
>>>>
>>>> A few thoughts on Concepts:
>>>>
>>>> As Concepts have evolved, I have found it difficult to get a handle on=
=20
>>>> what Concepts actually are.
>>>> i.e.: Are Concepts functions, types, or something else?
>>>>
>>>
>>> Something else.
>>> =20
>>>
>>>> Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming=
"=20
>>>> <https://www.youtube.com/watch?v=3DHddFGPTAmtU> answers that question=
=20
>>>> clearly.
>>>>
>>>> In his talk, Bjarne says:
>>>> * Concepts are NOT types of types. They are NOT type classes.
>>>>
>>>
>>> Well, they sort-of are. To a first approximation, they're predicates=20
>>> (type -> bool), which can be understood as partitions of the set of all=
=20
>>> types.
>>> For any type T, either T is-a Range or T is-not-a Range. So the set of=
=20
>>> Ranges is a subset of the set of all possible types.
>>> BUT! Look closer and there are at least three caveats.
>>> (1) Concepts have deep structure known as "normal form"; see below.
>>> (2) Concepts don't have to map (type -> bool); you can have=20
>>> multi-parameter concepts such as ConvertibleTo<T,U>, which are not as=
=20
>>> easily to gloss as predicates over single types. (But darned if the=20
>>> Concepts TS doesn't try! For any type T, either T is-a ConvertibleTo<U>=
or=20
>>> T is-not-a ConvertibleTo<U>.)
>>> (3) Concepts don't have to accept types at all. For example, you can=20
>>> make a concept that maps (int -> bool).
>>>
>>> template<int V>
>>> concept EvenValue =3D ((V % 2) =3D=3D 0);
>>>
>>> I don't think this kind of concept is useful in real code (I'd prefer=
=20
>>> this kind of concept be kicked out of the Working Draft before C++2a is=
=20
>>> shipped). But you definitely can't by any mental gymnastics claim that=
=20
>>> concept `EvenValue` is a "type function" or a "type of types" or anythi=
ng=20
>>> remotely like that.
>>>
>>>
>>> At around 1:06:30 in his talk Bjarne says:
>>>> * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS".
>>>>
>>>
>>> I believe that was an ad-lib not to be taken 100% literally. To a first=
=20
>>> approximation, a concept like Mergeable is a function mapping an ordere=
d=20
>>> tuple of types to a bool. But that doesn't mean that *all concepts ever=
*=20
>>> must be thought of as functions.
>>> That way lies functional programming and madness. ;)
>>>
>>> [...]
>>>
>>>> The Concepts defined in Bjarne's talk look more like variable=20
>>>> definitions *defined* in what feels (to me) like an odd mix of logic a=
nd=20
>>>> type like syntax:
>>>>
>>>> template<typename X> using Value_type =3D X::value_type;
>>>> template<typename X> using Iterator_of =3D X::iterator;
>>>>
>>>> template<typename For, typename For2, typename Out>
>>>> concept Mergable =3D
>>>> ForwardIterator<For>
>>>> && ForwardIterator<For2>
>>>> && OutputIterator<Out>
>>>> && Assignable<Value_type<For>,Value_type<Out>>
>>>> && Assignable<Value_type<For2>,Value_type<Out>>
>>>> && Comparable<Value_type<For>,Value_type<For2>>;
>>>>
>>>> The above looks like a variable definition. If it is not, then is it=
=20
>>>> right that it looks like one?
>>>> It's a definition, with conditional logic et al. i.e it uses &&. etc.=
=20
>>>> like an inline function.
>>>> So why are we defining it NOT using function like snytax?
>>>> Why is this a good thing?
>>>>
>>>
>>> Because of the first caveat I listed above: Concepts are not *just*=20
>>> predicates. They are logical predicates with deep structure, described =
by=20
>>> their *normal form*. For example, there is no special relationship=20
>>> between the variable templates
>>>
>>> template<class T> inline constexpr bool is_scalar_v =3D=20
>>> std::is_scalar<T>::value;
>>> template<class T> inline constexpr bool is_integral_v =3D=20
>>> is_scalar_v<T> && std::is_integral<T>::value;
>>>
>>> but there is a very special relationship between the concept( template)=
s
>>>
>>> template<class T> concept is_scalar_c =3D std::is_scalar<T>::value;
>>> template<class T> concept is_integral_c =3D is_scalar_c<T> &&=20
>>> std::is_integral<T>::value;
>>>
>>> The special relationship is called *subsumption*, and we say that=20
>>> is_integral_c<X> *subsumes* is_scalar_c<X>.
>>> If it weren't for subsumption, there would be no fundamental difference=
=20
>>> between a concept and a variable template of type `bool`.
>>>
>>> The compiler determines the subsumption relationships between concepts=
=20
>>> by cracking open their definitions and peering inside. The definitions =
are=20
>>> cracked open *only* along the boundaries of the logical `&&` and `||`=
=20
>>> operators. So it is critically important that the definition of a conce=
pt=20
>>> be a single logical expression. If a concept were allowed to be express=
ed=20
>>> as a function body, the compiler wouldn't be able to crack it open, lif=
t it=20
>>> into *normal form*, and figure out the *subsumption* relationships=20
>>> between this concept and all the other concepts in your program.
>>>
>>> Figuring out these relationships is important to the compiler because=
=20
>>> these relationships affect overload resolution.
>>>
>>> Please see my CppCon 2018 talk "Concepts as she is spoke"=20
>>> <https://www.youtube.com/watch?v=3DCXn02MPkn8Y> for a truly painful=20
>>> amount of information on how Concepts are different from plain old vari=
able=20
>>> templates.
>>>
>>> [...]
>>>
>>>> 1. If concepts ARE functions, why aren't we defining and using them=20
>>>> with function like syntax? And using () not <>.
>>>>
>>>
>>> I hope my answers above have pointed the way on this one.
>>> =20
>>>
>>>> 2. It seems J. Monnon's proposal is making the same point as I am, onl=
y=20
>>>> much better? Can we please address all that he proposes?
>>>>
>>>
>>> I think P0844 "Type functions and beyond"=20
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html>=
=20
>>> is thought-provoking. It's very large, though, which I believe is why i=
t's=20
>>> targeted at SG7 Compile-Time Programming (formerly SG7 Reflection).
>>> P0844 major section 3, "Concepts introducing types," seems to ignore th=
e=20
>>> existence of non-type concepts in the Working Draft. Perhaps there shou=
ld=20
>>> be a concerted effort to *kick non-type concepts out of the Working=20
>>> Draft* in order to gain some freedom of motion for these recurring=20
>>> theories of "concepts =3D=3D types of types."
>>> I do not believe that P0844 is making the same points (or, asking for=
=20
>>> clarification on the same points) as you are. I have only skimmed P0844=
,=20
>>> but it does not seem to be engaging with Concepts-as-they-are at all; i=
t=20
>>> seems to be trying to reuse Concepty words to refer to elements of the=
=20
>>> author's more na=C3=AFve "types of types" theory.
>>> (More na=C3=AFve is not necessarily bad! I think C++2a Concepts is *fa=
r*=20
>>> too much of an experts-only feature, and we could use a lot more naivet=
=C3=A9 in=20
>>> this area.)
>>>
>>> 3. I feel a more formal response to J. Monnon's paper from the main=20
>>>> proponents of Concepts as currently defined should be made before conc=
epts=20
>>>> get wired in any further in it's current direction?
>>>>
>>>> I know many people would like Concepts be the marquee feature of C++20=
,=20
>>>> but to me Concepts still seem quite away from where I'd like them to b=
e.
>>>> Even Bjarne can only 'begrudgingly live' with the current syntax.
>>>> All this flux and begrudging really doesn't suggest to me that Concept=
s=20
>>>> are ready to go for C++20.
>>>>
>>>
>>> FWIW, I agree with your conclusion.
>>> The question is, do C++2a Concepts need wholesale kicking-out, as=20
>>> happened in C++11? or can they be rescued by judicious cuts?
>>> The other question is, can anyone stop Concepts at this point or are th=
e=20
>>> wise people getting out of the way of the train? (Cynic says: observe t=
he=20
>>> recent formation of EWGI and LEWGI for those people tired of engaging w=
ith=20
>>> C++2a issues and eager to move on to C++2b.)
>>>
>>> =E2=80=93Arthur
>>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17eb2726-8f=
eb-4cdf-a58e-43d6dc81549a%40isocpp.org=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17eb2726-8=
feb-4cdf-a58e-43d6dc81549a%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/09414975-5749-4158-b9eb-897426556314%40isocpp.or=
g.
------=_Part_1345_1667251794.1540732215822
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, October 28, 2018 at 1:27:48 PM UTC+2, G=
a=C5=A1per A=C5=BEman wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">It might be useful to have a SmallerThan<int, int> con=
cept to check whether a type-erased type whose size is only known numerical=
ly can fit into an SBO buffer.<div><br></div><div>It's a bit of a stret=
ch, but might be a good case for keeping value concepts in, even if they on=
ly have rare usefulness.</div></div></blockquote><div><br></div><div>I just=
realized, with the downgrade of constexpr if to require a scope there is n=
o other way to check a class template argument.=C2=A0</div><div><br></div><=
div>template<GoodValue val>=C2=A0</div><div>class C</div><div>{</div>=
<div>=C2=A0 // ...</div><div>};</div><div><br></div><div><br></div><div>Als=
o, things will become genuinely interesting with custom class non-type temp=
late arguments.=C2=A0=C2=A0</div><div><br></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Sun, Oct 28, 2018 at 12:44 PM <<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"vbHgpB3KBgAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">mihailn...@gmail.com</a>> wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Arthur,=C2=A0<di=
v>If you don't think value concepts should not be in, then you should w=
rite a paper - it is probably worth a careful investigation.=C2=A0<div><br>=
</div><div>Should be noted, Concepts are <i>template argument filters</i> a=
nd as such people will argue that for consistency alone it is worth having =
concepts over values</div><div>simply because template arguments can be val=
ues as well.</div><div><br></div><div>That said,=C2=A0concepts over values =
might have outlived their usefulness with the introduction of static assert=
, constexpr if and contracts.</div><div><br></div><div>An investigating whe=
re exactly they are still useful will be nice to have, if for no other reas=
on then teachability.=C2=A0<br><div>=C2=A0<br><br>On Saturday, October 27, =
2018 at 11:27:58 PM UTC+3, Arthur O'Dwyer wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">On Wednesday, October 24, 2018 at 9:09:52=
PM UTC-4, <a>gmis...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>A few thoughts on Concepts:</div><div><br></di=
v><div>As Concepts have evolved, I have found it difficult to get a handle =
on what Concepts actually are.<br>i.e.: Are Concepts functions, types, or s=
omething else?</div></div></blockquote><div><br></div><div>Something else.<=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div><a href=3D"https://www.youtube.com/watch?v=3DHddFGPTAmtU" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.yout=
ube.com/watch?v\x3dHddFGPTAmtU';return true;" onclick=3D"this.href=3D&#=
39;https://www.youtube.com/watch?v\x3dHddFGPTAmtU';return true;">Bjarne=
's CppCon 2018 talk "Concepts: The Future of Generic Programming&q=
uot;</a> answers that question clearly.<br></div><p>In his talk, Bjarne say=
s:<br>* Concepts are NOT types of types. They are NOT type classes.<br></p>=
</div></blockquote><div><br></div><div>Well, they sort-of are. To a first a=
pproximation, they're predicates (type -> bool), which can be unders=
tood as partitions of the set of all types.</div><div>For any type T, eithe=
r T is-a Range or T is-not-a Range. So the set of Ranges is a subset of the=
set of all possible types.</div><div>BUT! Look closer and there are at lea=
st three caveats.</div><div>(1) Concepts have deep structure known as "=
;normal form"; see below.</div><div>(2) Concepts don't have to map=
(type -> bool); you can have multi-parameter concepts such as Convertib=
leTo<T,U>, which are not as easily to gloss as predicates over single=
types. (But darned if the Concepts TS doesn't try! For any type T, eit=
her T is-a ConvertibleTo<U> or T is-not-a ConvertibleTo<U>.)</d=
iv><div>(3) Concepts don't have to accept types at all. For example, yo=
u can make a concept that maps (int -> bool).</div><div><br></div><div>=
=C2=A0 =C2=A0 template<int V></div><div>=C2=A0 =C2=A0 concept EvenVal=
ue =3D ((V % 2) =3D=3D 0);</div><div><br></div><div>I don't think this =
kind of concept is useful in real code (I'd prefer this kind of concept=
be kicked out of the Working Draft before C++2a is shipped). But you defin=
itely can't by any mental gymnastics claim that concept `EvenValue`=C2=
=A0is a "type function" or a "type of types" or anythin=
g remotely like that.</div><div><br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><p>At around 1:06:30 in his talk Bj=
arne says:<br>* "it's just like defining functions, you *ARE* DEFI=
NING FUNCTIONS".</p></div></blockquote><div><br></div><div>I believe t=
hat was an ad-lib not to be taken 100% literally. To a first approximation,=
a concept like Mergeable is a function mapping an ordered tuple of types t=
o a bool. But that doesn't mean that <i>all concepts ever</i> must be t=
hought of as functions.</div><div>That way lies functional programming and =
madness. ;)</div><div><br></div><div>[...]</div><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"><div>The Concepts defined in Bjarne's tal=
k look more like variable definitions *defined* in what feels (to me) like =
an odd mix of logic and type like syntax:<br></div><p>template<typename =
X> using Value_type =3D X::value_type;<br>template<typename X> usi=
ng Iterator_of =3D X::iterator;</p><p>template<typename For, typename Fo=
r2, typename Out><br>concept Mergable =3D<br>=C2=A0=C2=A0=C2=A0 ForwardI=
terator<For><br>=C2=A0=C2=A0=C2=A0 && ForwardIterator<For2=
><br>=C2=A0=C2=A0=C2=A0 && OutputIterator<Out><br>=C2=A0=
=C2=A0=C2=A0 && Assignable<Value_type<For>,<wbr>Value_type=
<Out>><br>=C2=A0=C2=A0=C2=A0 && Assignable<Value_type&l=
t;For2>,<wbr>Value_type<Out>><br>=C2=A0=C2=A0=C2=A0 && =
Comparable<Value_type<For>,<wbr>Value_type<For2>>;</p><di=
v><br></div><div>The above looks like a variable definition. If it is not, =
then is it right that it looks like one?<br>It's a definition, with con=
ditional logic et al. i.e it uses &&. etc. like an inline function.=
<br></div><div>So why are we defining it NOT using function like snytax?<br=
>Why is this a good thing?</div></div></blockquote><div><br></div><div>Beca=
use of the first caveat I listed above: Concepts are not <i>just</i> predic=
ates. They are logical predicates with deep structure, described by their <=
i>normal form</i>. For example, there is no special relationship between th=
e variable templates</div><div><br></div><div>=C2=A0 =C2=A0 template<cla=
ss T> inline constexpr bool is_scalar_v =3D std::is_scalar<T>::val=
ue;</div><div>=C2=A0 =C2=A0 template<class T> inline constexpr bool i=
s_integral_v =3D is_scalar_v<T> && std::is_integral<T>:=
:value;</div><div><br></div><div>but there is a very special relationship b=
etween the concept( template)s</div><div><br></div><div><div>=C2=A0 =C2=A0 =
template<class T> concept is_scalar_c =3D std::is_scalar<T>::va=
lue;</div><div>=C2=A0 =C2=A0 template<class T> concept is_integral_c =
=3D is_scalar_c<T> && std::is_integral<T>::value;</div>=
</div><div><br></div><div>The special relationship is called <i>subsumption=
</i>, and we say that is_integral_c<X> <i>subsumes</i> is_scalar_c<=
;X>.</div><div>If it weren't for subsumption, there would be no fund=
amental difference between a concept and a variable template of type `bool`=
..</div><div><br></div><div>The compiler determines the subsumption relation=
ships between concepts by cracking open their definitions and peering insid=
e. The definitions are cracked open <i>only</i> along the boundaries of the=
logical `&&` and `||` operators. So it is critically important tha=
t the definition of a concept be a single logical expression. If a concept =
were allowed to be expressed as a function body, the compiler wouldn't =
be able to crack it open, lift it into <i>normal form</i>, and figure out t=
he <i>subsumption</i> relationships between this concept and all the other =
concepts in your program.</div><div><br></div><div>Figuring out these relat=
ionships is important to the compiler because these relationships affect ov=
erload resolution.</div><div><br></div><div>Please see my CppCon 2018 talk =
<a href=3D"https://www.youtube.com/watch?v=3DCXn02MPkn8Y" rel=3D"nofollow" =
target=3D"_blank" onmousedown=3D"this.href=3D'https://www.youtube.com/w=
atch?v\x3dCXn02MPkn8Y';return true;" onclick=3D"this.href=3D'https:=
//www.youtube.com/watch?v\x3dCXn02MPkn8Y';return true;">"Concepts =
as she is spoke"</a> for a truly painful amount of information on how =
Concepts are different from plain old variable templates.</div><div><br></d=
iv><div>[...]</div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>1. If concepts ARE functions, why aren't we defining and using th=
em with function like syntax? And using () not <>.<br></div></div></b=
lockquote><div><br></div><div>I hope my answers above have pointed the way =
on this one.</div><div>=C2=A0</div><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>2. It seems J. Monnon's proposal is making the s=
ame point as I am, only much better? Can we please address all that he prop=
oses?<br></div></div></blockquote><div><br></div><div>I think <a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html" rel=3D"=
nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.goog=
le.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2=
Fpapers%2F2018%2Fp0844r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFr_9=
YGZO5BDdyaSw7BW7ttm0_LQ';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg=
21%2Fdocs%2Fpapers%2F2018%2Fp0844r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNEFr_9YGZO5BDdyaSw7BW7ttm0_LQ';return true;">P0844 "Type func=
tions and beyond"</a> is thought-provoking. It's very large, thoug=
h, which I believe is why it's targeted at SG7 Compile-Time Programming=
(formerly SG7 Reflection).</div><div>P0844 major section 3, "Concepts=
introducing types," seems to ignore the existence of non-type concept=
s in the Working Draft. Perhaps there should be a concerted effort to <i>ki=
ck non-type concepts out of the Working Draft</i> in order to gain some fre=
edom of motion for these recurring theories of "concepts =3D=3D types =
of types."</div><div>I do not believe that P0844 is making the same po=
ints (or, asking for clarification on the same points) as you are. I have o=
nly skimmed P0844, but it does not seem to be engaging with Concepts-as-the=
y-are at all; it seems to be trying to reuse Concepty words to refer to ele=
ments of the author's more na=C3=AFve "types of types" theory=
..</div><div>(More na=C3=AFve is not necessarily bad!=C2=A0 I think C++2a Co=
ncepts is <i>far</i> too much of an experts-only feature, and we could use =
a lot more naivet=C3=A9 in this area.)</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div>3. I feel a more formal respo=
nse to J. Monnon's paper from the main proponents of Concepts as curren=
tly defined should be made before concepts get wired in any further in it&#=
39;s current direction?</div><div><br></div><div>I know many people would l=
ike Concepts be the marquee feature of C++20, but to me Concepts=C2=A0still=
seem quite away from where I'd like them to be.<br>Even Bjarne can onl=
y 'begrudgingly live' with the current syntax.<br>All this flux and=
begrudging really doesn't suggest to me that Concepts are ready to go =
for C++20.<br></div></div></blockquote><div><br></div><div>FWIW, I agree wi=
th your conclusion.</div><div>The question is, do C++2a Concepts need whole=
sale kicking-out, as happened in C++11? or can they be rescued by judicious=
cuts?</div><div>The other question is, can anyone stop Concepts at this po=
int or are the wise people getting out of the way of the train? (Cynic says=
: observe the recent formation of EWGI and LEWGI for those people tired of =
engaging with C++2a issues and eager to move on to C++2b.)</div><div><br></=
div><div>=E2=80=93Arthur</div></div></blockquote></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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
vbHgpB3KBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"vbHgpB3KBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/17eb2726-8feb-4cdf-a58e-43d6dc81549a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/17eb2726-8feb-4cdf-a58e-43d6dc81549a%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/17eb2726-8feb-4cdf-a58e-43d6dc81549a%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/17eb2726-8feb-4cdf-<wbr>a58e-=
43d6dc81549a%40isocpp.org</a><wbr>.<br>
</blockquote></div>
</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/09414975-5749-4158-b9eb-897426556314%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/09414975-5749-4158-b9eb-897426556314=
%40isocpp.org</a>.<br />
------=_Part_1345_1667251794.1540732215822--
------=_Part_1344_1942991597.1540732215821--
.
Author: Tom Honermann <tom@honermann.net>
Date: Mon, 29 Oct 2018 10:08:54 -0400
Raw View
This is a multi-part message in MIME format.
--------------C486CF5C0E2F856A50EC58EF
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
On 10/29/18 2:08 AM, gmisocpp@gmail.com wrote:
>
>
> On Sunday, October 28, 2018 at 9:27:58 AM UTC+13, Arthur O'Dwyer wrote:
>
> On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4,
> gmis...@gmail.com wrote:
>
> A few thoughts on Concepts:
>
> As Concepts have evolved, I have found it difficult to get a
> handle on what Concepts actually are.
> i.e.: Are Concepts functions, types, or something else?
>
>
> Something else.
>
> Bjarne's CppCon 2018 talk "Concepts: The Future of Generic
> Programming" <https://www.youtube.com/watch?v=3DHddFGPTAmtU>
> answers that question clearly.
>
> In his talk, Bjarne says:
> * Concepts are NOT types of types. They are NOT type classes.
>
>
> Well, they sort-of are. To a first approximation, they're
> predicates (type -> bool), which can be understood as partitions
> of the set of all types.
> For any type T, either T is-a Range or T is-not-a Range. So the
> set of Ranges is a subset of the set of all possible types.
> BUT! Look closer and there are at least three caveats.
> (1) Concepts have deep structure known as "normal form"; see below.
> (2) Concepts don't have to map (type -> bool); you can have
> multi-parameter concepts such as ConvertibleTo<T,U>, which are not
> as easily to gloss as predicates over single types. (But darned if
> the Concepts TS doesn't try! For any type T, either T is-a
> ConvertibleTo<U> or T is-not-a ConvertibleTo<U>.)
> (3) Concepts don't have to accept types at all. For example, you
> can make a concept that maps (int -> bool).
>
> =C2=A0 =C2=A0 template<int V>
> =C2=A0 =C2=A0 concept EvenValue =3D ((V % 2) =3D=3D 0);
>
> I don't think this kind of concept is useful in real code (I'd
> prefer this kind of concept be kicked out of the Working Draft
> before C++2a is shipped). But you definitely can't by any mental
> gymnastics claim that concept `EvenValue`=C2=A0is a "type function" o=
r
> a "type of types" or anything remotely like that.
>
>
> At around 1:06:30 in his talk Bjarne says:
> * "it's just like defining functions, you *ARE* DEFINING
> FUNCTIONS".
>
>
> I believe that was an ad-lib not to be taken 100% literally. To a
> first approximation, a concept like Mergeable is a function
> mapping an ordered tuple of types to a bool. But that doesn't mean
> that /all concepts ever/ must be thought of as functions.
> That way lies functional programming and madness. ;)
>
>
> See I think it can be taken pretty much 100% literally.
>
> From what I can tell,=C2=A0a Concept=C2=A0is=C2=A0100% a constexpr functi=
on.=C2=A0A=20
> concept=C2=A0function=C2=A0verifies that a given=C2=A0list of types (pass=
ed to that=20
> function) passed to it conform to a specification - as defined by the=20
> logic of that function. The name of the function signifies what the=20
> concept is.
> The function returns true if the types passed to the function meet the=20
> requirements of logic of the function and false if they do not.
>
> There=C2=A0may be=C2=A0more to=C2=A0how the=C2=A0compiler deals with such=
a function, but=20
> it seems to me that this minimum I've described above is true.
> Can we agree this far?
>
> If=C2=A0a concrete type is passed to a function as a parameter whose type=
=20
> is constrained by a Concept, the Concept function is called with the=20
> concrete type and if it returns false, it yields a compilation error.
> If a concrete type is returned from a function and assigned to a=20
> Concept variable the same check is performed. I'm sure this=20
> is=C2=A0reasonably off base but it seems like the gist of things. If this=
=20
> is correct or not though isn't the core of anything to me though. It's=20
> just how I'm visualizing it at the moment before I understand this=20
> more=C2=A0and subsumption and all of that.
>
> Why does thinking of all concepts as functions madness? Because it=20
> seems to me that's exactly what all concepts as currently discussed=20
> are. They ALL seem to be constexpr functions that take a list of types=20
> and return bool to indicate the types satisfy the concept or they=20
> don't. What more is there and where is the madness?
There is a fair amount of history here.=C2=A0 The model you are describing=
=20
was the basis for the Concepts Lite design that eventually became the=20
Concepts TS.=C2=A0 WG21 moved on from that model when integrating Concepts=
=20
into C++20.=C2=A0 Though concept definitions are, effectively, constexpr=20
predicates, specifying them as a new kind of entity avoids a fair amount=20
of special casing while also leaving more room for future evolution.
You might appreciate the analysis at=20
http://honermann.net/blog/2016/03/24/refining-concepts-the-quiddity-of-conc=
ept-definitions
Tom.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/f8d88afe-9de4-93b9-c8c0-e953be5f650d%40honermann=
..net.
--------------C486CF5C0E2F856A50EC58EF
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 10/29/18 2:08 AM, <a class=3D"moz-txt=
-link-abbreviated" href=3D"mailto:gmisocpp@gmail.com">gmisocpp@gmail.com</a=
>
wrote:<br>
</div>
<blockquote type=3D"cite"
cite=3D"mid:04c3ef3d-4950-47bf-9e32-6d48247a095e@isocpp.org">
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
<div dir=3D"ltr"><br>
<br>
On Sunday, October 28, 2018 at 9:27:58 AM UTC+13, Arthur O'Dwyer
wrote:
<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;">
<div dir=3D"ltr">On Wednesday, October 24, 2018 at 9:09:52 PM
UTC-4, <a moz-do-not-send=3D"true">gmis...@gmail.com</a>
wrote:
<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;">
<div dir=3D"ltr">
<div>A few thoughts on Concepts:</div>
<div><br>
</div>
<div>As Concepts have evolved, I have found it difficult
to get a handle on what Concepts actually are.<br>
i.e.: Are Concepts functions, types, or something
else?</div>
</div>
</blockquote>
<div><br>
</div>
<div>Something else.</div>
<div>=C2=A0</div>
<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;">
<div dir=3D"ltr">
<div><a
onmousedown=3D"this.href=3D'https://www.youtube.com/watch?v\x3dHddFGPTAmtU'=
;return
true;"
onclick=3D"this.href=3D'https://www.youtube.com/watch?v\x3dHddFGPTAmtU';ret=
urn
true;"
href=3D"https://www.youtube.com/watch?v=3DHddFGPTAmtU"
target=3D"_blank" rel=3D"nofollow"
moz-do-not-send=3D"true">Bjarne's CppCon 2018 talk
"Concepts: The Future of Generic Programming"</a>
answers that question clearly.<br>
</div>
<p>In his talk, Bjarne says:<br>
* Concepts are NOT types of types. They are NOT type
classes.<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>Well, they sort-of are. To a first approximation,
they're predicates (type -> bool), which can be
understood as partitions of the set of all types.</div>
<div>For any type T, either T is-a Range or T is-not-a
Range. So the set of Ranges is a subset of the set of all
possible types.</div>
<div>BUT! Look closer and there are at least three caveats.</di=
v>
<div>(1) Concepts have deep structure known as "normal
form"; see below.</div>
<div>(2) Concepts don't have to map (type -> bool); you
can have multi-parameter concepts such as
ConvertibleTo<T,U>, which are not as easily to gloss
as predicates over single types. (But darned if the
Concepts TS doesn't try! For any type T, either T is-a
ConvertibleTo<U> or T is-not-a
ConvertibleTo<U>.)</div>
<div>(3) Concepts don't have to accept types at all. For
example, you can make a concept that maps (int ->
bool).</div>
<div><br>
</div>
<div>=C2=A0 =C2=A0 template<int V></div>
<div>=C2=A0 =C2=A0 concept EvenValue =3D ((V % 2) =3D=3D 0);</d=
iv>
<div><br>
</div>
<div>I don't think this kind of concept is useful in real
code (I'd prefer this kind of concept be kicked out of the
Working Draft before C++2a is shipped). But you definitely
can't by any mental gymnastics claim that concept
`EvenValue`=C2=A0is a "type function" or a "type of types" or
anything remotely like that.</div>
<div><br>
</div>
<div><br>
</div>
<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;">
<div dir=3D"ltr">
<p>At around 1:06:30 in his talk Bjarne says:<br>
* "it's just like defining functions, you *ARE*
DEFINING FUNCTIONS".</p>
</div>
</blockquote>
<div><br>
</div>
<div>I believe that was an ad-lib not to be taken 100%
literally. To a first approximation, a concept like
Mergeable is a function mapping an ordered tuple of types
to a bool. But that doesn't mean that <i>all concepts
ever</i> must be thought of as functions.</div>
<div>That way lies functional programming and madness. ;)</div>
</div>
</blockquote>
<div><br>
</div>
<div>See I think it can be taken pretty much 100% literally.</div>
<div><br>
</div>
<div>From what I can tell,=C2=A0a Concept=C2=A0is=C2=A0100% a const=
expr
function.=C2=A0A concept=C2=A0function=C2=A0verifies that a given=
=C2=A0list of
types (passed to that function) passed to it conform to a
specification - as defined by the logic of that function. The
name of the function signifies what the concept is.<br>
The function returns true if the types passed to the function
meet the requirements of logic of the function and false if
they do not.</div>
<div><br>
</div>
<div>There=C2=A0may be=C2=A0more to=C2=A0how the=C2=A0compiler deal=
s with such a
function, but it seems to me that this minimum I've described
above is true.</div>
<div>Can we agree this far?</div>
<div><br>
</div>
<div>If=C2=A0a concrete type is passed to a function as a parameter
whose type is constrained by a Concept, the Concept function
is called with the concrete type and if it returns false, it
yields a compilation error.<br>
If a concrete type is returned from a function and assigned to
a Concept variable the same check is performed. I'm sure this
is=C2=A0reasonably off base but it seems like the gist of things.
If this is correct or not though isn't the core of anything to
me though. It's just how I'm visualizing it at the moment
before I understand this more=C2=A0and subsumption and all of tha=
t.</div>
<div><br>
</div>
<div>Why does thinking of all concepts as functions madness?
Because it seems to me that's exactly what all concepts as
currently discussed are. They ALL seem to be constexpr
functions that take a list of types and return bool to
indicate the types satisfy the concept or they don't. What
more is there and where is the madness?</div>
</div>
</blockquote>
<p>There is a fair amount of history here.=C2=A0 The model you are
describing was the basis for the Concepts Lite design that
eventually became the Concepts TS.=C2=A0 WG21 moved on from that mode=
l
when integrating Concepts into C++20.=C2=A0 Though concept definition=
s
are, effectively, constexpr predicates, specifying them as a new
kind of entity avoids a fair amount of special casing while also
leaving more room for future evolution.<br>
</p>
<p>You might appreciate the analysis at
<a class=3D"moz-txt-link-freetext" href=3D"http://honermann.net/blog/2016/0=
3/24/refining-concepts-the-quiddity-of-concept-definitions">http://honerman=
n.net/blog/2016/03/24/refining-concepts-the-quiddity-of-concept-definitions=
</a></p>
<p>Tom.<br>
</p>
</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/f8d88afe-9de4-93b9-c8c0-e953be5f650d%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/f8d88afe-9de4-93b9-c8c0-e953be5f6=
50d%40honermann.net</a>.<br />
--------------C486CF5C0E2F856A50EC58EF--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Sun, 4 Nov 2018 15:11:51 -0500
Raw View
--000000000000bae0e90579dc6199
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, Oct 29, 2018 at 2:08 AM <gmisocpp@gmail.com> wrote:
> On Sunday, October 28, 2018 at 9:27:58 AM UTC+13, Arthur O'Dwyer wrote:
>>
>> On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, gmis...@gmail.com
>> wrote:
>>>
>>> A few thoughts on Concepts:
>>>
>>> As Concepts have evolved, I have found it difficult to get a handle on
>>> what Concepts actually are.
>>> i.e.: Are Concepts functions, types, or something else?
>>>
>>
>> Something else.
>>
>> [...] To a first approximation, they're predicates (type -> bool), which
>> can be understood as partitions of the set of all types.
>> For any type T, either T is-a Range or T is-not-a Range. So the set of
>> Ranges is a subset of the set of all possible types.
>> BUT! Look closer and there are at least three caveats.
>> (1) Concepts have deep structure known as "normal form"; see below.
>> (2) Concepts don't have to map (type -> bool); you can have
>> multi-parameter concepts such as ConvertibleTo<T,U> [...]
>> (3) Concepts don't have to accept types at all. [...]
>>
>>> At around 1:06:30 in his talk Bjarne says:
>>> * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS".
>>>
>> I believe that was an ad-lib not to be taken 100% literally. To a first
>> approximation, a concept *like Mergeable* [emphasis added =E2=80=94A] is=
a
>> function mapping an ordered tuple of types to a bool. But that doesn't m=
ean
>> that *all concepts ever* must be thought of as functions.
>>
>
> See I think it can be taken pretty much 100% literally.
>
> From what I can tell, a Concept is 100% a constexpr function. A
> concept function verifies that a given list of types (passed to that
> function) passed to it conform to a specification - as defined by the log=
ic
> of that function. The name of the function signifies what the concept is.
> The function returns true if the types passed to the function meet the
> requirements of logic of the function and false if they do not.
>
> There may be more to how the compiler deals with such a function, but it
> seems to me that this minimum I've described above is true.
> Can we agree this far?
>
A Concept is a "constexpr function" from
some-inputs-that-may-or-may-not-be-types to `bool`, yes, *but also more*.
The "more" is the part you hadn't yet discovered, i.e., subsumption and
normal form.
If a concrete type is passed to a function as a parameter whose type is
> constrained by a Concept, the Concept function is called with the concret=
e
> type and if it returns false, it yields a compilation error.
> If a concrete type is returned from a function and assigned to a Concept
> variable the same check is performed. I'm sure this is reasonably off bas=
e
> but it seems like the gist of things. If this is correct or not though
> isn't the core of anything to me though. It's just how I'm visualizing it
> at the moment before I understand this more and subsumption and all of th=
at.
>
> Why does thinking of all concepts as functions madness? Because it seems
> to me that's *exactly* [emphasis added =E2=80=94A] what all concepts as c=
urrently
> discussed are.
>
All concepts are "functions" in that sense, *but also more*. You are wrong
when you say that a concept is *exactly* a function.
[...]
>> Please see my CppCon 2018 talk "Concepts as she is spoke"
>> <https://www.youtube.com/watch?v=3DCXn02MPkn8Y> for a truly painful amou=
nt
>> of information on how Concepts are different from plain old variable
>> templates.
>>
>
> [...] I think Concept definitions need to retain a similar functional fee=
l
> and that means exposing Concepts to look more like the functions and
> enabling them to be defined more like that. Or at least it's not clear to
> me why we can't and shouldn't go further down that road.
>
Because if you replace all your C++2a Concepts with plain old functions,
you slice away the one way in which a C++2a Concept is *more than* a plain
old function. Namely, subsumption.
By the way, the "plain old constraint on a function template" part of a
Concept can be perfectly forwarded through a forwarding wrapper.
The "subsumption" part of a Concept *cannot* (as of the C++2a Working
Draft) be forwarded through a forwarding wrapper (and I'm not aware of any
proposal on the table to fix that).
Example:
https://concepts.godbolt.org/z/StUlc4
I think C++2a's subsumption rules are fairly problematic. I think that the
reason they're problematic is that they're *new* =E2=80=94 they're literall=
y the
one new thing about C++2a concepts relative to C++17 traits, so of course
they are the least baked. Everything else about C++2a Concepts is
essentially unchanged since C++03: If you understand C++03 traits-based
metaprogramming, then you understand everything about C++2a Concepts =E2=80=
=94 *except
for subsumption*.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0L6Fq6NKY-_-OGvA-mg6DuHkoTgC6%2BivpwJimiOB=
xDbiQ%40mail.gmail.com.
--000000000000bae0e90579dc6199
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Oct 29, 2018 at 2:08 AM <<a hr=
ef=3D"mailto:gmisocpp@gmail.com">gmisocpp@gmail.com</a>> wrote:<br><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-co=
lor:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">On Sunday, October =
28, 2018 at 9:27:58 AM UTC+13, Arthur O'Dwyer wrote:<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">=
<div dir=3D"ltr">On Wednesday, October 24, 2018 at 9:09:52 PM UTC-4, <a>gmi=
s...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);borde=
r-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>A few thoug=
hts on Concepts:</div><div><br></div><div>As Concepts have evolved, I have =
found it difficult to get a handle on what Concepts actually are.<br>i.e.: =
Are Concepts functions, types, or something else?</div></div></blockquote><=
div><br></div><div>Something else.</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-lef=
t-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><di=
v dir=3D"ltr"><div></div></div></blockquote><div>[...] To a first approxima=
tion, they're predicates (type -> bool), which can be understood as =
partitions of the set of all types.</div><div>For any type T, either T is-a=
Range or T is-not-a Range. So the set of Ranges is a subset of the set of =
all possible types.</div><div>BUT! Look closer and there are at least three=
caveats.</div><div>(1) Concepts have deep structure known as "normal =
form"; see below.</div><div>(2) Concepts don't have to map (type -=
> bool); you can have multi-parameter concepts such as ConvertibleTo<=
T,U> [...]</div><div>(3) Concepts don't have to accept types at all.=
[...]</div><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"><div dir=3D"ltr"><p>At around 1:06:30 in his t=
alk Bjarne says:<br>* "it's just like defining functions, you *ARE=
* DEFINING FUNCTIONS".</p></div></blockquote><div>I believe that was a=
n ad-lib not to be taken 100% literally. To a first approximation, a concep=
t <i><b>like Mergeable</b></i>=C2=A0[emphasis added =E2=80=94A] is a functi=
on mapping an ordered tuple of types to a bool. But that doesn't mean t=
hat <i>all concepts ever</i> must be thought of as functions.</div></div></=
blockquote><div><br></div><div>See I think it can be taken pretty much 100%=
literally.</div><div><br></div><div>From what I can tell,=C2=A0a Concept=
=C2=A0is=C2=A0100% a constexpr function.=C2=A0A concept=C2=A0function=C2=A0=
verifies that a given=C2=A0list of types (passed to that function) passed t=
o it conform to a specification - as defined by the logic of that function.=
The name of the function signifies what the concept is.<br>The function re=
turns true if the types passed to the function meet the requirements of log=
ic of the function and false if they do not.</div><div><br></div><div>There=
=C2=A0may be=C2=A0more to=C2=A0how the=C2=A0compiler deals with such a func=
tion, but it seems to me that this minimum I've described above is true=
..</div><div>Can we agree this far?</div></div></blockquote><div><br></div><=
div>A Concept is a "constexpr function" from some-inputs-that-may=
-or-may-not-be-types to `bool`, yes, <i>but also more</i>.=C2=A0 The "=
more" is the part you hadn't yet discovered, i.e., subsumption and=
normal form.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
If=C2=A0a concrete type is passed to a function as a parameter whose type i=
s constrained by a Concept, the Concept function is called with the concret=
e type and if it returns false, it yields a compilation error.<br>If a conc=
rete type is returned from a function and assigned to a Concept variable th=
e same check is performed. I'm sure this is=C2=A0reasonably off base bu=
t it seems like the gist of things. If this is correct or not though isn=
9;t the core of anything to me though. It's just how I'm visualizin=
g it at the moment before I understand this more=C2=A0and subsumption and a=
ll of that.</div><div><br></div><div>Why does thinking of all concepts as f=
unctions madness? Because it seems to me that's <i><b>exactly</b></i>=
=C2=A0[emphasis added =E2=80=94A] what all concepts as currently discussed =
are.</div></div></blockquote><div><br></div><div>All concepts are "fun=
ctions" in that sense, <i>but also more</i>.=C2=A0 You are wrong when =
you say that a concept is <i><b>exactly</b></i> a function.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" st=
yle=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"><div dir=3D"ltr"><d=
iv>[...]</div><div>Please see my CppCon 2018 talk <a href=3D"https://www.yo=
utube.com/watch?v=3DCXn02MPkn8Y" rel=3D"nofollow" target=3D"_blank">"C=
oncepts as she is spoke"</a> for a truly painful amount of information=
on how Concepts are different from plain old variable templates.</div></di=
v></blockquote></div></blockquote><div>=C2=A0<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div>[...] I think Concept definitions=C2=A0need to retain=C2=
=A0a similar=C2=A0functional feel and that means exposing Concepts to look =
more like the functions and enabling them to be defined more like that. Or =
at least it's not clear to me why we can't and shouldn't=C2=A0g=
o further down that road.</div></div></blockquote><div><br></div><div>Becau=
se if you replace all your C++2a Concepts with plain old functions, you sli=
ce away the one way in which a C++2a Concept is <i>more than</i> a plain ol=
d function. Namely, subsumption.</div><div><br></div><div>By the way, the &=
quot;plain old constraint on a function template" part of a Concept ca=
n be perfectly forwarded through a forwarding wrapper.</div><div>The "=
subsumption" part of a Concept <i><b>cannot</b></i>=C2=A0(as of the C+=
+2a Working Draft) be forwarded through a forwarding wrapper (and I'm n=
ot aware of any proposal on the table to fix that).</div><div>Example:</div=
><div><a href=3D"https://concepts.godbolt.org/z/StUlc4">https://concepts.go=
dbolt.org/z/StUlc4</a></div><div><br></div><div>I think C++2a's subsump=
tion rules are fairly problematic. I think that the reason they're prob=
lematic is that they're <i>new</i> =E2=80=94 they're literally the =
one new thing about C++2a concepts relative to C++17 traits, so of course t=
hey are the least baked. Everything else about C++2a Concepts is essentiall=
y unchanged since C++03: If you understand C++03 traits-based metaprogrammi=
ng, then you understand everything about C++2a Concepts =E2=80=94=C2=A0<i>e=
xcept for subsumption</i>.</div><div><br></div><div>=E2=80=93Arthur</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/CADvuK0L6Fq6NKY-_-OGvA-mg6DuHkoTgC6%2=
BivpwJimiOBxDbiQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0L6Fq6NKY=
-_-OGvA-mg6DuHkoTgC6%2BivpwJimiOBxDbiQ%40mail.gmail.com</a>.<br />
--000000000000bae0e90579dc6199--
.