220 18761 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Factory functions as deducing constructors? (N4471) Date: Thu, 25 Jun 2015 10:05:32 +0800 Lines: 140 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_E7DE3F32-3CF9-4259-A081-5DB7D52502A1" X-Trace: ger.gmane.org 1435197954 31674 80.91.229.3 (25 Jun 2015 02:05:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jun 2015 02:05:54 +0000 (UTC) Cc: std-proposals@isocpp.org, Richard Smith To: Michael Spertus Original-X-From: std-proposals+bncBCW25A7E3QCRB6ODVWWAKGQEDIMHDII@isocpp.org Thu Jun 25 04:05:48 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z7wXz-0000eD-0R for gclcip-std-proposals@m.gmane.org; Thu, 25 Jun 2015 04:05:47 +0200 Original-Received: by pdmx3 with SMTP id x3sf121306161pdm.1 for ; Wed, 24 Jun 2015 19:05:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=edbyOdxG46JjWPeze5naYqRI1Gc/aB3UOglxDhhbMP8=; b=AI1LUTQiExBhGPinu1RXACpjcD+GeVZoaQNlqsMHBBn1EdL7464wpzNgxQYVkKL7qS 5VaIgugqORSXgpMb7mby5pKOeDDJnCxt45CRj0ZgmujoBXsfYO/FXMJfz4v2Yztnbul8 f1MLxI92YteKveUXkWO4SzEttsXV9ltiiyxm5BahDkK9jlX6cwQwUfoQQZcampnCfLsp NKfMDX9StzMLOJkKP0wvDjiRMJaTyjTIlsTrzScKmzKKUtjF5odN8rmDVj1Y0ecBywXw 2z/bF/dnKGIeHJvDgnXPkLoYbhvzEZnvxqHobTKMp96QGiIffygl/Gm8gFKKC7o8jcvi gijw== X-Gm-Message-State: ALoCoQlgwbqaCTcAeDSEcZNa0xJgWFWiUraYcb347SpBTEI31RpSdFTd82QOp9sXxAgEYa9e7Lc6 X-Received: by 10.70.96.41 with SMTP id dp9mr56483378pdb.13.1435197945892; Wed, 24 Jun 2015 19:05:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.18.80 with SMTP id a77ls610000ioj.36.gmail; Wed, 24 Jun 2015 19:05:45 -0700 (PDT) X-Received: by 10.66.100.138 with SMTP id ey10mr85254241pab.110.1435197944986; Wed, 24 Jun 2015 19:05:44 -0700 (PDT) Original-Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com. [2607:f8b0:400e:c03::233]) by mx.google.com with ESMTPS id qd9si42450847pbc.97.2015.06.24.19.05.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 19:05:44 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::233 as permitted sender) client-ip=2607:f8b0:400e:c03::233; Original-Received: by paceq1 with SMTP id eq1so39872961pac.3 for ; Wed, 24 Jun 2015 19:05:44 -0700 (PDT) X-Received: by 10.66.63.70 with SMTP id e6mr84688287pas.62.1435197944846; Wed, 24 Jun 2015 19:05:44 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.44.94]) by mx.google.com with ESMTPSA id ph4sm28162495pdb.43.2015.06.24.19.05.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jun 2015 19:05:43 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.2098) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::233 as permitted sender) smtp.mail=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:18761 Archived-At: --Apple-Mail=_E7DE3F32-3CF9-4259-A081-5DB7D52502A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 2015=E2=80=9306=E2=80=9325, at 8:47 AM, Michael Spertus wrote: >=20 > It=E2=80=99s worth mentioning that since I regard the template deduction = for existing constructors in the primary template as by far the most import= ant part of the proposal (Indeed, I would strongly favor the proposal even = without any kind of factory functions), I lean towards a solution that look= ed as much like existing constructors as possible. I am open to the possibi= lity that this implication (although not its premise) is fallacious reasoni= ng on my part. Heh=E2=80=A6 are we discussing this now? :P It seems that the transparent feature works well in the majority of simple = cases (the template type parameter is exactly suitable as the constructor p= arameter type, partial specializations don=E2=80=99t exist or are exactly c= ompatible), but sometimes it will break and the programmer will want manual= control. How about implicit declaration of the non-member factory functions? Create = one signature per suitable constructor, including partial and explicit spec= ializations. Essentially, provide a visible window on the parallel overload= set. The implicit definition would follow conservative rules like in N4471, but = in any doubtful cases it could be defined as deleted. Some cases could fall= through the cracks, e.g. where a specialization constructor parallels a pr= imary constructor but one is suitable and the other isn=E2=80=99t. But, the= fidelity level should be pretty good, authority is returned to the author = via explicit definitions, and it captures most existing factory functions. Hopefully that would be the best of both worlds, capturing all the cases wh= ere N4471 works. I=E2=80=99m happy to postpone detailed analysis until more= brain cells are free, though. > On 2015=E2=80=9306=E2=80=9324, at 10:56 PM, David Rodr=C3=ADguez Ibeas wrote: >=20 > Let's see if I understand the proposal would be replacing 'make_shared= (arg1, arg2)' with 'shared_ptr(arg1, arg2)' is it? It would provide a way to replace shared_ptr( ptr ) with shared_ptr( ptr= ). Perhaps there could be a new constructor shared_ptr::shared_ptr( in_= place_construction_tag, arg1, arg2 ), but it would need separate motivat= ion. There are plenty of motivating cases, though, so intricate library det= ails seem premature. --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --Apple-Mail=_E7DE3F32-3CF9-4259-A081-5DB7D52502A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2015= =E2=80=9306=E2=80=9325, at 8:47 AM, Michael Spertus <mike_spertus@symantec.com> wrot= e:

It=E2=80=99s worth mentioning that since = I regard the template deduction for existing constructors in the primary te= mplate as by far the most important part of the proposal (Indeed, I would s= trongly favor the proposal even without any kind of factory functions), I l= ean towards a solution that looked as much like existing constructors as po= ssible. I am open to the possibility that this implication (although not it= s premise) is fallacious reasoning on my part.

Heh=E2=80=A6 are we discussin= g this now? :P

It= seems that the transparent feature works well in the majority of simple ca= ses (the template type parameter is exactly suitable as the constructor par= ameter type, partial specializations don=E2=80=99t exist or are exactly com= patible), but sometimes it will break and the programmer will want manual c= ontrol.

How about= implicit declaration of the non-member factory functions? Create one signa= ture per suitable constructor, including partial and explicit specializatio= ns. Essentially, provide a visible window on the parallel overload set.

The implicit definit= ion would follow conservative rules like in N4471, but in any doubtful case= s it could be defined as deleted. Some cases could fall through the cracks,= e.g. where a specialization constructor parallels a primary constructor bu= t one is suitable and the other isn=E2=80=99t. But, the fidelity level shou= ld be pretty good, authority is returned to the author via explicit definit= ions, and it captures most existing factory functions.

Hopefully that would be the best of b= oth worlds, capturing all the cases where N4471 works. I=E2=80=99m happy to= postpone detailed analysis until more brain cells are free, though.
<= div class=3D"">

On = 2015=E2=80=9306=E2=80=9324, at 10:56 PM, David Rodr=C3=ADguez Ibeas <dibeas@ieee.org> wrote:
Let's see if I underst= and the proposal would be replacing 'make_shared<T>(arg1, arg2)' with= 'shared_ptr<T>(arg1, arg2)' is it?

It would provide a way to repla= ce shared_ptr<T>( ptr )=  with shared_ptr( ptr ).= Perhaps there could be a new constructor shared_ptr<T>::shared_ptr( in_place_construction_tag<T>, = arg1, arg2 ), but it would need separate motivation. There are plent= y of motivating cases, though, so intricate library details seem premature.=

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--Apple-Mail=_E7DE3F32-3CF9-4259-A081-5DB7D52502A1-- .