220 9851 article Path: news.gmane.org!not-for-mail From: Johannes Schaub Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: auto variable templates? Date: Sun, 16 Mar 2014 19:17:18 +0100 Lines: 110 Approved: news@gmane.org Message-ID: References: <87y50a8tr4.fsf@euclid.axiomatics.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1394993831 6234 80.91.229.3 (16 Mar 2014 18:17:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Mar 2014 18:17:11 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCQPNCEZSQNBBLWVS6MQKGQECIG4YVQ@isocpp.org Sun Mar 16 19:17:21 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f200.google.com ([209.85.216.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WPFce-0004NK-SQ for gclcip-std-proposals@m.gmane.org; Sun, 16 Mar 2014 19:17:21 +0100 Original-Received: by mail-qc0-f200.google.com with SMTP id i17sf11150083qcy.7 for ; Sun, 16 Mar 2014 11:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from: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=xiML3O3w1gsLyrdqTzZ4SkSVC0wJhVP5TjyeboJqpwE=; b=0IPa1O6jo426oS40RKGHkCdFIIO9rsKNFqiaeMxTjv2oR2CArCdur1iiTynCnBdb2w vaS0OihTezcq9f06OoYRUIT6BUQ0JzRcWORu9UNA4HRAe6c+Y0rSWMJBT71D2SQ2mQBh 02WCJPZRZoccusajg5s94bGrK5FcdHiyucHxa7NzMmDA6jDOaIKonl6kOXmAV1WoP46a cS4N8WPtuvy0CrYr3bO6ihnSEe5ah/WAKA2EjoaTa4ln2hFGk37VdrmSy+seWVBNL8jm 2dUN3hxkpOftnpbYiagRckvaADBcy+ajjC1Ju2A7zJQpXI19keOW23BD28FsCun5uLXE KJTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from: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=xiML3O3w1gsLyrdqTzZ4SkSVC0wJhVP5TjyeboJqpwE=; b=F5TDRmI0zZ/Dw13phGMulR9IVEMNAb51Ux2VJGyEtuShImYeHkul4Z/GBPWbKg1UO4 eVmAJtO3QQWfb4UqQdtAccCqhxgCvm0W7CMVdSUrADNBOsxim9EdF3IjmMYPtVSV/8/h lVHhepfVIH0RRbXe/kly5iUr0pDQ3Us906+KLMTK/UprD3vOjFI6os6i+VwYfkA6/XrE AWPD7H/1e6k+xLwlSiAjd2HBfxusR38FZs62sZdj3GEpa8kU6jzT6/GONHFkaRyFB4u6 7NFTZCCiIPmfFZMMVnqVxfgWD/Y5iQbM3+QyHSkp62GJtMGKQjEohWr8t9A5u8icDjoi EDEg== X-Gm-Message-State: ALoCoQk1Pe7UyhPjnA4A1leoYZ1AcV8MgvQDjB84THInsEG6KzivCfgsG4na/drM+kZNm41Xk/Ji X-Received: by 10.236.27.33 with SMTP id d21mr807325yha.23.1394993840075; Sun, 16 Mar 2014 11:17:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.138.66 with SMTP id qo2ls755307igb.43.canary; Sun, 16 Mar 2014 11:17:18 -0700 (PDT) X-Received: by 10.66.148.134 with SMTP id ts6mr21156667pab.113.1394993838520; Sun, 16 Mar 2014 11:17:18 -0700 (PDT) Original-Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [2607:f8b0:400e:c01::233]) by mx.google.com with ESMTPS id ha5si11968366pbc.150.2014.03.16.11.17.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 11:17:18 -0700 (PDT) Received-SPF: pass (google.com: domain of schaub.johannes@googlemail.com designates 2607:f8b0:400e:c01::233 as permitted sender) client-ip=2607:f8b0:400e:c01::233; Original-Received: by mail-pb0-f51.google.com with SMTP id uo5so4750878pbc.38 for ; Sun, 16 Mar 2014 11:17:18 -0700 (PDT) X-Received: by 10.68.237.228 with SMTP id vf4mr3811584pbc.131.1394993838357; Sun, 16 Mar 2014 11:17:18 -0700 (PDT) Original-Received: by 10.68.216.97 with HTTP; Sun, 16 Mar 2014 11:17:18 -0700 (PDT) In-Reply-To: <87y50a8tr4.fsf@euclid.axiomatics.org> X-Original-Sender: schaub.johannes@googlemail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of schaub.johannes@googlemail.com designates 2607:f8b0:400e:c01::233 as permitted sender) smtp.mail=schaub.johannes@googlemail.com; dkim=pass header.i=@googlemail.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:9851 Archived-At: 2014-03-16 8:53 GMT+01:00 Gabriel Dos Reis : > Johannes Schaub writes: > > | 2014-03-16 1:17 GMT+01:00 Richard Smith : > | > On Sat, Mar 15, 2014 at 5:13 PM, Johannes Schaub > | > wrote: > | >> > | >> 2014-03-16 0:38 GMT+01:00 Richard Smith : > | >> > On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos > | >> > > | >> > wrote: > | >> >> > | >> >> Is the following supposed to be ill-formed according to the current > | >> >> draft? > | >> >> > | >> >> template constexpr auto X = 42; > | >> >> > | >> >> int main() > | >> >> { > | >> >> static_assert(X == 42, ""); > | >> >> } > | >> >> > | >> >> > | >> >> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in > | >> >> namespace-scope, but doesn't explicitly say in variable templates - > | >> >> consequently this is ill-formed. > | >> > > | >> > > | >> > A specialization of a variable template is a variable, so this is > | >> > allowed. > | >> > > | >> > | >> I don't understand this reason. The following is not a specialization > | >> of a variable template, is it? > | >> > | >> template constexpr auto X = 42; > | >> > | >> The Standard says in 7.1.6.4p6, "A program that uses auto or > | >> decltype(auto) in a context not explicitly allowed in this section is > | >> ill-formed." > | >> > | >> The section does not explicitly allow "auto" for variable templates. > | >> Why does it matter that the specialization of that template is a > | >> variable? > | > > | > > | > Because the validity of a template isn't governed by the usual language > | > rules. 14.6/8: "No diagnostic shall be issued for a template for which a > | > valid specialization can be generated." > | > > | > | It's also not clear to me where to draw the line. Consider > | > | class Y { > | typedef int type; > | }; > | > | template > | struct X { }; > | > | The specialization of this template does not have template parameters, > > I don't understand why this particular observation is important. Could > you elaborate? > Since the template parameter is what is being ill-formed, it is important whether or not it will be part of the specialization of the template. If it is part of it, the specialization will be ill-formed. If it is not part of it, the specialization doesn't contain anything that is ill-formed, so I would conclude that the specialization will be well-formed and so because "a valid specializaion can be generated", no diagnostic shall be given. > | since it's a normal class. A diangostic should therefor not be > | generated for the class template, since the specialization is valid. > | However, clang complains > | > | "main.cpp:5:13: error: 'type' is a private member of 'Y'" > > The issue here is different: it is the declaration itself that is invalid > in the sense that the declaration of the template (regardless of whether > it can have a specialization) uses an inaccessible name. > I understand that the example I gave is intended to be ill-formed. The intent seems to be something like this: If the rule violation that would render the template ill-formed appears as part of the "declaration" of the template-declaration, then this is not really an error, as long as a valid specialization can be generated for it. Or perhaps even this still doesn't capture the real intent of the rule. In my example, the rule violation appears not as part of the "declaration", but outside of it and hence the template is still ill-formed. But this isn't at all stated by the Standard, or I'm just blind and can't read. I guess what I would like is an example in the spec that shows what is meant by it. Perhaps the example above with the access error (or something better), and the example with "auto" (or something better). That would avoid misunderstandings in the future. -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. .