220 32300 article Path: news.gmane.org!.POSTED!not-for-mail From: Lee Howes Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Has it been proposed to allow "template <...>" to apply to multiple declarations/definitions? Date: Thu, 4 May 2017 09:18:28 -0700 Lines: 84 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> <1b4adafd-e4b8-e5a8-4d58-035fc7cdaff0@technion.ac.il> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c054954905bb6054eb51f59 X-Trace: blaine.gmane.org 1493914710 21228 195.159.176.226 (4 May 2017 16:18:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 4 May 2017 16:18:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5OBRO5TMFBBVVIVXEAKGQERDMRKEY@isocpp.org Thu May 04 18:18:26 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f69.google.com ([74.125.83.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d6JST-0005Pr-TI for gclcip-std-proposals@m.gmane.org; Thu, 04 May 2017 18:18:26 +0200 Original-Received: by mail-pg0-f69.google.com with SMTP id 187sf14612050pgc.3 for ; Thu, 04 May 2017 09:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject: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=FCNb7wkrcCwlj7f9M4pS0udkMHA+Y6iMZORQhA4Q4xU=; b=j7YZNd4eqUz6YxbH8FJx/ujApuiUIfOZioRWYQXwIqJm6lCqS7mCwpfqS3K8qYp/Am lLvs9tUklG/qxbtWF5/mSlOwEvdxkWT6FnqIMx+yv6IbufnigodXj72T/7R/w7sPDYAC AIJf56EkJG//hDkmHzVtmZg9PvhFHW49t8JZMR2u3OWRdZ+rYK40WYQfJDRRm9RrZW6z J0sW8Vw+lAJaUysA6wY8giFuMex2vlC7ZCD2noH4sBlLt6v0Q2+f9QoUg98NsXLZ4Nkt d+m1cxzbaN4BVCV1di99iclJTokIr7Ff/SMsrLkvQ5s2hDvY6PYB9Jpm1d2AXEFkucTK 36Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject: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=FCNb7wkrcCwlj7f9M4pS0udkMHA+Y6iMZORQhA4Q4xU=; b=YNc4mMQ+3U7PDHztwYgfsNG/v3xfHxNHt5cgoRF5X4D7f6vy2rMWVIiYhOc82mwRVP rBsODfhYhDy5q5qwMflp4ahTMEJyRNIj87WXItDYISW3qy7u81+bKPzfnC9OX6miO7H4 K+SjP1d+9FnudaC2fj7Y8cl2cZdP6dfQSmHbqW7+OhLQM1OlIh4vVF6GgoHuIjGoc5f/ aNyu5xYBHDGQcr9xjucVd1FRwDxHjVZ0p1wRh+xwqghJI8Vem5FbGHpr+tYz8w6XJYSA sgmt1VZpLxC7cxzjoX66bvbsBBEt/dL1CK/XE5VaYcvmQ9zIm95JDP5i63NkcXwh9LTg Agcg== X-Gm-Message-State: AN3rC/5I07gLK0mtBqIy/vAIfMOgiArr4LsWdpzSM6Eh6oCJ+cXFqCyk qJZ1Q3bW9VUXbA== X-Received: by 10.99.119.141 with SMTP id s135mr8026716pgc.47.1493914711295; Thu, 04 May 2017 09:18:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.26.2 with SMTP id 2ls568561iti.12.gmail; Thu, 04 May 2017 09:18:29 -0700 (PDT) X-Received: by 10.107.166.211 with SMTP id p202mr41493542ioe.15.1493914709814; Thu, 04 May 2017 09:18:29 -0700 (PDT) Original-Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com. [2607:f8b0:4001:c0b::22a]) by mx.google.com with ESMTPS id 124si1520270itj.14.2017.05.04.09.18.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 09:18:29 -0700 (PDT) Received-SPF: pass (google.com: domain of xrikcus@gmail.com designates 2607:f8b0:4001:c0b::22a as permitted sender) client-ip=2607:f8b0:4001:c0b::22a; Original-Received: by mail-it0-x22a.google.com with SMTP id x188so589168itb.0 for ; Thu, 04 May 2017 09:18:29 -0700 (PDT) X-Received: by 10.36.253.7 with SMTP id m7mr3026875ith.85.1493914709143; Thu, 04 May 2017 09:18:29 -0700 (PDT) Original-Received: by 10.79.4.195 with HTTP; Thu, 4 May 2017 09:18:28 -0700 (PDT) In-Reply-To: <1b4adafd-e4b8-e5a8-4d58-035fc7cdaff0@technion.ac.il> X-Original-Sender: xrikcus@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of xrikcus@gmail.com designates 2607:f8b0:4001:c0b::22a as permitted sender) smtp.mailfrom=xrikcus@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:32300 Archived-At: --94eb2c054954905bb6054eb51f59 Content-Type: text/plain; charset=UTF-8 I like the class namespace proposal. I've often wished for such a thing as a clean way of separating interface from implementation in template code. I'm a little less keen on this proposal because I share the concern that when I see: template { void foo(T param); void bar(T param); } My brain wants to assume that those Ts are the same. Whether that matters is open to question, and depends substantially on whether such a fact would ever be expected to be visible. It may matter with separate compilation. If I have the above in a header, then in one compilation unit: template { void foo(T param) { do something with param; } void bar(T param) { do something with param; } } something() { foo(3); } It feels natural if I instantiate any one of these on an explicit type, I should be able to link against any of them. I don't think that's a reasonable assumption, but natural enough that it could lead to confusion.Using the same name but with a syntax that clearly denotes independence is a very different form implicit relation, and I think easier to explain. -- 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/CAJH_FNVebzbcf-iME1unNM8MNEx2TtEnJCRtXamz769TReqYGw%40mail.gmail.com. --94eb2c054954905bb6054eb51f59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like the class namespace proposal. I've often wished= for such a thing as a clean way of separating interface from implementatio= n in template code.

I'm a little less keen on this p= roposal because I share the concern that when I see:
template<= typename T> {
=C2=A0 void foo(T param);
=C2=A0 void = bar(T param);
}

My brain wants to assume= that those Ts are the same.=C2=A0

Whether that ma= tters is open to question, and depends substantially on whether such a fact= would ever be expected to be visible. It may matter with separate compilat= ion. If I have the above in a header, then in one compilation unit:
template<typename T> {
=C2=A0 void foo(T param) { d= o something with param; }
=C2=A0=C2=A0void bar(T param) { do some= thing with param; }
}

something() = {
foo(3);
}

It feels natural i= f I instantiate any one of these on an explicit type, I should be able to l= ink against any of them. I don't think that's a reasonable assumpti= on, but natural enough that it could lead to confusion.Using the same name = but with a syntax that clearly denotes independence is a very different for= m implicit relation, and I think easier to explain.=C2=A0


--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJH_FNVebzbcf-iM= E1unNM8MNEx2TtEnJCRtXamz769TReqYGw%40mail.gmail.com.
--94eb2c054954905bb6054eb51f59-- .