------=_Part_20725_1091982472.1527983850457
Content-Type: multipart/alternative;
 boundary="----=_Part_20726_1418043415.1527983850457"

------=_Part_20726_1418043415.1527983850457
Content-Type: text/plain; charset="UTF-8"

This is a question/issue I have stumbled upon while trying out the concepts
TS, I hope this is the right forum.
Please forgive my syntax errors as I'm new to concepts.
I have the following situation:

template<typename T> concept VeryGeneral = requires
{
    void T::general_fn();
};


template<VeryGeneral T> concept Specifc = requires
{
    void T::specific_fn();
};

Now the `general_fn` in `Specific` implementations can logically be
implemented using `specific_fn`, for example:
template<typename T> requries Specific<T>
void general_fn_impl_for_any_specific(T t) {
    if (bla)
        t.specific_fn();
}

I don't want the users to this manually, so I want to give them a CRTP base
class (or just some adaptor type) that does that for them:

Note: A concrete example for this problem is `Iterator` and an
`iterator_facade` library that uses a concept called `Cursor` for users to
implement more simply (this is an oversimplification of the problem as
there is only one concept, but it seems close enough).

Here is the problem: The concept users need to implement (if they use the
adaptor) is not properly defined.
There are two options to expose as the library author:

   1. The subset of `Specific` that is not provided by the adaptor type.
   2. Create a concept for exactly this subset.

The problem with the first approach is that users implementing the concepts
can't properly understand what they need to implement on the API level from
the concepts defintion (which defeats the purpose of the concepts TS).

The problem with second approach the user now has to remember two versions
of the same concepts: one to use and one to implement.
If the concepts library is composed of many building blocks this becomes
true for the entire library, which to me is terrible design and confusing
(especially as concept decoupling is encouraged by the commitee - at least
in Bjarne's How to design good concepts and use them well
<http://wg21.link/P0557>).

Is this fragmentation nescessary? Is there any mechanism in the TS (or what
was already merged, or the Ranges TS, or whatever...) to prevent this from
happening? Was this problem disscussed before?

--
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/f686b7c7-83c4-4779-9f91-316bbe3bab4b%40isocpp.org.

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

<div dir=3D"ltr">This is a question/issue I have stumbled upon while trying=
 out the concepts TS, I hope this is the right forum.<div>Please forgive my=
 syntax errors as I&#39;m new to concepts.<br><div>I have the following sit=
uation:</div><div><br></div><div><div class=3D"prettyprint" style=3D"border=
-width: 1px; border-style: solid; border-color: rgb(187, 187, 187); backgro=
und-color: rgb(250, 250, 250); word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><font color=3D"#660066"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">concept</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">VeryGeneral</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> requires<b=
r></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">general_fn</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">template</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">VeryGeneral</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">conc=
ept</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Specifc</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> requires<br></span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">specific_fn</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">};</span></font></div></code></div><br>Now the `general_fn` in `Spe=
cific` implementations can logically be implemented using `specific_fn`, fo=
r example:</div><div><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div=
 class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">template</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> requries </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Specific</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> general_fn_impl_for_any_=
specific</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">T t</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">bla</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 t</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">specific_fn</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}<=
/span></font></div></code></div><br></div><div>I don&#39;t want the users t=
o this manually, so I want to give them a CRTP base class (or just some ada=
ptor type) that does that for them:</div><div><br></div><div>Note: A concre=
te example for this problem is `Iterator` and an `iterator_facade` library =
that uses a concept called `Cursor` for users to implement more simply (thi=
s is an oversimplification of the problem as there is only one concept, but=
 it seems close enough).<br></div><div><br></div><div>Here is the problem: =
The concept users need to implement (if they use the adaptor) is not proper=
ly defined.</div><div>There are two options to expose as the library author=
:</div><div><ol><li>The subset of `Specific` that is not provided by the ad=
aptor type.</li><li>Create a concept for exactly this subset.</li></ol><div=
>The problem with the first approach is that users implementing the concept=
s can&#39;t properly understand what they need to implement on the API leve=
l from the concepts defintion (which defeats the purpose of the concepts TS=
).</div><div><br></div><div>The problem with second approach the user now h=
as to remember two versions of the same concepts: one to use and one to imp=
lement.</div></div><div>If the concepts library is composed of many buildin=
g blocks this becomes true for the entire library, which to me is terrible =
design and confusing (especially as concept decoupling is encouraged by the=
 commitee - at least in Bjarne&#39;s=C2=A0<a href=3D"http://wg21.link/P0557=
">How to design good concepts and use them well</a>).</div><div><br></div><=
div>Is this fragmentation nescessary? Is there any mechanism in the TS (or =
what was already merged, or the Ranges TS, or whatever...) to prevent this =
from happening? Was this problem disscussed before?</div><div><br></div></d=
iv></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f686b7c7-83c4-4779-9f91-316bbe3bab4b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f686b7c7-83c4-4779-9f91-316bbe3bab4b=
%40isocpp.org</a>.<br />

------=_Part_20726_1418043415.1527983850457--

------=_Part_20725_1091982472.1527983850457--

.

--000000000000469712056db2a21f
Content-Type: text/plain; charset="UTF-8"

On Sun, 3 Jun 2018, 00:57 Omer Rosler <omer.rosler@gmail.com> wrote:

> This is a question/issue I have stumbled upon while trying out the
> concepts TS, I hope this is the right forum.
>

This kind of thing is well suited here. Although this is generally for
bringing an idea to a proposal worthy state, critiques of current proposals
and problems with accepted proposals are common and welcome.

"Here is the problem: The concept users need to implement (if they use the
adaptor) is not properly defined."

Can you elaborate on this problem you describe with a further code sample?
Something a little more concrete to work with - I got a little lost trying
to understand your conclusion.

--
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/CAC%2B0CCMee4%3DAGpF3%3D9mazT1UwxFqobdJ-kpHyE%2B82O2UmmQtDQ%40mail.gmail.com.

--000000000000469712056db2a21f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, =
3 Jun 2018, 00:57 Omer Rosler &lt;<a href=3D"mailto:omer.rosler@gmail.com" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">omer.rosler@gmai=
l.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">This is a question/issue I have stumbled upon while trying out the conce=
pts TS, I hope this is the right forum.</div></blockquote></div></div><div =
dir=3D"auto"></div><div dir=3D"auto"><br></div><div dir=3D"auto">This kind =
of thing is well suited here. Although this is generally for bringing an id=
ea to a proposal worthy state, critiques of current proposals and problems =
with accepted proposals are common and welcome.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto"><span style=3D"font-family:sans-serif;font-size:12.=
8px">&quot;Here is the problem: The concept users need to implement (if the=
y use the adaptor) is not properly defined.&quot;</span></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Can you elaborate on this problem you desc=
ribe with a further code sample? Something a little more concrete to work w=
ith - I got a little lost trying to understand your conclusion.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCMee4%3DAGpF3%3D9mazT1UwxFqob=
dJ-kpHyE%2B82O2UmmQtDQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CC=
Mee4%3DAGpF3%3D9mazT1UwxFqobdJ-kpHyE%2B82O2UmmQtDQ%40mail.gmail.com</a>.<br=
 />

--000000000000469712056db2a21f--

.

------=_Part_19391_1506462426.1527991174651
Content-Type: multipart/alternative;
 boundary="----=_Part_19392_61113823.1527991174651"

------=_Part_19392_61113823.1527991174651
Content-Type: text/plain; charset="UTF-8"

On Saturday, June 2, 2018 at 7:57:30 PM UTC-4, Omer Rosler wrote:
>
> The problem with second approach the user now has to remember two versions
> of the same concepts: one to use and one to implement.
>

How many times have you used an iterator? I bet it's several orders of
magnitude more often than you've *written one*.

Yes, your library has two concepts. But they aren't two versions of the
*same* concept. There's the Iterator concept, and there's the
ThingThatThisToolTurnsIntoAnIterator concept. Those aren't the same thing;
indeed, more likely than not, they are quite dissimilar. They have
different interfaces and different purposes.

Users don't have to remember the ThingThatThisToolTurnsIntoAnIterator
concept, because they simply don't use it very often. When they need to use
it, they'll look up what it does and how it works. What they're going to
*remember* is Iterator, because that's what they're using most of the time.

--
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/48f336e3-146b-4317-8a60-1a3acc16af4b%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, June 2, 2018 at 7:57:30 PM UTC-4, Omer Rosler=
 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"><div><=
div><div>The problem with second approach the user now has to remember two =
versions of the same concepts: one to use and one to implement.</div></div>=
</div></div></blockquote><div><br></div><div>How many times have you used a=
n iterator? I bet it&#39;s several orders of magnitude more often than you&=
#39;ve <i>written one</i>.</div><div><br></div><div>Yes, your library has t=
wo concepts. But they aren&#39;t two versions of the <i>same</i> concept. T=
here&#39;s the Iterator concept, and there&#39;s the ThingThatThisToolTurns=
IntoAnIterator concept. Those aren&#39;t the same thing; indeed, more likel=
y than not, they are quite dissimilar. They have different interfaces and d=
ifferent purposes.</div><div><br></div><div>Users don&#39;t have to remembe=
r the ThingThatThisToolTurnsIntoAnIterator concept, because they simply don=
&#39;t use it very often. When they need to use it, they&#39;ll look up wha=
t it does and how it works. What they&#39;re going to <i>remember</i> is It=
erator, because that&#39;s what they&#39;re using most of the time.</div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/48f336e3-146b-4317-8a60-1a3acc16af4b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/48f336e3-146b-4317-8a60-1a3acc16af4b=
%40isocpp.org</a>.<br />

------=_Part_19392_61113823.1527991174651--

------=_Part_19391_1506462426.1527991174651--

.

------=_Part_23003_970630986.1528044488303
Content-Type: text/plain; charset="UTF-8"

On Sunday, June 3, 2018 at 4:21:19 AM UTC+3, Jake Arkinstall wrote:
> On Sun, 3 Jun 2018, 00:57 Omer Rosler <omer....@gmail.com> wrote:
>
> This is a question/issue I have stumbled upon while trying out the concepts TS, I hope this is the right forum.
>
>
>
> This kind of thing is well suited here. Although this is generally for bringing an idea to a proposal worthy state, critiques of current proposals and problems with accepted proposals are common and welcome.
>
>
> "Here is the problem: The concept users need to implement (if they use the adaptor) is not properly defined."
>
>
> Can you elaborate on this problem you describe with a further code sample? Something a little more concrete to work with - I got a little lost trying to understand your conclusion.

Think of a node library that abstracts away both memory access and connections between the nodes:

`template<typename T> concept DAGNode = requires {
    typename T::children_router_type;
    T T::get_child(children_router_type child_connection);
};
`
Now for a much more specific concepts - that of a binary tree node:
`
enum binary_node_connections
{
    left,
    right
};
template<DAGNode T> concept BinaryTreeNode = requires
{
    requires std::is_same_v<typename T::children_router_type, binary_node_connections>;

    T get_right();
    T get_left();
};
`

The interface that is exposed by the concept is supposed to be getting nodes by the specific functions - get_right and get_left
The default implementation of `get_child` using those methods can be given by a CRTP base, but then for node classes implementors this is a whole new concept to implement.
This is the underlying problem, especially if every concept does that.
For example we might add traversal requirement for any `DAGNode` or add a `BinarySearchTreeNode` for balanced trees that adds a search member function, etc etc.
This doubles the number of concepts. And completely separates users from implementers.

--
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/3eaf8f38-0284-424b-9dc8-10db869fdb69%40isocpp.org.

------=_Part_23003_970630986.1528044488303--

.

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

On Sunday, June 3, 2018 at 4:59:34 AM UTC+3, Nicol Bolas wrote:
> On Saturday, June 2, 2018 at 7:57:30 PM UTC-4, Omer Rosler wrote:
>=20
>=20
>=20
> The problem with second approach the user now has to remember two version=
s of the same concepts: one to use and one to implement.
>=20
>=20
> How many times have you used an iterator? I bet it's several orders of ma=
gnitude more often than you've written one.
>=20
>=20
> Yes, your library has two concepts. But they aren't two versions of the s=
ame concept. There's the Iterator concept, and there's the ThingThatThisToo=
lTurnsIntoAnIterator concept. Those aren't the same thing; indeed, more lik=
ely than not, they are quite dissimilar. They have different interfaces and=
 different purposes.
>=20
>=20
> Users don't have to remember the ThingThatThisToolTurnsIntoAnIterator con=
cept, because they simply don't use it very often. When they need to use it=
, they'll look up what it does and how it works. What they're going to reme=
mber is Iterator, because that's what they're using most of the time.

Well the iterator comparison for the ratio of uses/implementations is not f=
air as this is not the case for every concept library out there.=20

There is a second problem with this separation into two concepts:
Consider a customization point in the users' concepts that is given via a t=
raits class.
If that customization is not given by the ThingThatTurnsIntoMyConcept (then=
 this concept also has a traits class) then users and implementers use diff=
erent customization points which costs the library in a lot more metaprogra=
mming pain just because it uses concepts.

--=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/e21d8a37-1e22-41b2-beef-b0d21f2886b6%40isocpp.or=
g.

------=_Part_26135_692902384.1528045292855--

.

------=_Part_18562_1769981434.1528051621775
Content-Type: multipart/alternative;
 boundary="----=_Part_18563_1747966124.1528051621776"

------=_Part_18563_1747966124.1528051621776
Content-Type: text/plain; charset="UTF-8"

On Sunday, June 3, 2018 at 1:01:32 PM UTC-4, Omer Rosler wrote:
>
> On Sunday, June 3, 2018 at 4:59:34 AM UTC+3, Nicol Bolas wrote:
> > On Saturday, June 2, 2018 at 7:57:30 PM UTC-4, Omer Rosler wrote:
> >
> >
> >
> > The problem with second approach the user now has to remember two
> versions of the same concepts: one to use and one to implement.
> >
> >
> > How many times have you used an iterator? I bet it's several orders of
> magnitude more often than you've written one.
> >
> >
> > Yes, your library has two concepts. But they aren't two versions of the
> same concept. There's the Iterator concept, and there's the
> ThingThatThisToolTurnsIntoAnIterator concept. Those aren't the same thing;
> indeed, more likely than not, they are quite dissimilar. They have
> different interfaces and different purposes.
> >
> >
> > Users don't have to remember the ThingThatThisToolTurnsIntoAnIterator
> concept, because they simply don't use it very often. When they need to use
> it, they'll look up what it does and how it works. What they're going to
> remember is Iterator, because that's what they're using most of the time.
>
> Well the iterator comparison for the ratio of uses/implementations is not
> fair as this is not the case for every concept library out there.
>
There is a second problem with this separation into two concepts:
> Consider a customization point in the users' concepts that is given via a
> traits class.
> If that customization is not given by the ThingThatTurnsIntoMyConcept
> (then this concept also has a traits class) then users and implementers use
> different customization points which costs the library in a lot more
> metaprogramming pain just because it uses concepts.
>

Let's be more specific about the problem, using iterators as kind of a
model for the idea.

Iterators have a lot of interfaces. This makes them easy to use, so those
interfaces provide value. So that's your "consumption concept", one that's
optimized based on the usefulness to the code using such objects.

But implementing iterators, particularly from range-like starting points,
is painful. It often requires a lot of repetition or writing a lot of
boilerplate. You could imagine a far more simplified interface. But you
don't want users to *use* that interface, because the interface is less
usable than the Iterator interface. This is your "implementation concept".

These two concepts have *nothing* to do with one another. They are two
different concepts for two different users with two different use cases.
The only association between them is that there is some piece of
metaprogramming code which takes objects which abide by the implementation
concept and generates objects for the consumption concept.

But this is merely a *helper tool* for the consumption concept. It is not a
fundamental or essential part of that concept. After all, nobody is
*forcing* you to use this particular tool. If you want to write your
Iterator type without help, you certainly can do so. As long as you conform
to the consumption concept, you're fine.

Not only that, you can have *multiple* such tools, each of which has their
own concept model. You can write a tool that takes Java-style iterators and
generates code for STL-style iterators. Or vice-versa.

So I fail to see the problem here.

--
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/bb8f21fb-3f6c-4905-a8b9-688cb15f5e30%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, June 3, 2018 at 1:01:32 PM UTC-4, Omer Rosler w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On Sunday, June 3, 2018 a=
t 4:59:34 AM UTC+3, Nicol Bolas wrote:<br>&gt; On Saturday, June 2, 2018 at=
 7:57:30 PM UTC-4, Omer Rosler wrote:<br>&gt; <br>&gt; <br>&gt; <br>&gt; Th=
e problem with second approach the user now has to remember two versions of=
 the same concepts: one to use and one to implement.<br>&gt; <br>&gt; <br>&=
gt; How many times have you used an iterator? I bet it&#39;s several orders=
 of magnitude more often than you&#39;ve written one.<br>&gt; <br>&gt; <br>=
&gt; Yes, your library has two concepts. But they aren&#39;t two versions o=
f the same concept. There&#39;s the Iterator concept, and there&#39;s the T=
hingThatThisToolTurnsIntoAnIt<wbr>erator concept. Those aren&#39;t the same=
 thing; indeed, more likely than not, they are quite dissimilar. They have =
different interfaces and different purposes.<br>&gt; <br>&gt; <br>&gt; User=
s don&#39;t have to remember the ThingThatThisToolTurnsIntoAnIt<wbr>erator =
concept, because they simply don&#39;t use it very often. When they need to=
 use it, they&#39;ll look up what it does and how it works. What they&#39;r=
e going to remember is Iterator, because that&#39;s what they&#39;re using =
most of the time.<p>Well the iterator comparison for the ratio of uses/impl=
ementations is not fair as this is not the case for every concept library o=
ut there.</p></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p>T=
here is a second problem with this separation into two concepts:<br>Conside=
r a customization point in the users&#39; concepts that is given via a trai=
ts class.<br>If that customization is not given by the ThingThatTurnsIntoMy=
Concept (then this concept also has a traits class) then users and implemen=
ters use different customization points which costs the library in a lot mo=
re metaprogramming pain just because it uses concepts.</p></blockquote><div=
><br></div><div>Let&#39;s be more specific about the problem, using iterato=
rs as kind of a model for the idea.</div><div><br></div><div>Iterators have=
 a lot of interfaces. This makes them easy to use, so those interfaces prov=
ide value. So that&#39;s your &quot;consumption concept&quot;, one that&#39=
;s optimized based on the usefulness to the code using such objects.<br></d=
iv><div><br></div><div>But implementing iterators, particularly from range-=
like starting points, is painful. It often requires a lot of repetition or =
writing a lot of boilerplate. You could imagine a far more simplified inter=
face. But you don&#39;t want users to <i>use</i> that interface, because th=
e interface is less usable than the Iterator interface. This is your &quot;=
implementation concept&quot;.<br></div><div><br></div><div>These two concep=
ts have <i>nothing</i> to do with one another. They are two different conce=
pts for two different users with two different use cases. The only associat=
ion between them is that there is some piece of metaprogramming code which =
takes objects which abide by the implementation concept and generates objec=
ts for the consumption concept.</div><div><br></div><div>But this is merely=
 a <i>helper tool</i> for the consumption concept. It is not a fundamental =
or essential part of that concept. After all, nobody is <i>forcing</i> you =
to use this particular tool. If you want to write your Iterator type withou=
t help, you certainly can do so. As long as you conform to the consumption =
concept, you&#39;re fine.</div><div><br></div><div>Not only that, you can h=
ave <i>multiple</i> such tools, each of which has their own concept model. =
You can write a tool that takes Java-style iterators and generates code for=
 STL-style iterators. Or vice-versa.</div><div><br></div><div>So I fail to =
see the problem here.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bb8f21fb-3f6c-4905-a8b9-688cb15f5e30%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bb8f21fb-3f6c-4905-a8b9-688cb15f5e30=
%40isocpp.org</a>.<br />

------=_Part_18563_1747966124.1528051621776--

------=_Part_18562_1769981434.1528051621775--

.

------=_Part_5562_1747134834.1528052146287
Content-Type: multipart/alternative;
 boundary="----=_Part_5563_2138219071.1528052146287"

------=_Part_5563_2138219071.1528052146287
Content-Type: text/plain; charset="UTF-8"

On Sunday, June 3, 2018 at 12:48:08 PM UTC-4, Omer Rosler wrote:
>
> On Sunday, June 3, 2018 at 4:21:19 AM UTC+3, Jake Arkinstall wrote:
> > On Sun, 3 Jun 2018, 00:57 Omer Rosler <omer....@gmail.com> wrote:
> >
> > This is a question/issue I have stumbled upon while trying out the
> concepts TS, I hope this is the right forum.
> >
> >
> >
> > This kind of thing is well suited here. Although this is generally for
> bringing an idea to a proposal worthy state, critiques of current proposals
> and problems with accepted proposals are common and welcome.
> >
> >
> > "Here is the problem: The concept users need to implement (if they use
> the adaptor) is not properly defined."
> >
> >
> > Can you elaborate on this problem you describe with a further code
> sample? Something a little more concrete to work with - I got a little lost
> trying to understand your conclusion.
>
> Think of a node library that abstracts away both memory access and
> connections between the nodes:
>
> `template<typename T> concept DAGNode = requires {
>     typename T::children_router_type;
>     T T::get_child(children_router_type child_connection);
> };
> `
> Now for a much more specific concepts - that of a binary tree node:
> `
> enum binary_node_connections
> {
>     left,
>     right
> };
> template<DAGNode T> concept BinaryTreeNode = requires
> {
>     requires std::is_same_v<typename T::children_router_type,
> binary_node_connections>;
>
>     T get_right();
>     T get_left();
> };
> `
>
> The interface that is exposed by the concept is supposed to be getting
> nodes by the specific functions - get_right and get_left
>

No, those are convenience functions. You should be able to pass a
`BinaryTreeNode` to any algorithm that can take a `DAGNode`. Isn't that
kind of the point of having `DAGNode`? Just like with `ForwardIterator` vs.
`RandomAccessIterator`?


> The default implementation of `get_child` using those methods can be given
> by a CRTP base, but then for node classes implementors this is a whole new
> concept to implement.
>

That's all up to you. There's no reason your CRTP base class cannot
determine whether the given node type is a `BinaryTreeNode` and
conditionally provide `get_left` and `get_right` members that call your
`get_child` function.

That's how most iterator/range facade types work. If your type implements
the random access functions, then the facade generates a random access
iterator. If your type doesn't have those APIs, then you don't get a random
access iterator.

And remember: your CRTP base class does not have to use `get_child` at all.
It can use an interface that it defines, which it refines to match the
concept it's trying to implement.


> This is the underlying problem, especially if every concept does that.
> For example we might add traversal requirement for any `DAGNode` or add a
> `BinarySearchTreeNode` for balanced trees that adds a search member
> function, etc etc.
> This doubles the number of concepts. And completely separates users from
> implementers.
>

Users and implementers *should* be separate. The interface that users use
does not need to care about the interface that implementers use. User
interfaces are defined by what makes things easiest for users; implementer
interfaces are defined by what makes things easiest for implementers.

These are rarely the same.

--
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/e34e594c-4ebe-4d93-b128-42fe31172195%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, June 3, 2018 at 12:48:08 PM UTC-4, Omer Rosler =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Sunday, June 3, 2018 =
at 4:21:19 AM UTC+3, Jake Arkinstall wrote:<br>&gt; On Sun, 3 Jun 2018, 00:=
57 Omer Rosler &lt;<a>omer....@gmail.com</a>&gt; wrote:<br>&gt; <br>&gt; Th=
is is a question/issue I have stumbled upon while trying out the concepts T=
S, I hope this is the right forum.<br>&gt; <br>&gt; <br>&gt; <br>&gt; This =
kind of thing is well suited here. Although this is generally for bringing =
an idea to a proposal worthy state, critiques of current proposals and prob=
lems with accepted proposals are common and welcome.<br>&gt; <br>&gt; <br>&=
gt; &quot;Here is the problem: The concept users need to implement (if they=
 use the adaptor) is not properly defined.&quot;<br>&gt; <br>&gt; <br>&gt; =
Can you elaborate on this problem you describe with a further code sample? =
Something a little more concrete to work with - I got a little lost trying =
to understand your conclusion.<p>Think of a node library that abstracts awa=
y both memory access and connections between the nodes:</p><p>`template&lt;=
typename T&gt; concept DAGNode =3D requires {<br>=C2=A0 =C2=A0 typename T::=
children_router_type;<br>=C2=A0 =C2=A0 T T::get_child(children_router_<wbr>=
type child_connection);<br>};<br>`<br>Now for a much more specific concepts=
 - that of a binary tree node:<br>`<br>enum binary_node_connections<br>{<br=
>=C2=A0 =C2=A0 left,<br>=C2=A0 =C2=A0 right<br>};<br>template&lt;DAGNode T&=
gt; concept BinaryTreeNode =3D requires<br>{<br>=C2=A0 =C2=A0 requires std:=
:is_same_v&lt;typename T::children_router_type, binary_node_connections&gt;=
;</p><p>=C2=A0 =C2=A0 T get_right();<br>=C2=A0 =C2=A0 T get_left();<br>};<b=
r>`</p><p>The interface that is exposed by the concept is supposed to be ge=
tting nodes by the specific functions - get_right and get_left<br></p></blo=
ckquote><div><br></div><div>No, those are convenience functions. You should=
 be able to pass a `BinaryTreeNode` to any algorithm that can take a `DAGNo=
de`. Isn&#39;t that kind of the point of having `DAGNode`? Just like with `=
ForwardIterator` vs. `RandomAccessIterator`?<br></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><p>The default implementation of `=
get_child` using those methods can be given by a CRTP base, but then for no=
de classes implementors this is a whole new concept to implement.<br></p></=
blockquote><div><br></div><div>That&#39;s all up to you. There&#39;s no rea=
son your CRTP base class cannot determine whether the given node type is a =
`BinaryTreeNode` and conditionally provide `get_left` and `get_right` membe=
rs that call your `get_child` function.</div><div><br></div><div>That&#39;s=
 how most iterator/range facade types work. If your type implements the ran=
dom access functions, then the facade generates a random access iterator. I=
f your type doesn&#39;t have those APIs, then you don&#39;t get a random ac=
cess iterator.</div><div><br></div><div>And remember: your CRTP base class =
does not have to use `get_child` at all. It can use an interface that it de=
fines, which it refines to match the concept it&#39;s trying to implement.<=
br></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;"><p>T=
his is the underlying problem, especially if every concept does that.<br>Fo=
r example we might add traversal requirement for any `DAGNode` or add a `Bi=
narySearchTreeNode` for balanced trees that adds a search member function, =
etc etc.<br>This doubles the number of concepts. And completely separates u=
sers from implementers.</p></blockquote><div><br></div><div>Users and imple=
menters <i>should</i> be separate. The interface that users use does not ne=
ed to care about the interface that implementers use. User interfaces are d=
efined by what makes things easiest for users; implementer interfaces are d=
efined by what makes things easiest for implementers.</div><div><br></div><=
div>These are rarely the same.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e34e594c-4ebe-4d93-b128-42fe31172195%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e34e594c-4ebe-4d93-b128-42fe31172195=
%40isocpp.org</a>.<br />

------=_Part_5563_2138219071.1528052146287--

------=_Part_5562_1747134834.1528052146287--

.