220 32360 <9a9e46d5-ed24-40d8-8451-8b32ec0146d5@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Jakob Riedle Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: =?UTF-8?B?UmU6IFtzdGQtcHJvcG9zYWxzXSBSZTogQWRkaW5nIHRoZSBLZXl3b3JkIOKAnGludGVyZg==?= =?UTF-8?B?YWNl4oCdIGluIEMrKw==?= Date: Tue, 9 May 2017 09:19:48 -0700 (PDT) Lines: 316 Approved: news@gmane.org Message-ID: <9a9e46d5-ed24-40d8-8451-8b32ec0146d5@isocpp.org> References: <9ee212eb-4037-40c4-94c3-57a9a170a4c3@isocpp.org> <1765502.4y06pMOS3s@tjmaciei-mobl1> <45a81e95-d352-49ab-9c6e-7375aa41413c@isocpp.org> <09ec869a-2c1d-4fe8-8295-253e5001edd4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1274_354219459.1494346788659" X-Trace: blaine.gmane.org 1494346794 813 195.159.176.226 (9 May 2017 16:19:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 9 May 2017 16:19:54 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCX2XNFO6MPRBJOYY7EAKGQERL7ZBFY@isocpp.org Tue May 09 18:19:45 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f71.google.com ([74.125.83.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d87rV-0008Q3-7G for gclcip-std-proposals@m.gmane.org; Tue, 09 May 2017 18:19:45 +0200 Original-Received: by mail-pg0-f71.google.com with SMTP id d127sf3323475pga.11 for ; Tue, 09 May 2017 09:19:50 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=6FDwwnztcW967fK5E953xxKUdn7N5YwtWm3s49gKNZ0=; b=jaD1YdFUP0/hJUq/gMdCviBrjcTuknYPl1iL4Lz5zH5GDbGIQghhiudUtBxLQly4cN SQ/BqYoAOf9w2Et1Rw31eafh/KxvDoGiESryeF9T386bq52mLFrYCuhhsTPcBD1HUW49 qlN80BYDVmDDvvIsLif6CPmMrzX8NlAoAvJ7q8SmCm++RzV1sN4pmRCuvSPvC2HTX3vt 7qsuA9RTzr4Moho6q+BqCEtvLFol/doCZUf0FAX556dG9cy6Mh89yh4nzRJKrtF2/+vS LXDNanGsAVik5Gd3CHHuOAP0gCYY9+dmNKawOuI4gqJUxdgRyQRJPwvfIsZ3vssUTswL gDww== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=6FDwwnztcW967fK5E953xxKUdn7N5YwtWm3s49gKNZ0=; b=O1QnJPklnqMSxa21seaC54gz82PZOqUdf9ZsjVmG2kGSmbywF0urd+J/hBow9HHY4W ToRzadzwxberdS5BsgxwvqBtqO8tNNDYH6DWiJC2Q16JREsjUcoS+JoTzvSTjHek54GN XZCPLBv0BSDeO8rCXMIozcTOyA/bqu0E/Ao0X0FBE3P+D2U/IJS2+K7VrUZfiF4lCWLE RJdGfkqQK0QX9/q3bH1lpjBNmI/L+Rfub6wIG2LK2fF8uA2FdhE7HjliyPGHndW7YHri sMcTxq+Oa6BWTz9/nzUBBtSr1nmWX+T/om0NnoUI1dBo71omc2lmx8emmGt3Ejlo4rQq mSSQ== 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=6FDwwnztcW967fK5E953xxKUdn7N5YwtWm3s49gKNZ0=; b=hgYhQrYNz06L5tyOe38ucvLBWpYb0bF7JF2DICrnJuRZDpZOXXS+D65vvTFPbMaYpe 4vTiMxj2M76xIJ3c8mctY1g8plT9WoMVENTq5f3s+IG5t2Gb2Io1lzsmzRzj/P12YdHf qS34NLX5/tWZ6DG1q5X0A979pskPHVhSYDdb+JYC/KsfooQP5ejokQ0ktKj/N0TdKq0p aCF56dgqqYI8PC9PrLwlIJ9Khd6xLv4/MOxXP0Bm7e1K5xK+CaqRMoPLevywiddMfQtF C9U+UA+2zppHNVQJfJS/H+NfsOYPA4HKIHYLnRsjYoRD2Zktao+F4PNIWs5HvUC2Y9TS 4McQ== X-Gm-Message-State: AODbwcDw9QEUYaQyhnYhoj8arA9AHpEScVvt7sIqFKQCzI9Ar8Zn+EYn rVVHbut+kUWRXg== X-Received: by 10.99.42.199 with SMTP id q190mr154573pgq.102.1494346790271; Tue, 09 May 2017 09:19:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.73.129 with SMTP id g1ls610623otf.32.gmail; Tue, 09 May 2017 09:19:49 -0700 (PDT) X-Received: by 10.157.60.148 with SMTP id z20mr16155otc.3.1494346789146; Tue, 09 May 2017 09:19:49 -0700 (PDT) In-Reply-To: <09ec869a-2c1d-4fe8-8295-253e5001edd4@isocpp.org> X-Original-Sender: jakob.riedle@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:32360 Archived-At: ------=_Part_1274_354219459.1494346788659 Content-Type: multipart/alternative; boundary="----=_Part_1275_311731125.1494346788659" ------=_Part_1275_311731125.1494346788659 Content-Type: text/plain; charset="UTF-8" Am Dienstag, 9. Mai 2017 16:39:08 UTC+2 schrieb Nicol Bolas: > > That would have to be a `vector`. Which would be different > from `vector`. > Yeah, I was aiming for std::vector, sorry for the ambiguity. *[Note: Having a reference here introduces some new difficulties with lifetime,* *but I think my point is independent of that: Generic Functions/* *Translation Units are usually independent of the concrete Type]* > No, my argument is that `Callable` is a *concept*. Concepts *are > not types*; in the current TS, they are either functions or variables, > neither of which is a *type*. > [...] > That's my point. You can't have `Callable<>` be both a static and dynamic > concept. That's why its best to make "dynamic concepts" specifically be > types. > You are right on that. However, I defined the use of Callable<> in different contexts quite clearly (did I not?): void func(){ > // ... > } > int main(){ > // Here the concept 'Callable<>' is used at a non-deduced context (where > no deduction happens) > // Therefore, the Callable<> will automatically be interpreted as an *abstract > class* (Dynamic Concept) to which other types can be type erased to. > std::vector myVec; > myVec.emplace( &func ); > } > class MyClass{ > std::vector myVec; // same applies here since we are in an > undeduced context > void set_vector( std::vector newVec ){ // This is still a > function template where Callable might be deduced as std::function > std::move(newVec.begin(),newVec.end(),std::back_inserter(myVec)); // > Here an implicit conversion happens from the potentially specialized > std::function to type erased Callables } > } [...] `Callable<>` is a static concept, so if you want to make a dynamic concept > based on it, you must use some other syntax besides `Callable<>`. > Is this question now solved? I should explicate here, that I personally strive for exactly this ambiguity to allow going hand in hand with "normal" concepts. Actually, I see your point of ambiguity very clearly. But maybe you have this perspective, because the different applications of a concepts name are not going hand in hand (yet). Is that true? In the following I will argue, why we should strive to reconcile Dynamic and "Static" Concepts to go hand in hand with each other, much like compile time and runtime constexpr function execution does. *Plea to complete the symmetry to constexpr functions:* Constexpr functions operate on Values. Values have to have a data type, that means in an abstract way, *data types are concepts (subsets of) the infinite set of potential values*. Concepts (from Concepts Lite) also represent subsets, but not upon values but upon the infinite set of potential types. *Trying to interwine both principles:* - If you pass constant (known at compilation) values into a constexpr function, you immediately can work with it and determine everything you want at compile time. - If you pass constant (known at compilation) types into a templated function/class, you immediately can work with it and determine everything you want at compile time. - If you pass a dynamic (only known at runtime) values into a constexpr function, you need to defer all work to the run time. - If you pass a dynamic (only known at compilation due to polymorphism) types into a templated function/class, you need to defer all work to runtime. Data types (as mentioned above), guarantee certain subset of possible values a variable of that type can have. Concepts guaratee a certain subsets of types. In order to be able to defer an operations on concrete types (restricted by a concept) to run time, dynamic concepts have to make the symmetry complete. Yours cincerely, Jakob -- 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/9a9e46d5-ed24-40d8-8451-8b32ec0146d5%40isocpp.org. ------=_Part_1275_311731125.1494346788659 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Am Dienstag, 9. Mai 2017 16:39:08 UTC+2 schrieb Nicol Bola= s:
That w= ould have to be a `vector<BaseClass*>`. Which would be different from= `vector<BaseClass>`.

Yeah, I was aiming for std::vector<BaseClass&>, sorry for the am= biguity.

[Note: Having a reference here introdu= ces some new difficulties with lifetime,
but I think my po= int is independent of that: Generic Functions/
Translation= Units are usually independent of the concrete Type]
=C2=A0
No, my argument is that `Callable<void()>` is a conc= ept. Concepts are not types; in the current TS, they are either = functions or variables, neither of which is a type.
<= div>[...]
That's my point. You can't have `Callable<&g= t;` be both a static and dynamic concept. That's why its best to make &= quot;dynamic concepts" specifically be types.
=

You are right on that. However, I defined the use of Ca= llable<> in different contexts quite clearly (did I not?):
=
void=C2=A0func(){
=C2=A0= // ...
}
int= =C2=A0main(){// Here the concept 'Callable<>= ' is used at a non-deduced context (where no deduction happens)
// Therefore, the Callable<> will automa= tically be interpreted as an abstract class=C2=A0(Dynamic Concept) t= o which other types can be type erased to.
::ve= ctor<Callable>=C2=A0myVec;
myVec.emplace(=C2=A0&func=C2=A0);
}
class=C2=A0MyClass{
<= span style=3D"font-family: monospace; background-color: rgb(250, 250, 250);= color: rgb(0, 0, 0);">=C2=A0std::vector<Callable&g= t;=C2=A0myVec;=C2=A0= // same applies here since we are in an undeduced context
=C2=A0void=C2=A0set_vector(=C2=A0std::vector<Callable>=C2=A0newV= ec=C2=A0){=C2=A0// This is still a function templat= e where Callable might be deduced as std::function<void()>
= =C2=A0 std::move(newVec.begin(),newVec= ..end(),std::back_inserter(myVec));=C2=A0// Here an = implicit conversion happens from the potentially specialized std::function&= lt;void()> to type erased Callables
=C2= =A0}
}

[...]

`Callable<>` is = a static concept, so if you want to make a dynamic concept based on it, you= must use some other syntax besides `Callable<>`.

Is this question now solved?
I should explicate = here, that I personally strive for exactly this ambiguity to allow going ha= nd in hand with "normal" concepts.
Actually, I see = your point of ambiguity very clearly.
But maybe you have this per= spective, because the different applications of a concepts name are not goi= ng hand in hand (yet). Is that true?

In the follow= ing I will argue, why we should strive to reconcile Dynamic and "Stati= c" Concepts to go hand in hand with each other,
much like co= mpile time and runtime constexpr function execution does.


Plea to complete the symmetry to= constexpr functions:

Constexpr functions operate on Values. Values have to have a data ty= pe, that means in an abstract way,
data types are concepts (su= bsets of) the infinite set of potential values.

Concepts (from Concepts Lite) also represent subsets, but not upon values= but upon the infinite set of potential types.

= Trying to interwine both principles:
  • If you pass cons= tant (known at compilation) values into a constexpr function, you immediate= ly can work with it and determine everything you want at compile time.
    <= /li>
  • If you pass constant=C2=A0(known at compilation) types into a templ= ated function/class, you immediately can work with it and determine everyth= ing you want at compile time.
  • If you pass a dynamic (only known= at runtime) values into a constexpr function, you need to defer all work t= o the run time.
  • If you pass a dynamic (only known at compilatio= n due to polymorphism) types into a templated function/class, you need to d= efer all work to runtime.
Data types (as mentioned abov= e), guarantee certain subset of possible values a variable of that type can= have.
Concepts guaratee a certain subsets of types.
In= order to be able to defer an operations on concrete types (restricted by a= concept) to run time,=C2=A0
dynamic concepts have to make the sy= mmetry complete.


Yours cincerely,
Jakob

--
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/9a9e46d5-ed24-40d8-8451-8b32ec0146d5= %40isocpp.org.
------=_Part_1275_311731125.1494346788659-- ------=_Part_1274_354219459.1494346788659-- .