220 40714 article Path: news.gmane.org!.POSTED!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Why don't concepts look like and get called like functions? Date: Wed, 24 Oct 2018 18:09:52 -0700 (PDT) Lines: 245 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_156_547975175.1540429792304" X-Trace: blaine.gmane.org 1540429670 5017 195.159.176.226 (25 Oct 2018 01:07:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 25 Oct 2018 01:07:50 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBYNPYTPAKGQEORJKMZI@isocpp.org Thu Oct 25 03:07:46 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f69.google.com ([209.85.161.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gFU7k-0001A4-9m for gclcip-std-proposals@m.gmane.org; Thu, 25 Oct 2018 03:07:44 +0200 Original-Received: by mail-yw1-f69.google.com with SMTP id l126-v6sf4541239ywb.17 for ; Wed, 24 Oct 2018 18:09:55 -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=8Fie0QzV8WN9xFBx1+bjIlPKIgcuX9mzp/IvT8MM9vE=; b=h1z4gEvisigfT18ZEtf+mfrue6+rZ2cyVEMWlCpXP6GUkI7r1FPvX094J9ZlHt/i7N 3ukSxd1PkCp9ptJ4u2+zsBExH/Gin6mcjqr+cL17BTpzPbvtCmVKgFNyfqYaFIsdkbZX Ue3e98MT4DZsdk+Vd5MPNznS4T5B0kicqyWrVINkqwQm7hCvGxnBPE+PI927QpUIpngO g1EJowaQu3uoA3wy+6cjkyBi3MfY7iKG8iJm0zXPTTXMca5gF6o8LcfUC5mhr1muEOuS ilMn8VWp5+jg49zVSmY9riiHH2qeeQ0BMf2fzkKA+C6asFp1ZSgcFyKn0w2rY/l9CP1/ pFyg== 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=8Fie0QzV8WN9xFBx1+bjIlPKIgcuX9mzp/IvT8MM9vE=; b=L1jdaF0q/zWP6q8ao/BRIRvP36gW7Mccj0qWHyc7Z3AUBxoZNUpcMmvv7sR9qfPUvx UgHYsoGvKxQPffs+v+BgHFofcpUotpspkMp7U9isldZgPG8cyqe972jI4n4yQfNJk6f1 mpEVAp+9dHSWkNsbdXaiGQRi8vujt+KRODmmTjF0C/0Hqiq44xP3ACWDJGPHEnVdRcAK KaBb1gX35rk5D2SsC4VQcZ9VghM2Cx733Gk3LIF7PJa96Mcg4NcIYKkbzEG9opVxj30F DHNwxAMl0uV3A1vHrWR+rYgi+XrhSXp9Rhf2N3CuzncTnpoGzeQ7REUJSSSmMSSPz4fO Ipuw== 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=8Fie0QzV8WN9xFBx1+bjIlPKIgcuX9mzp/IvT8MM9vE=; b=ik6aLbWHHk8KNwyW4hx6f5QAMfoKhErve1s4zE45MXMXnl77UKLu2ewdqu8RdCwJfz FWB45dXOLBzLAt0cBCxzNsC4Bpdzr/YcKyAdd3076/kTKZLR30GwwTnLC/qrVMTs5q4N WDqhwB8s19W3LHWuEEAViyps5ACgv1COxD1W4V+tUiuyEVRoNGTe7vKLLUb/AxQSHa02 U0MgzX4NSvvP5CAnR2V0rDdTFNMe6d1fBSykc8epf0SkVLwwALPczlOvcMVvTM5RVbvl GODO0z/mkRdEV/b0eo77FVrz1CfkkRkII+mV9bf45aNx3mu6xoUeISlRJlYpwkKvyFVT oCkg== X-Gm-Message-State: AGRZ1gKjqBCQR8PY4SHQZSh/msjy/C9IojI+UWu2rsm/cxSqzKERXLry 20Sf5M02sIrwgRfAbDdJHyX0ig== X-Google-Smtp-Source: AJdET5ftDT3OxFZTetGZlEdAKbUG5Y64G8c2UXXLr+M11ZTXvqCOJGQQgqghTlFJqbvxHf2m5hfaGQ== X-Received: by 2002:a5b:490:: with SMTP id n16-v6mr2894362ybp.15.1540429794561; Wed, 24 Oct 2018 18:09:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:9b82:: with SMTP id v2-v6ls3425451ybo.6.gmail; Wed, 24 Oct 2018 18:09:53 -0700 (PDT) X-Received: by 2002:a25:50cd:: with SMTP id e196-v6mr56643ybb.0.1540429793030; Wed, 24 Oct 2018 18:09:53 -0700 (PDT) X-Original-Sender: gmisocpp@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:40714 Archived-At: ------=_Part_156_547975175.1540429792304 Content-Type: multipart/alternative; boundary="----=_Part_157_741733329.1540429792305" ------=_Part_157_741733329.1540429792305 Content-Type: text/plain; charset="UTF-8" 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? Bjarne's CppCon 2018 talk "Concepts: The Future of Generic Programming" answers that question clearly. In his talk, Bjarne says: * Concepts are NOT types of types. They are NOT type classes. * Concepts can take more than one argument. * Concept is a specification of what one or more types can do. At around 1:06:30 in his talk Bjarne says: * "it's just like defining functions, you *ARE* DEFINING FUNCTIONS". So I want to ask: ----- If concepts ARE functions why don't they look like functions? Perhaps they should? ----- 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: template using Value_type = X::value_type; template using Iterator_of = X::iterator; template concept Mergable = ForwardIterator && ForwardIterator && OutputIterator && Assignable,Value_type> && Assignable,Value_type> && Comparable,Value_type>; 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? I find this function as a variable thing confusing to coming to terms with what Concepts actually are. If Concepts ARE functions as Bjarne says, why shouldn't they look and be composed using functional notation? It seems I'm not alone in this feeling. J. Monnon proposes this: Type functions and beyond An exploration of type functions and concept functions http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0844r0.html He says: "This document proposes to extend functions to let them operate directly on types and concepts. The goal is to allow writing metaprogramming in the most intuitive and consistent way with the rest of the language." J. Monnon says: Here is an example of a type function: ForwardIterator IteratorType(typename T) { // In a type function, an `if` behaves as a `if constexpr`. if (Container(T)) // `Container` is a concept return T::iterator; else if (Array(T)) // `Array` is a concept return Decay(T); } // On call site: typename I = IteratorType(C); J. Monnon says: "A type function is always executed at compile-time. Here, it takes a type T and returns another type that models the ForwardIterator concept. Type functions allow a natural and straightforward notation to manipulate types." This also justifies his comment which I emphasise: // In a type function, an `if` behaves as a `if constexpr`. At this time, I agree with J. Monnon's proposal. I find it intuitive and insightful if I understand it correctly. If J. Monnon's paper has been discussed at any length anywhere, can someone please tell me the outcome? His proposal appeared on Reddit at one point but attracted a near zero response there, which stunned me. I'd certainly like to see more commentary on that proposal here before the next Standards meeting that is imminent. I may be wrong, but doesn't the D language go this route also? What is so wrong with that approach that C++ goes it's own way? There is more I would like to say about Concepts such as why I hate the syntax as currently proposed. But for now, I'd really like to focus this discussion on the main elements I've raised. 1. If concepts ARE functions, why aren't we defining and using them with function like syntax? And using () not <>. 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? 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 concepts 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. This is even before any of my comments or J. Monnon's paper is taken into account. Right now, I feel that if Modules and Coroutines were the only main features that hit for C++20, I'd be happy with that. If people can explain why my comments are on the mark or misplaced and what the issues are with J. Monnon's proposal, I'd be grateful. Thanks -- 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/ae920b87-e062-4b2c-b74c-ae3067d3c604%40isocpp.org. ------=_Part_157_741733329.1540429792305 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 somethin= g else?

Bjarne's CppCon 2018 talk "Concepts= : The Future of Generic Programming" answers that question clearly.In his talk, Bjarne says:
* Concepts are NOT types of types. They are N= OT type classes.
* Concepts can take more than one argument.
* Concep= t is a specification of what one or more types can do.

At around 1:06= :30 in his talk Bjarne says:
* "it's just like defining functio= ns, you *ARE* DEFINING FUNCTIONS".


So I want to= ask:

-----
If concepts ARE functions why don't they look li= ke functions?
Perhaps they should?
-----


The C= oncepts defined in Bjarne's talk look more like variable definitions *d= efined* in what feels (to me) like an odd mix of logic and type like syntax= :

template<typename X> using Value_type =3D X::value_type;template<typename X> using Iterator_of =3D X::iterator;

templa= te<typename For, typename For2, typename Out>
concept Mergable =3D=
=C2=A0=C2=A0=C2=A0 ForwardIterator<For>
=C2=A0=C2=A0=C2=A0 &am= p;& ForwardIterator<For2>
=C2=A0=C2=A0=C2=A0 && Output= Iterator<Out>
=C2=A0=C2=A0=C2=A0 && Assignable<Value_ty= pe<For>,Value_type<Out>>
=C2=A0=C2=A0=C2=A0 && As= signable<Value_type<For2>,Value_type<Out>>
=C2=A0=C2= =A0=C2=A0 && 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 defi= nition, 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?

I find = this function as a variable thing confusing to coming to terms with what Co= ncepts actually are.

If Concepts ARE functions as Bjarne says= , why shouldn't they look and be composed using functional notation?

It seems I'm not alone in this feeling. J. Monno= n proposes this:
Type functions and beyond
An exploration of type fun= ctions and concept functions
http://www.open-std.org/jtc1/sc22/wg2= 1/docs/papers/2018/p0844r0.html

He says: "This document pr= oposes to extend functions to let them operate directly on types and concep= ts.
The goal is to allow writing metaprogramming in the most intuitive a= nd consistent way with the rest of the language."

J. Monnon says= :

Here is an example of a type function:
=C2=A0=C2=A0=C2=A0 Forwar= dIterator IteratorType(typename T) {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 // In a type function, an `if` behaves as a `if constexpr`.
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (Container(T))=C2=A0 // `Cont= ainer` is a concept
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 return T::iterator;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 else if (Array(T)) // `Array` is a concept
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return Decay(T);
=C2=A0=C2= =A0=C2=A0 }

=C2=A0=C2=A0=C2=A0 // On call site:
=C2=A0=C2=A0=C2=A0= typename I =3D IteratorType(C);


J. Monnon says:
= "A type function is always executed at compile-time. Here, it takes a = type T and returns another type that models the ForwardIterator concept. Ty= pe functions allow a natural and straightforward notation to manipulate typ= es."

This also justifies his comment which I = emphasise: // In a type function, an `if` behaves as a `if constexpr`.

At this time, I=C2=A0agree with J. Monnon's propos= al. I find it intuitive and insightful if I understand it correctly.
If = J. Monnon's paper has been discussed at any length anywhere, can someon= e please tell me the outcome?
His proposal=C2=A0appeared on Reddi= t at one point but attracted a near zero response there, which stunned me.<= br>I'd certainly like to see more commentary on that proposal here befo= re the next Standards meeting that is imminent.

I = may be wrong, but doesn't the D language go this route also? What is so= wrong with that approach=C2=A0that C++ goes it's own way?
There is more I would like to say about Concepts such as why I= hate the syntax as currently proposed.
But for now, I'd really like= to focus this discussion on the main elements I've raised.
1. If co= ncepts ARE functions, why aren't we defining and using them with functi= on like syntax? And using () not <>.
2. It seems J. Monnon's p= roposal is making the same point as I am, only much better? Can we please a= ddress all that he proposes?
3. I feel a more formal response to J. Monn= on's paper from the main proponents of Concepts as currently defined sh= ould be made before concepts get wired in any further in it's current d= irection?

I know many people would like Concepts b= e the marquee feature of C++20, but to me Concepts=C2=A0still seem quite aw= ay from where I'd like them to be.
Even Bjarne can only 'begrudg= ingly live' with the current syntax.
All this flux and begrudging re= ally doesn't suggest to me that Concepts are ready to go for C++20.
= This is even before any of my comments or J. Monnon's paper is taken in= to account.

Right now, I feel that if Modules and = Coroutines were the only main features that hit for C++20, I'd be happy= with that.
If people can=C2=A0explain why my comments are on the mark o= r misplaced=C2=A0and what the issues are with=C2=A0J. Monnon's proposal= ,=C2=A0I'd be grateful.

Thanks

<= /div>

--
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/ae920b87-e062-4b2c-b74c-ae3067d3c604= %40isocpp.org.
------=_Part_157_741733329.1540429792305-- ------=_Part_156_547975175.1540429792304-- .