220 32238 article Path: news.gmane.org!.POSTED!not-for-mail From: Eyal Rozenberg Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Has it been proposed to allow "template <...>" to apply to multiple declarations/definitions? Date: Sat, 29 Apr 2017 18:49:36 +0200 Lines: 135 Approved: news@gmane.org Message-ID: References: <0f4715ef-223b-4d28-8381-d7a43b93d792@isocpp.org> <701a4af0-ba41-4546-b7db-e653a14392a0@isocpp.org> <53267650-79b8-431a-abd4-0d0d93991645@isocpp.org> <58FF63C9.7040202@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1493484582 22783 195.159.176.226 (29 Apr 2017 16:49:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Apr 2017 16:49:42 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Cc: d25fe0be@outlook.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDHKZN7LR4ARBJUISPEAKGQERYJVJPI@isocpp.org Sat Apr 29 18:49:37 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d4VYv-0005oT-NV for gclcip-std-proposals@m.gmane.org; Sat, 29 Apr 2017 18:49:37 +0200 Original-Received: by mail-lf0-f69.google.com with SMTP id e4sf13368426lfg.7 for ; Sat, 29 Apr 2017 09:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding :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=P83RoOoD7kGtGRp8K2a/wrkeOSxVBRWfJn/25jxPsT0=; b=OADdtig+7RR3loIJrg4nkCl9fA745UB2ngdOWj7wNX3fu/jA3Un8bp0nI7BmMqbILd xX1wJLUsAe6yvoIk1Z8h5Sq+rsb1BVA7Cxf5VBSBVfNdf4Z1rp8nmot08t8OHUmkSlvy A/bUB3jdMszLCrrKGmV5s23vjnYPsqLHfWGs6jrXiVZDdo5KxxuHKoKFXG/uArdcQxQM 2aTPEfDYF79xBeWsyATQSDszC215bGXcV8szFGTms1PUpFECsAb+8bBZNmBVmZEpGsu2 T+OqlgKeRpgubvwqJXzvRqw0YpNjcLm0LWoXssQ/7rXb9Lzhr8RvDybKW5LsCWkHdXbL X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :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=P83RoOoD7kGtGRp8K2a/wrkeOSxVBRWfJn/25jxPsT0=; b=n+fjCANwNnHgY5fo2eOB+IQCEauLk5EGc3tPl7e38vat62MsyV1Xwz688UEC8KLcyN JQ96IfQRQdSGZ5KUXdghsUf6bndRJfziCUSr9jiP+AKKDky/HLKBa0IwQQT3PvcazSak O4Ijbr7CkxgxA453cIPuElaGCyhk3Fm0yXfCA7+v7GkBMSyKEQuL9dZAKD7KWIg2fC/y HxiTty5mDK6dfe5bFmgkQfJiaX9WQSMmD1feaZDT96muoCmO0hPRLa/jlN45t9bJ5FKV h/kxXcITzniArc6XuTR4mSc+vgWt9PcCSJC7lGUzD9JxGey+utbFsFe9fcoAc7z8EvM X-Gm-Message-State: AN3rC/5G+2xZa6PpaDY5pdxQg2w4YVhgf+7My7dSP3xYEu5B9DwhJzzF egzouYREyIweMw== X-Received: by 10.46.80.7 with SMTP id e7mr2005448ljb.10.1493484583514; Sat, 29 Apr 2017 09:49:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.47.86 with SMTP id v83ls1156042wmv.1.canary-gmail; Sat, 29 Apr 2017 09:49:41 -0700 (PDT) X-Received: by 10.80.184.51 with SMTP id j48mr13333703ede.165.1493484581722; Sat, 29 Apr 2017 09:49:41 -0700 (PDT) Original-Received: from fester.cwi.nl (fester.cwi.nl. [192.16.191.27]) by mx.google.com with ESMTPS id b36si10076166eda.91.2017.04.29.09.49.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Apr 2017 09:49:41 -0700 (PDT) Received-SPF: pass (google.com: domain of srs0=t3nmv=4f=technion.ac.il=eyalroz@cwi.nl designates 192.16.191.27 as permitted sender) client-ip=192.16.191.27; Original-Received: from fester.cwi.nl (fester.cwi.nl [192.16.191.27]) by fester.cwi.nl (8.14.4/8.12.3) with ESMTP id v3TGnfd8026501; Sat, 29 Apr 2017 18:49:41 +0200 Original-Received: from [192.168.2.1] (ip565d4370.direct-adsl.nl [86.93.67.112] (may be forged)) (authenticated bits=0) by fester.cwi.nl (8.14.4/8.12.3) with ESMTP id v3TGnfTT026499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 29 Apr 2017 18:49:41 +0200 In-Reply-To: <58FF63C9.7040202@gmail.com> X-Original-Sender: eyalroz@technion.ac.il X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of srs0=t3nmv=4f=technion.ac.il=eyalroz@cwi.nl designates 192.16.191.27 as permitted sender) smtp.mailfrom=SRS0=t3nmV=4F=technion.ac.il=eyalroz@cwi.nl 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:32238 Archived-At: I've had another look at your suggestion, Matthew. I've now bought into your explanation of why it's not really more complicated than what I suggested. So - I like it. But there's a bit of a conundrum here. Your proposal makes sense. I also think my proposal makes sense, and the justification is at least partially similar, i.e. "Why should a template specification apply to just a single definition/declaration?" as an example of DRY. Both proposals are not complicated to implement, it seems. Now, your suggestion has the advantage of doing more in its use case. That is, with my suggestion you would write template { List::List(...) { ... } List& List::operator=3D(List const& other) { ... } List::iterator List::find(...) { ... } } and with yours it would just be template namespace class List { List(...) { ... } List& operator=3D(List const& other) { ... } iterator find(...) { ... } } on the other hand, your suggestion would not allow for template { bool all_of(InputIterator First, InputIterator Last, Predicate Comp); bool any_of(InputIterator First, InputIterator Last, Predicate Comp); } which my suggestion does allow, and I hope you would agree is useful to have. Also, if only one suggestion were accepted, it's not clear there would be sufficient motivation to accept the other. I would like to say the solution is a combination of both proposals into one. In the combination, there are template specification scopes, and class-namespace scopes. Thus: template { namespace class List { List(...) { ... } List& operator=3D(List const& other) { ... } iterator find(...) { ... } } T foo_which_may_or_may_not_be_related(T x); } But then, this is (a bit) more complicated than either of the individual suggestions. What do you think? (You =3D Matthew and everybody else) Eyal On 04/25/2017 04:57 PM, Matthew Woehlke wrote: > On 2017-04-24 11:18, eyalroz@technion.ac.il wrote: >> On Monday, April 24, 2017 at 10:14:12 AM UTC+2, P=C3=A9ter Radics wrote: >>> There was a proposal a while back about "Class Namespace" (a quick sear= ch=20 >>> brings up this link, but I'm not sure this is the latest draft:=20 >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0223r0.html).= =20 >=20 > It is. I didn't get a chance to present it at Jacksonville, but the > informal feedback I received was that it needed more work. (Alas, now I > can't recall what folks were wanting...) >=20 >>> This proposal is smaller in scope then the OPs idea, but would solve th= e=20 >>> issue for class templates. >> >> I actually think that's a more complicated suggestion, since it requires= =20 >> some resolution work to find the right class. >=20 > How so? It's a fairly straight-forward transformation. This: >=20 > [TEMPLATE] // template <...> > namespace CLASS_SPEC { > TYPE DECL // e.g. int foo(...) > } >=20 > ...is equivalent to: >=20 > [TEMPLATE] TYPE CLASS_SPEC::DECL >=20 > ...and very nearly equivalent to: >=20 > [TEMPLATE] CLASS_SPEC { > TYPE DECL > }; >=20 > I don't see why the compiler would have to work any harder under the > proposal than it already needs to today. A simple implementation can > just memoize the namespace tokens and then transform every declaration > within the scope using said tokens to match its C++current equivalent. >=20 >> But be that as it may - what's the status of that proposal? I see that i= t's=20 >> been 'assigned' to the Evolution subgroup; should I post to that mailing= =20 >> lists about this whole business? >=20 > See above. Needs to be presented. Feedback is always appreciated! >=20 >> Also, do you think it's reasonable/advisable to draft a proposal in a=20 >> similar format and submit it more officially? >=20 > Please talk to me before submitting a similar proposal; it is probably > better to update the existing proposal instead, unless you are proposing > something significantly different. (Even if you want to propose an > alternative, maybe I would like to help :-).) >=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/d32aae5b-0098-e356-4629-0a5eab29f746%40technion.= ac.il. .