220 28288 <1fe5b03d-5251-4d0b-b6f8-b7ffdd88e3f3@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: what makes a Concept a Concept? Date: Sun, 18 Sep 2016 17:01:43 -0700 (PDT) Lines: 154 Approved: news@gmane.org Message-ID: <1fe5b03d-5251-4d0b-b6f8-b7ffdd88e3f3@isocpp.org> References: <1fc1c369-a709-41b0-bcd6-5fc01e814a5a@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_337_563691606.1474243303860" X-Trace: blaine.gmane.org 1474243315 22423 195.159.176.226 (19 Sep 2016 00:01:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Sep 2016 00:01:55 +0000 (UTC) Cc: najjarchedy@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB2OV7S7AKGQETBFDSNQ@isocpp.org Mon Sep 19 02:01:48 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1blm1p-0004df-9N for gclcip-std-proposals@m.gmane.org; Mon, 19 Sep 2016 02:01:45 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id t204sf252405431ywt.2 for ; Sun, 18 Sep 2016 17:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=0ncAYEjDQdw7aQQywNsXhUnp8Cn0UPbYI2xpPJJTtuk=; b=oyK46/09biDVxNlPMTXmlM5ZS+l0zZtVA27LRlvj1iUq3aSsu4T4BDX74YRnlHDNPE VDZ+/sthOLMvPzYd806cC9RRBNCy/E6+3fP7it3E4k1/0HnIXtmlWKwe9eiecTDs7COF x55PburSqH743tZuPg0DFTBmI/7IG6YxHssccwv1iQs/FBMo9scPIgPYM4Fso//3BqXI 3veJcDGY25RV66GahrQ6BpOWlj5qFybC+9d0dBH/KBw9IL+kfC2QbGT4yyjDGOjiY841 qqeyNqeanbn4rrNDHfedVitTDS5VMTNWlMy43w2E4EPvYa00HA5z+FVtplXeinHo7mG1 EsXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=0ncAYEjDQdw7aQQywNsXhUnp8Cn0UPbYI2xpPJJTtuk=; b=kDnVM1p0Divnv2vUWgfK2ER5Gb2NJ7EDLKEwzae59b+biCwCAM98CBcgrM81mK9p3o 0dxB5VMT2NT32agwgOOa1dzDC3I674xM8YeMC8uE6C2UdwFFjHG8U7Pvxw2roAYb402A triczblTnANv6q7RSHX543GVsRyIJnbDw6rR7JWnhL60NfAdDJV9QTLyXyx7LpIimbyl vdCHx+dtEqOfoT8JkUDgfBrhqFaz0Uz/XAQPX3j/6t0kZ8zPsthBXIgF8+uHSM03Y0J5 7A6nH9KGJw3CzShVPS7oZ0pT3KXzkdNaQcVv0Jzx+CvJcZ8+kDvD6TZAhZ+DcyOOriiU rIew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc: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=0ncAYEjDQdw7aQQywNsXhUnp8Cn0UPbYI2xpPJJTtuk=; b=KDS3rW5/guMum9MJLQM7qQ4dM/ciGfbAQZrdMkgYlfSZT9epoXc0mknnW0zunJmhen 8uY6CvuDiCkEkGZcsp0II0AeWfkPOlGWm8hStO8IKLLxuE1RVYBBUQExuhTB7UoXFWid 5zobOBVTgTGTMfk/Sh8+IPfApv7XGPnvkq7qURIp3WAfAE19s4y+6WirrXPYi1qjPpNr +DrJzRwi2zXz0T4DgVF8oYpjot1koNMz7/XFuUi/JsOZxgEEX5x/nmECRcwoQaqu+PXj 7IMH+yyu4tL1c5IjvMPb8pEbf7QeNZnSEtzgAV/b0vse3L3dkl3hB/0ENT4S7i+EAmDF WHBA== X-Gm-Message-State: AE9vXwPD+CVAG3GmwOJIIgpsba7eW9z06AnYk3IYZrWTVnuCLpRYJiCjkAjtgHziqEBWLg== X-Received: by 10.200.48.167 with SMTP id v36mr3247511qta.65.1474243306618; Sun, 18 Sep 2016 17:01:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.54.199 with SMTP id l190ls2361889itl.2.gmail; Sun, 18 Sep 2016 17:01:45 -0700 (PDT) X-Received: by 10.36.238.143 with SMTP id b137mr204058iti.7.1474243304970; Sun, 18 Sep 2016 17:01:44 -0700 (PDT) In-Reply-To: <1fc1c369-a709-41b0-bcd6-5fc01e814a5a@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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:28288 Archived-At: ------=_Part_337_563691606.1474243303860 Content-Type: multipart/alternative; boundary="----=_Part_338_1323418928.1474243303860" ------=_Part_338_1323418928.1474243303860 Content-Type: text/plain; charset=UTF-8 On Sunday, September 18, 2016 at 6:05:39 PM UTC-4, najja...@gmail.com wrote: > > > i started writing an article/documentation about Concepts by at a point in > time when i started giving examples and saying if this is a Concept or a > simple Constraint, i found my self enable to answer the question why this > is a concept ? > according to CPPCoreGuideline example :Addable is not a Concept because it > violates the Commutativity property of Addition.that's okay, but what makes > EquallyComparable or Regular a Concept? > > Addable is defined like so: > > template concept bool Addable = has_plus; > > This isn't really an appropriate question for this forum, as it's not discussing a proposed change to the language so much as an interpretation of the ideas behind one. That being said, what has primacy in a formal discussion is the formal standard. In this case, the Concepts TS standard. In that standard, it defines "concept" as a constexpr variable/function that evaluates to a `bool` based on its template parameters. The Core Guideline in question is not saying that `Addable` is not a "concept". It's saying that it's not a *good concept*. (or, as they put it, a "true concept", just like "no true Scottsman "...) That the way it constraints its parameter is not in accord with what the user will think `Addable` actually means based on its name. Much like you might say that a particular base class isn't a good representation of a polymorphic interface; it's still a base class, just not a very good one even if it works. The guideline is talking about concepts that represent something more than just "this set of operations won't provoke a compile error". It should actually state something about the type(s) in question. `Addable` doesn't really say anything more than "this operation will work". As an example, consider the Range TS's `Regular` concept. It specifies that a `Regular type` is copy/moveable, default-constructible, copy/move assignable, swappable, destructible, and can be equality compared. These are all different constraints. But when you put them together, what do you have? `Regular` defines a type that has a *value* (for the most part). *That* is what the Core Guidelines is talking about when it says "true concept". Not merely an arbitrary ball of constraints that fit whatever function implementation you're writing at the time. It's talking about something with a real meaning, such that the series of constraints are simply testing adherence to that meaning. That's the difference between `Addable` and `Number`: the former just tests if there's an `operator+`; the latter actually *says something* about the type. A good concept is supposed to be more than the sum of its parts. -- 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/1fe5b03d-5251-4d0b-b6f8-b7ffdd88e3f3%40isocpp.org. ------=_Part_338_1323418928.1474243303860 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sunday, September 18, 2016 at 6:05:39 PM UTC-4, najja..= ..@gmail.com wrote:

i started writing an article/documentation about Concepts by at a = point in time when i started giving examples and saying if this is a=C2=A0 = Concept or a simple Constraint, i found my self enable to answer the questi= on why this is a concept ?
according to CPPCoreGuideline example :Addabl= e is not a Concept because it violates the Commutativity property of Additi= on.that's okay, but what makes EquallyComparable or Regular a Concept?<= br>
Addable is defined like so:

template<typename T> concept bool Addable =3D has_plus<T>;
<=
/div>

This isn't really an = appropriate question for this forum, as it's not discussing a proposed = change to the language so much as an interpretation of the ideas behind one= ..

That being said, what has primacy in a formal discussion is the fo= rmal standard. In this case, the Concepts TS standard. In that standard, it= defines "concept" as a constexpr variable/function that evaluate= s to a `bool` based on its template parameters.

The Core Guideline i= n question is not saying that `Addable` is not a "concept". It= 9;s saying that it's not a good concept. (or, as they put it, a = "true concept", just like "no true Scottsman"...) That the way it = constraints its parameter is not in accord with what the user will think `A= ddable` actually means based on its name. Much like you might say that a pa= rticular base class isn't a good=20 representation of a polymorphic interface; it's still a base class, jus= t not a very good one even if it works.

The guideline is talking abou= t concepts that represent something more than just "this set of operat= ions won't provoke a compile error". It should actually state some= thing about the type(s) in question. `Addable` doesn't really say anyth= ing more than "this operation will work".

As an example, c= onsider the Range TS's `Regular` concept. It specifies that a `Regular = type` is copy/moveable, default-constructible, copy/move assignable, swappa= ble, destructible, and can be equality compared. These are all different co= nstraints. But when you put them together, what do you have?

`Regula= r` defines a type that has a value (for the most part).

Th= at is what the Core Guidelines is talking about when it says "true= concept". Not merely an arbitrary ball of constraints that fit whatev= er function implementation you're writing at the time. It's talking= about something with a real meaning, such that the series of constraints a= re simply testing adherence to that meaning.

That's the differen= ce between `Addable` and `Number`: the former just tests if there's an = `operator+`; the latter actually says something about the type.
<= br>A good concept is supposed to be more than the sum of its parts.

--
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/1fe5b03d-5251-4d0b-b6f8-b7ffdd88e3f3= %40isocpp.org.
------=_Part_338_1323418928.1474243303860-- ------=_Part_337_563691606.1474243303860-- .