220 38462 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Concepts fragmentation problem Date: Sun, 3 Jun 2018 11:55:46 -0700 (PDT) Lines: 187 Approved: news@gmane.org Message-ID: References: <3eaf8f38-0284-424b-9dc8-10db869fdb69@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5562_1747134834.1528052146287" X-Trace: blaine.gmane.org 1528052021 22842 195.159.176.226 (3 Jun 2018 18:53:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Jun 2018 18:53:41 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBM7T2DMAKGQEDNXV6NY@isocpp.org Sun Jun 03 20:53:37 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fPY8G-0005qF-Mr for gclcip-std-proposals@m.gmane.org; Sun, 03 Jun 2018 20:53:36 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id l17-v6sf15905830ywh.19 for ; Sun, 03 Jun 2018 11:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=u9sB3SSfmjv03D8kDy3Bs2e4zlh4jMg5L1LOmTOfyLc=; b=zyppPP6RCEuuES2Li62ALzOTMp0P3kxkOD238v0KLDpZbVEOtXdFDgh1HZkJA88/Ls iHq0+5vbi97/LsXM/OgWbt9fVppyAlQwNQbWYjD91SXHMJNDo9PTKSVn8wlqTAPHY68d KsuSw/Rv3EAdNT5+2cQWLg7DD6VEVSsbA7UQ98+I5MKzeqeLWWwfTC2nxDlPCeRfHklu VwYXFf2GmkjluQF0j/nOAfo7l0iVb1rWW4Ytx3bjlhkgSknfV86VcdO4P29zWgWtKMPl C9Zhfh/jp1kYd6KLE1PshiuhnXt2IrBEoZvqzmy+SEi3KzXcbpMR4L1QEuMti07JbiqR bWjg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=u9sB3SSfmjv03D8kDy3Bs2e4zlh4jMg5L1LOmTOfyLc=; b=eynCXENBLE4nSM8DsUcVWWgu5K6KZg/f18X8hoJcEZqmT5lY69cnl3klV27Tb3ZagA ByZdSevxgimrg8P6I1RoZev1qUIbtKSJ/hxjhtijYDY6Yht0UI7JousKrqys/reaf0cI X+YafpN3HIu/NA3l7wNmgy8WmCWX4kjqvBuaZB4jv+tALAudk8L28Lo5zYo/d4sORX9b xhbwVbK9KlNeTrr4DBbSddSl/Hag5Jiqtm3tpHXEpCG2R+D6wq+liV8a01GbGvIBdYCX 4UJw9Z9VcOH9wF9Php+mfryRxGk47MFbjO2SDTT0dW5uctZhusUb7JKYZSvjx2rquze9 ztKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=u9sB3SSfmjv03D8kDy3Bs2e4zlh4jMg5L1LOmTOfyLc=; b=CUqgYG1NCbXVpWEGGiJMc/x/54rbE7hIKVzzMg2KEJ5qxKehkoA1H+pgEKfQNYMshx 5lVWQpluput/2q5F0su9G9yhs1k+TgPAwn8tnfTSPQnyXT7765vm36V+lyCBC3Cpqt+Q 2cfJQvDgAI/zB7EKJ89nBUh0YFtr/yDDTvzsYJZvRs5ysN5Psvs9T128kiaefxGW+X3r hVIzHUtGf1RCKYxf1k5asllU8/WQWvv7URi6RY2pgnzxdjx6h4FC1AvvfUAhb4hrr+iy AjDSwOIx9BLd843u+n/PiyYWaXc204RG1yXpSZAtLi7AQEV87TXlox5LvNQuC46Tcg1+ CHLg== X-Gm-Message-State: ALKqPwcJ/rW0yYy0R+WSW8T76ySaPeTKqIVzPTtbdjCJiiauh5UEonqE 8ffTevInwIlBvgi6PCqm6TWtPw== X-Google-Smtp-Source: ADUXVKJAtbVB6XdC7EFJEeh641segc9RjLUmxE1QNJ6eERGpW+AhNAG5bjBvcRLSc032giuhBp1vxg== X-Received: by 2002:a81:6a85:: with SMTP id f127-v6mr5549946ywc.132.1528052147652; Sun, 03 Jun 2018 11:55:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:28c3:: with SMTP id o186-v6ls195137ywo.22.gmail; Sun, 03 Jun 2018 11:55:46 -0700 (PDT) X-Received: by 2002:a81:9341:: with SMTP id k62-v6mr775526ywg.4.1528052146725; Sun, 03 Jun 2018 11:55:46 -0700 (PDT) In-Reply-To: <3eaf8f38-0284-424b-9dc8-10db869fdb69@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:38462 Archived-At: ------=_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 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 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 concept BinaryTreeNode = requires > { > requires std::is_same_v 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
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:
>
> Th= is is a question/issue I have stumbled upon while trying out the concepts T= S, 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 prob= lems with accepted proposals are common and welcome.
>
>
&= gt; "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 awa= y both memory access and connections between the nodes:

`template<= typename T> concept DAGNode =3D requires {
=C2=A0 =C2=A0 typename T::= children_router_type;
=C2=A0 =C2=A0 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
{=C2=A0 =C2=A0 left,
=C2=A0 =C2=A0 right
};
template<DAGNode T&= gt; concept BinaryTreeNode =3D requires
{
=C2=A0 =C2=A0 requires std:= :is_same_v<typename T::children_router_type, binary_node_connections>= ;

=C2=A0 =C2=A0 T get_right();
=C2=A0 =C2=A0 T get_left();
};`

The interface that is exposed by the concept is supposed to be ge= tting 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 `DAGNo= de`. Isn't that kind of the point of having `DAGNode`? Just like with `= ForwardIterator` vs. `RandomAccessIterator`?
=C2=A0

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.


That's all up to you. There'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.

That'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't have those APIs, then you don't get a random ac= cess iterator.

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's trying to implement.<= br>
=C2=A0

T= his is the underlying problem, especially if every concept does that.
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.
This doubles the number of concepts. And completely separates u= sers from implementers.


Users and imple= menters should 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>These are rarely the same.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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-- ------=_Part_5562_1747134834.1528052146287-- .