220 38453 article Path: news.gmane.org!.POSTED!not-for-mail From: Omer Rosler Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Concepts fragmentation problem Date: Sat, 2 Jun 2018 16:57:30 -0700 (PDT) Lines: 199 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_20725_1091982472.1527983850457" X-Trace: blaine.gmane.org 1527983727 13033 195.159.176.226 (2 Jun 2018 23:55:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Jun 2018 23:55:27 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC2L3NWCRYJBB265ZTMAKGQEYNCJXWY@isocpp.org Sun Jun 03 01:55:23 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f199.google.com ([209.85.213.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fPGMj-0003Fo-My for gclcip-std-proposals@m.gmane.org; Sun, 03 Jun 2018 01:55:22 +0200 Original-Received: by mail-yb0-f199.google.com with SMTP id n65-v6sf19210995ybn.10 for ; Sat, 02 Jun 2018 16:57:33 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=41jFBs3drlCGL7atzUWxxPsH6SSZW9v+ErQl3N0CxNE=; b=SGErUf3ZY83D9n/sQeqBqDYs+YXWIuEx3WQRhb+tJ5fh+u8O5awC/E6m3d7dL+VQFd kg78k4eT5pWWrCPDhMiA0Zdvyn4UU+35P7Yd2pK4QXEkTyhAhGE+FwX9ET+cJR+Lb0y2 NyqffISko1MIXb47/H9sFu85lb8/1novPJsSBua0P1YZ1p+jvl3sqoFpk2kI4qUmqPNZ StRax2QHbNB12yYAEXmDWzLbQNCIUHWRAKvPr0uHOwNC9VINyOdn+sQusZLTxuMfKoK4 LIBgVXHGHHk/Atihraso9Qck6kDtJF7JP3JmW4F+pl4x2rWN6EfKLLdAjovIRdMB/Ftj 8bzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=41jFBs3drlCGL7atzUWxxPsH6SSZW9v+ErQl3N0CxNE=; b=J03eJrdCIqPfTgYA3Nldc1RKC5gRD4YsmKy5CVS3dhXXsuVxgWXON1dxLkqzVQ6y7Q tHhqhU0wdBFXzvpgTCAYTJ/P7AwJSZ6v8Fx/iW1WdYIEfO8fJw62NW4MytcYiLCYqhn/ ph+4fbjbIn2wwTmw6DUv/QL6HESrcBjVlzfh7uVQKFsl+vEMoSxQQv+zwgdaCGYlKS6s yStxwCHU2/O20q9tRZzaM78PFpwIqFSzwznwFa1OJNCvVpBBZXZ5zqq5Yg3LS0L+hFim JKW5cLWSojMDtJmKGtP6P1dlJrYClfToWwUkHYpuBsrPejczkKyk/hts0U5a9yqKpiV9 utYg== 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: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=41jFBs3drlCGL7atzUWxxPsH6SSZW9v+ErQl3N0CxNE=; b=gJeanki/8OWtcYI5oJe3k96IaTNFKKuVYMfRopkBBEujCozC+VzLJlGWueNo9kiaEm /Bdi2P91z/D057fj7oIeVCFWa5/7MILInaaXr6KJKTwrkoncLgmOj10vhJvh5eW5KfUb VkqRm29gxxmSDvihwCsiwqjWAp6Rjp+tfJ8Uor1Z/LZkcgHJ6Xss/wMX+4+sleDMz6a5 bn/T29YKn2u4aIWVE5Nzs5NmwLfRmXRtY2ZFC4eenraLa5opjri7wL5/si20L081yQXa HXTdJJTico/B5mN9Sdnr9tBeBojwCCkP6QKc4ZHg6VPPZlAXnwN7AxRbWXdF34jPlZnh 1ZXQ== X-Gm-Message-State: APt69E2uUa2k5oBAfa0x9EZKaJcH68c2YYOIdZ69dJM6AJ8sLzV9/YXd eua36XUTJeJQ0lvt3todEuSkVA== X-Google-Smtp-Source: ADUXVKKHrxbzR8oZCwl8Gd3TajRPf7nHi0GZeFUOxfU9sXIIh/mtGbWbWFKStNNuDeYXAMh5WB1+rw== X-Received: by 2002:a81:4f51:: with SMTP id d78-v6mr837861ywb.179.1527983852648; Sat, 02 Jun 2018 16:57:32 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:b78d:: with SMTP id n13-v6ls9297280ybh.5.gmail; Sat, 02 Jun 2018 16:57:31 -0700 (PDT) X-Received: by 2002:a25:824a:: with SMTP id d10-v6mr673831ybn.8.1527983851379; Sat, 02 Jun 2018 16:57:31 -0700 (PDT) X-Original-Sender: omer.rosler@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:38453 Archived-At: ------=_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 concept VeryGeneral = requires { void T::general_fn(); }; template concept Specifc = requires { void T::specific_fn(); }; Now the `general_fn` in `Specific` implementations can logically be implemented using `specific_fn`, for example: template requries Specific 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 ). 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
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 sit= uation:

template<typename T> concept VeryGeneral =3D<= /span> requires{=
=C2=A0 =C2=A0= void T::general_fn();
};


template<VeryGeneral T> conc= ept Specifc =3D requires
{
=C2=A0 =C2=A0 void T::specific_fn();
};

Now the `general_fn` in `Spe= cific` implementations can logically be implemented using `specific_fn`, fo= r example:
template<typename T> requries Specific<T>
void general_fn_impl_for_any_= specific(<= /span>T t<= span style=3D"color: #660;" class=3D"styled-by-prettify">) {
=C2=A0 =C2=A0 if (bla)
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 t.specific_fn();
}<= /span>

I don'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:

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).

Here is the problem: = The concept users need to implement (if they use the adaptor) is not proper= ly defined.
There are two options to expose as the library author= :
  1. The subset of `Specific` that is not provided by the ad= aptor type.
  2. Create a concept for exactly this subset.
The problem with the first approach is that users implementing the concept= s can'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= ).

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.
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's=C2=A0How to design good concepts and use them well).

<= 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?

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