220 32239 <20170429171449.5124179.6280.29268@gmail.com> article Path: news.gmane.org!.POSTED!not-for-mail From: Tony V E 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 13:14:49 -0400 Lines: 166 Approved: news@gmane.org Message-ID: <20170429171449.5124179.6280.29268@gmail.com> 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 1493486093 24973 195.159.176.226 (29 Apr 2017 17:14:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Apr 2017 17:14:53 +0000 (UTC) Cc: d25fe0be@outlook.com To: Eyal Rozenberg , std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQIIZFETZACRUBETHFCFE@isocpp.org Sat Apr 29 19:14:48 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f72.google.com ([74.125.83.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d4VxI-0006OX-CA for gclcip-std-proposals@m.gmane.org; Sat, 29 Apr 2017 19:14:48 +0200 Original-Received: by mail-pg0-f72.google.com with SMTP id j127sf20610098pgc.10 for ; Sat, 29 Apr 2017 10:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc: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=7huM2iS8V6EXp5jTQggxXbvxOQgJDg0CvxAC4pSHD+g=; b=xfcj7oVa3dPSxC+F6XpWporQixRznra/+WYlXeOc4WbxLpr+Lc7F5a8hPUQmL/gKN7 g2A2CkrqoZQXbLLzeNmJpw6AAag1XRFmM9OemvMMDO+hfthEfxJqwCSBffyPTBjfu4QJ o95BF4TEgAoKWtSp7MA8659JwF7ZRMaWpdGAP2Q7MuFd1GRkFdOBONzZWZ6I/gw1w1Ck qYpoRjl2WdoP/51P5BwLfgcFKR4ccGL+fdaXrZh/MTVK7hYU6AoMXQteLu/o0GnqgunT iiYCzz1dWAZ4en/N0pNzVcvr33jbd0S5Czu6wEdBMhkvvDUZiJcnzsyzXFYsQhUZcy74 ANRQ X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc :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=7huM2iS8V6EXp5jTQggxXbvxOQgJDg0CvxAC4pSHD+g=; b=I5sPBhSu0jTatjRIYS9B+CI9goB9b5E/cRHI7Y+Vgx6ZtMiljT1nag+uURA0qjvhoJ I1FY95Eb56fn5r0fEKQmfDMrc9suZ91MQ7X+01NPnBwT+YY+tHJmNu9aUbnm+WeExYj4 RX7KFSdN8pbGJ97QQoUiEXjZk+ZE1xRDTZeu5arI8IKJvVIG/0yY09mL6BxVGTLKAZNr Xn6sK1/5D1DiLZYobUJ5ARiKSlA3W+nxtwbBw+llSuCzA4sj+yPhZg0qKKhu9X0XJ2S/ F8zmmQnSWP+RgVqSesR6HN06tRx8/loYhZrtTuvJoY6hsd7g+yEwnWcnQqCpxBKaXBJf X-Gm-Message-State: AN3rC/6Vl3bCIE6G6yidwmTwK1UReUkAEEqqL0tNP3VAdhPDmQxJzAep 9uFd3x0Cit8XKQ== X-Received: by 10.99.23.97 with SMTP id 33mr8192003pgx.31.1493486093795; Sat, 29 Apr 2017 10:14:53 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.164.225 with SMTP id d94ls2467990ioj.19.gmail; Sat, 29 Apr 2017 10:14:52 -0700 (PDT) X-Received: by 10.36.70.204 with SMTP id j195mr14726970itb.22.1493486092322; Sat, 29 Apr 2017 10:14:52 -0700 (PDT) Original-Received: from mail-io0-x243.google.com (mail-io0-x243.google.com. [2607:f8b0:4001:c06::243]) by mx.google.com with ESMTPS id a124si3037035ioe.11.2017.04.29.10.14.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Apr 2017 10:14:52 -0700 (PDT) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4001:c06::243 as permitted sender) client-ip=2607:f8b0:4001:c06::243; Original-Received: by mail-io0-x243.google.com with SMTP id h41so15819206ioi.1 for ; Sat, 29 Apr 2017 10:14:52 -0700 (PDT) X-Received: by 10.107.180.69 with SMTP id d66mr16762156iof.56.1493486092038; Sat, 29 Apr 2017 10:14:52 -0700 (PDT) Original-Received: from [127.0.0.1] ([2605:8d80:6a1:5c06:c466:61c5:a232:51e7]) by smtp.gmail.com with ESMTPSA id y7sm1382919itc.27.2017.04.29.10.14.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 29 Apr 2017 10:14:50 -0700 (PDT) X-Mailer: BlackBerry Email (10.3.3.2205) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:4001:c06::243 as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dmarc=pass (p=NONE sp=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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:32239 Archived-At: I don't really like "=E2=80=8Etemplate specification scopes", but I'm OK wi= th "class-namespace scopes"=E2=80=8E.=C2=A0 Not sure why, just my gut instincts.=C2=A0 Class-namespace encloses related items.=C2=A0 Template specs could enclose anything. Sure, a good programmer will only us= e it wisely, but it is fundamentally just syntactic relationships, not sema= ntic relationships.=C2=A0 I prefer language constructs that represent semantic properties. Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0portable=C2=A0Babbage=C2=A0Devi= ce =C2=A0 Original Message =C2=A0 From: Eyal Rozenberg Sent: Saturday, April 29, 2017 12:49 PM To: std-proposals@isocpp.org Reply To: std-proposals@isocpp.org Cc: d25fe0be@outlook.com Subject: Re: [std-proposals] Re: Has it been proposed to allow "template <.= ...>" to apply to multiple declarations/definitions? 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 > 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. --=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/20170429171449.5124179.6280.29268%40gmail.com. .