220 32400 article Path: news.gmane.org!.POSTED!not-for-mail From: Denis Kotov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: When C++ will support unconstrained generic functions ? Date: Thu, 11 May 2017 13:34:28 -0700 (PDT) Lines: 289 Approved: news@gmane.org Message-ID: References: <2b6b016d-3463-416b-afd5-d10bac62a334@isocpp.org> <3657aeea-1787-40ee-9320-9b6e6466f061@isocpp.org> <872d1f11-6ded-4398-9117-1c3871f364b4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5377_176465285.1494534868848" X-Trace: blaine.gmane.org 1494534877 29242 195.159.176.226 (11 May 2017 20:34:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 11 May 2017 20:34:37 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDY2PNGE6QOBBVMV2PEAKGQE65MFDGA@isocpp.org Thu May 11 22:34:30 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d8un8-0007My-Gb for gclcip-std-proposals@m.gmane.org; Thu, 11 May 2017 22:34:30 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id k129sf22832626ybb.15 for ; Thu, 11 May 2017 13:34:31 -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=B7x53PCg/zYBnXX9+4bbS/SKtG26bhvLDOjbMXWOqfc=; b=vBtFT/ejNh486/h+VQbSb5NRPwFTXf0ygm2u1TG1uudXzQoEmclt1Ify3rxxA805+g QNu/2Ztf3lsM/dKzd0yz+sQ4ZOq0DNtL9Lwpvlv5AsgSqLeEBXFTOeI4aaYcNH6gvv38 PmdV+iLDy0pWPsM19NjPi8ojz8dxplvhOIm+G/RwRIGX/lxIeWfnU3Tgy8deaM619YNh ZamLbVU7tJO/Du4z6AU9KnMiC6Px8wp0FDdwcslLSMtRMxszY2LSsplo4CE/Fg+2s1G8 UJiqrdhOhPdlmiAPOtoetkSOZr72hzgCb4NbEZPA6foGdjbZEdv7YYjTaI8ey4BS5fez ex7A== 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=B7x53PCg/zYBnXX9+4bbS/SKtG26bhvLDOjbMXWOqfc=; b=ZVcCWU6H4CT8Zv17ZPYMgUfc6st8v09IkX3gG967biKrcwohNHaf6drehBpFU0hgoH 8jrpD7iQ8zORJW56MIy+XxPkJFcHJAX2Bv/0H6Dv563cvn/OuuRR0ZbC/gRzMG9GSlTP XiJRhzJY1PWblGxUViaVS8DvtxkG+5lObcQi3cHlDwzFH814yW59XugtFQW7TULOvF1K n+VS4xDbtE29YycAPHayu4/d3PvH7Ty023Ip/yTAtCRMN/HShjgG5FcXhwC24JZ/MdYj x2NqO3h1e3VaQ+D5BdE8NdaxVCC1R3exCHkgMsJ8PmpSjkWcRtMKIgIIy95vEea6bLNa IR9A== 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=B7x53PCg/zYBnXX9+4bbS/SKtG26bhvLDOjbMXWOqfc=; b=HmI/mXXc9degCOr1Kj+zXHzS7s4Epq7jOpYrthT00cqoUk8h3SMypN2KqfonEhV2Ot VJISL5hhWRtWpKeOgN8QkycbzbobzRSZMLN7NV/MyMuar+Fc9QdUEEwFgWwBTjE1LMFV YfTN/GJuI1Ca2okg1gKBIhfHlAZfxeFtOyLwLPiA9Krc2Px5FSE0x9AeDGPNAsH/f5MH wB45xD/PzRTFth8VC7pbqklYiGWK31wYfY/KEoEYKTwj7LJaFhlzqgCspwEGK1KVK2uS YCaGqG3cIeXZfRZdP5AAPWlDBYEJax4uZYsdg5UYpA6Al26a7+hFNuO7W6WE+WpwYgRe z/JQ== X-Gm-Message-State: AODbwcA4JeHuvGSHVgz3ec8rPn/DMfcF1sPlNutWSaKb2Rqat+83rXDc cPW0uz1ef06CgQ== X-Received: by 10.13.228.197 with SMTP id n188mr252573ywe.156.1494534870473; Thu, 11 May 2017 13:34:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.27.130 with SMTP id z2ls5795302otd.45.gmail; Thu, 11 May 2017 13:34:29 -0700 (PDT) X-Received: by 10.157.14.91 with SMTP id n27mr9265otd.8.1494534869375; Thu, 11 May 2017 13:34:29 -0700 (PDT) In-Reply-To: <872d1f11-6ded-4398-9117-1c3871f364b4@isocpp.org> X-Original-Sender: redradist@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:32400 Archived-At: ------=_Part_5377_176465285.1494534868848 Content-Type: multipart/alternative; boundary="----=_Part_5378_1446275676.1494534868849" ------=_Part_5378_1446275676.1494534868849 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Arthur O'Dwyer *>> Anyway, @Denis, you probably don't want 'auto' parameters on your=20 functions anyway, because then you still have to deal with the messiness of= =20 overload sets, and having to define all your functions in header files, and= =20 so on. If you really find yourself doing a lot of template functions, maybe= =20 consider* I would say that I would prefer writing in such way, because for me it=20 seems like pure polymorphic programming ... It is like Python programming= =20 but with ability to compile your Python program and find all issues at=20 compile time instead of runtime. It is so awesome !! =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 10 =D0=BC=D0=B0=D1=8F 2017 =D0=B3., 1:38:00= UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB= =D1=8C Arthur O'Dwyer =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > > On Tuesday, May 9, 2017 at 11:30:47 AM UTC-7, Nicol Bolas wrote: >> >> On Tuesday, May 9, 2017 at 2:17:45 PM UTC-4, Denis Kotov wrote: >>> >>> Hi Nicol, >>> >>> It is very strange why it is a part of concept, for me it seems like=20 >>> extension for templates >>> >> >> Because the Concepts TS defines the ability to constraint function=20 >> parameters transparently: >> >> void Func(ConceptName t); >> >> is equivalent to: >> >> template >> void Func(T t); >> >> `auto` is thus redefined as simply an unconstrained context. >> >> It's not strange at all. It's a natural thing for Concepts TS to do. And= =20 >> besides, once you have concepts, you'll be using them far more than `aut= o`=20 >> for function parameters. There aren't that many functions that can truly= =20 >> take *any* type. Even forwarding functions like `emplace` should=20 >> constrain their parameters to those types which can actually be used to= =20 >> construct the object they're supposed to. >> > > As Nicol also wrote: > > There is a lot of uncertainty about how much of Concepts TS's "terse"= =20 > syntax we really want in the language. > > The fact that Andrew Sutton (or whoever it was =E2=80=94 apologies if I'm= wrong =E2=80=94=20 > but my impression is that it was him) bundled "terse syntax" straight int= o=20 > the Concepts proposal, instead of splitting up the functional "Concepts"= =20 > proposal from the purely syntactic-sugar "terse syntax" proposal, is one = of=20 > the (many) reasons that "Concepts" has taken so long to get into the=20 > language. > > My impression is that a significant fraction of the Committee share=20 > Nicol's "uncertainty" about terse syntax =E2=80=94 i.e., "I'd be more ame= nable to=20 > this proposal if it didn't come with terse syntax." > My further impression is that a vocal minority are unhappy at a higher=20 > level with how Sutton has handled the level-1 complaints =E2=80=94 i.e., = "I'd=20 > actually be in favor of all of these features separately, but after the= =20 > aforementioned response, continuing to bundle them together is so=20 > disingenuous that I oppose the bundled proposal on moral grounds." > > http://honermann.net/blog/2016/03/06/why-concepts-didnt-make-cxx17/ > > Anyway, @Denis, you probably don't want 'auto' parameters on your=20 > functions anyway, because then you still have to deal with the messiness = of=20 > overload sets, and having to define all your functions in header files, a= nd=20 > so on. If you really find yourself doing a lot of template functions, may= be=20 > consider > > // Unconstrained generic function (as inline variable of closure type) > inline auto func =3D [](const auto &i) { > std::cout << "Type of object i is " << typeid(i).name() << std::endl; > std::cout << "Value is " << i << std::endl; > }; > > int main() { > func(1); > func(std::string{"Hi Denis !"}); > return 0; > } > > > and let us know how it goes? (Probably a bad idea, but I'm not joking tha= t=20 > it *might* be worth a try.) > > my $.02, > Arthur > --=20 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 e= mail 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/c67567e3-2086-4f43-9859-6e2a58ba51b7%40isocpp.or= g. ------=_Part_5378_1446275676.1494534868849 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Arthur O'Dwyer
<= b>>> Anyway, @Denis, you probably don't want 'auto' param= eters on your=20 functions anyway, because then you still have to deal with the messiness of overload sets, and having to define all your functions in header=20 files, and so on. If you really find yourself doing a lot of template=20 functions, maybe consider

I would say that I would prefer writin= g in such way, because for me it seems like pure polymorphic programming ..= .. It is like Python programming but with ability to compile your Python pro= gram and find all issues at compile time instead of runtime.
It is so aw= esome !!

=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 10 =D0=BC=D0=B0=D1=8F 2017 = =D0=B3., 1:38:00 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1= =82=D0=B5=D0=BB=D1=8C Arthur O'Dwyer =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0=D0=BB:
On = Tuesday, May 9, 2017 at 11:30:47 AM UTC-7, Nicol Bolas wrote:
On Tuesday, May 9, 2017 at 2:17:= 45 PM UTC-4, Denis Kotov wrote:
Hi Nicol,

It is very strange why it is a part of concep= t, for me it seems like extension for templates

= Because the Concepts TS defines the ability to constraint function paramete= rs transparently:

void <= span style=3D"color:#606">Func(ConceptName t);

is equivalent= to:

template<ConceptName T= >
void <= span style=3D"color:#606">Func(T t);

`auto` is thus rede= fined as simply an unconstrained context.

It's not strange at al= l. It's a natural thing for Concepts TS to do. And besides, once you ha= ve concepts, you'll be using them far more than `auto` for function par= ameters. There aren't that many functions that can truly take any type. Even forwarding functions like `emplace` should constrain their par= ameters to those types which can actually be used to construct the object t= hey're supposed to.

As Nicol= also wrote:
>=C2=A0There is a lot of uncertainty about how = much of Concepts TS's "terse" syntax we really want in the la= nguage.

The fact that Andrew Sutton (or whoever it was =E2= =80=94 apologies if I'm wrong =E2=80=94 but my impression is that it wa= s him) bundled "terse syntax" straight into the Concepts proposal= , instead of splitting up the functional "Concepts" proposal from= the purely syntactic-sugar "terse syntax" proposal, is one of th= e (many) reasons that "Concepts" has taken so long to get into th= e language.

My impression is that a significant fraction of the Comm= ittee share Nicol's "uncertainty" about terse syntax =E2=80= =94 i.e., "I'd be more amenable to this proposal if it didn't = come with terse syntax."
My further impression is that a vocal mino= rity are unhappy at a higher level with how Sutton has handled the level-1 = complaints =E2=80=94 i.e., "I'd actually be in favor of all of the= se features separately, but=C2=A0after the aforementioned response, continu= ing to bundle them together is so disingenuous that I oppose the bundled pr= oposal on moral grounds."

=
Anyway, @Denis, you probably don't want 'auto' param= eters on your functions anyway, because then you still have to deal with th= e messiness of overload sets, and having to define all your functions in he= ader files, and so on. If you really find yourself doing a lot of template = functions, maybe consider

// Unconstrained generic function (as inline variab=
le of closure type)
inline auto func =3D [](const=
 auto &i) {
=C2=A0 std::c=
out << "Type=
 of object i is " << typeid(i).name() << std::endl;
=C2=A0 s=
td::cout << "Value is " << i << std=
::endl;
};
=

int main() =
{
=C2=A0 func(1);
=C2=A0 func(=
std::string{"=
Hi Denis !"});
=C2=A0 return 0;=

}

and let us know how it goes? (Probably a bad= idea, but I'm not joking that it might be worth a try.)

=
my $.02,
Arthur

--
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/c67567e3-2086-4f43-9859-6e2a58ba51b7= %40isocpp.org.
------=_Part_5378_1446275676.1494534868849-- ------=_Part_5377_176465285.1494534868848-- .