220 9948 <024B4235-736C-4BAA-8007-E8906A92A214@gmail.com> article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: auto variable templates? Date: Thu, 20 Mar 2014 19:04:14 +0800 Lines: 132 Approved: news@gmane.org Message-ID: <024B4235-736C-4BAA-8007-E8906A92A214@gmail.com> References: <878usaa8hz.fsf@euclid.axiomatics.org> <93E854CB-24C9-49ED-BE88-1A43D0FD715A@gmail.com> <877g7qm4yd.fsf@euclid.axiomatics.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_2B233623-063C-4802-BD47-FBF8DF5BAF4F" X-Trace: ger.gmane.org 1395313476 30076 80.91.229.3 (20 Mar 2014 11:04:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 11:04:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBSMWVOMQKGQELR4W6SA@isocpp.org Thu Mar 20 12:04:44 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WQamB-0007BH-LP for gclcip-std-proposals@m.gmane.org; Thu, 20 Mar 2014 12:04:43 +0100 Original-Received: by mail-ob0-f200.google.com with SMTP id gq1sf2711104obb.7 for ; Thu, 20 Mar 2014 04:04:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=S1m0RIYm2g6/eLKdr/jg1/3VegVTVRvE8b03tk38uco=; b=J6cQTutuoa4Lm/3HrkXus43cSiAcbO8DK5J3FZZD8XPtszrglZSo/jz8v+IwqiLcFH HX+xIArq7yCoprwOemBXvUmpd2Zy/PE5+Z30TUI74msm/Txuj+d57Inw0ZcMB/NGBpE2 /xhBp1f5GaEd4d750SQ9ScQr2TMP42b7yyOa6nIIPvWwnUq/1NR0Zxf6mu/4ONkmSeCw bBIK0ku/ImqZmigmO8VljQ9QvueONPU6KQjIKZ5ohGwHDRE2TSSoIO+JEdtIOmOpW2qV YjRGaCX1q0rFn1MQ0FZWLDALg+2sdxPP71aqYymbEWGa1vuo5yG2+h0dX1Q4iMkJFGAe HQ+g== X-Gm-Message-State: ALoCoQkjLOeZvXV92L0Wgu5sCz+n/RF4/Y6NOEeW25IbN7/gHIo7agUPBd+Bm8ajcPXEFJS0DR+j X-Received: by 10.50.164.198 with SMTP id ys6mr13184898igb.2.1395313482660; Thu, 20 Mar 2014 04:04:42 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.62.15 with SMTP id u15ls327291igr.37.gmail; Thu, 20 Mar 2014 04:04:41 -0700 (PDT) X-Received: by 10.66.231.40 with SMTP id td8mr46070300pac.103.1395313481533; Thu, 20 Mar 2014 04:04:41 -0700 (PDT) Original-Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [2607:f8b0:400e:c01::231]) by mx.google.com with ESMTPS id hb1si1231367pac.159.2014.03.20.04.04.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 04:04:41 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c01::231 as permitted sender) client-ip=2607:f8b0:400e:c01::231; Original-Received: by mail-pb0-f49.google.com with SMTP id jt11so779568pbb.8 for ; Thu, 20 Mar 2014 04:04:41 -0700 (PDT) X-Received: by 10.68.194.202 with SMTP id hy10mr46001549pbc.94.1395313481315; Thu, 20 Mar 2014 04:04:41 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.52]) by mx.google.com with ESMTPSA id gj9sm3242225pbc.7.2014.03.20.04.04.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 04:04:39 -0700 (PDT) In-Reply-To: <877g7qm4yd.fsf@euclid.axiomatics.org> X-Mailer: Apple Mail (2.1874) 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:c01::231 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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:9948 Archived-At: --Apple-Mail=_2B233623-063C-4802-BD47-FBF8DF5BAF4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 On 2014-03-20, at 2:14 AM, Gabriel Dos Reis wrote: > | not at instantiation. If his code > | exposes a defect, it belongs to name lookup, not the instantiation > | process.=20 >=20 > I am not quite sure what you think is the defect. I don't think there is, I'm just imagining a use-case similar to his exampl= e, where the user wants to use a private type to declare a non-type paramet= er. This is currently impossible at namespace scope. (There might already b= e a DR about it.) On 2014-03-20, at 3:14 AM, Johannes Schaub = wrote: > I was playing devil's advocate. You are saying that the following is a te= mplate "Devil's advocate" means arguing a hypothetical point which one does not tr= uly believe. Is this the case? -- Since this argument will continue going in circles, here is my suggestion f= rom a private email to Johannes: > FWIW, I'd recommend changing "This use is allowed when declaring variable= s in..." to "This use is allowed in variable declarations in..." since the = template declaration unequivocally encloses a variable declaration, whether= or that declaration declares a variable or a variable template specializat= ion set. To be clear, the text is in [decl.spec.auto] 7.1.6.4/4 and the fix is inten= ded to adjust it to match [temp] 14/1, "A declaration introduced by a templ= ate declaration of a variable is a variable template." The wording there is= a little imprecise, and should perhaps be "A template-declaration in which= the declaration declares a variable, declares a variable template." Which = is utterly the height of redundant obviousness, and I apologize. In any case, the idea already presumed by the standard is that a variable d= eclaration is "almost" a purely syntactic construct, such that we can decid= e that it's such before knowing what it has declared. TL;DR: auto needs to be valid for variable declarations even if they don't = declare variables. But it's not causing any problems. --=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=_2B233623-063C-4802-BD47-FBF8DF5BAF4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 <= br>
On 2014–03–20, at 2:14 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
=
| not at = instantiation. If his code
| exposes = a defect, it belongs to name lookup, not the instantiation
| process.
I am not quite sure what you think is the defect.

I don’t think there is, I’m just imagining a u= se-case similar to his example, where the user wants to use a private type = to declare a non-type parameter. This is currently impossible at namespace = scope. (There might already be a DR about it.)


On 2014–03–20, at 3:14 AM, Johannes Schaub <schaub.johannes@googlemail.c= om> wrote:

I was playing devi= l's advocate. You are saying that the following is a template

“Devil’s advocate” means arguing = a hypothetical point which one does not truly believe. Is this the case?

—

Since this argument= will continue going in circles, here is my suggestion from a private email= to Johannes:

FWIW, I&rs= quo;d recommend changing “This use is allowed when declaring variable= s in…” to “This use is allowed in variable declarations = in…” since the template declaration unequivocally encloses a v= ariable declaration, whether or that declaration declares a variable or a v= ariable template specialization set.

To be clear= , the text is in [decl.spec.auto] 7.1.6.4/4 and the fix is intended to adju= st it to match [temp] 14/1, “A declaration introduced by a template d= eclaration of a variable is a variable template.” The wordi= ng there is a little imprecise, and should perhaps be “A template-= declaration in which the declaration declares a variable, declar= es a variable template.” Which is utterly the height of redundant obv= iousness, and I apologize.

In any case, the idea a= lready presumed by the standard is that a variable declaration is “al= most” a purely syntactic construct, such that we can decide that it&r= squo;s such before knowing what it has declared.

T= L;DR: auto needs to be valid for variabl= e declarations even if they don’t declare variables. But it’s n= ot causing any problems.

--

---
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=_2B233623-063C-4802-BD47-FBF8DF5BAF4F-- .