220 9906 <87r45ykq7q.fsf@euclid.axiomatics.org> article Path: news.gmane.org!not-for-mail From: Gabriel Dos Reis Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: auto variable templates? Date: Wed, 19 Mar 2014 11:17:45 -0700 Organization: axiomatics.org Lines: 129 Approved: news@gmane.org Message-ID: <87r45ykq7q.fsf@euclid.axiomatics.org> 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 1395253064 21408 80.91.229.3 (19 Mar 2014 18:17:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 18:17:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCSYNQUB2UHRBSV6U6MQKGQEMXOP3EA@isocpp.org Wed Mar 19 19:17:49 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pb0-f72.google.com ([209.85.160.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WQL3k-0002se-Cd for gclcip-std-proposals@m.gmane.org; Wed, 19 Mar 2014 19:17:49 +0100 Original-Received: by mail-pb0-f72.google.com with SMTP id jt11sf23059402pbb.7 for ; Wed, 19 Mar 2014 11:17:47 -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:to:subject:in-reply-to:organization :references:sender:date:message-id:lines:mime-version :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=FNui0nVU5PBXq0woZqXbTd8RSiCGc/FEy8D3ORVbv3k=; b=fcYcfUKG24if1NCTrU3GfpFeg7Z+lfcWE7szpbSR6afA+VYYXC2jYutuVt925Dt1Q/ NC9gmqGzyNQKK5veKC35nfAmJzypeLS0XnAStDBfBPxJoV8uxYTxidPVO0UcXDtw3W2J AuFvQh81+9E2vtUHIoGm5zfrmX9tkLpBddwi8lM7I3CULtau8K39pD8eflb/NS5qOrSF P7KA6dBqAkcm8QHvBlBI+uggb/Yemvz66Zq5K8C+bRSMhDAIGu9KBWpQGAc3glmF2AVk Md6uKLkkWyIL3YwLpgKOiR5AKjJsUdNtDehaHxfmmLYAoij/PLhL6wOgyOoz+UWAUXt3 IEyg== X-Gm-Message-State: ALoCoQmXovxX8MqytOJAlQe5tmmlv4VP7gOdovdBJ9oIq+W2tbrAdh8UgOcedx4IdtWNZkE7gt5b X-Received: by 10.66.27.132 with SMTP id t4mr15038376pag.6.1395253067253; Wed, 19 Mar 2014 11:17:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.60.228 with SMTP id k4ls1057534obr.99.gmail; Wed, 19 Mar 2014 11:17:46 -0700 (PDT) X-Received: by 10.182.87.42 with SMTP id u10mr3233301obz.22.1395253066133; Wed, 19 Mar 2014 11:17:46 -0700 (PDT) Original-Received: from mail.axiomatics.org (www.axiomatics.org. [66.228.53.191]) by mx.google.com with ESMTP id me5si18359108obb.42.2014.03.19.11.17.46 for ; Wed, 19 Mar 2014 11:17:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of gdr@axiomatics.org designates 66.228.53.191 as permitted sender) client-ip=66.228.53.191; Original-Received: from euclid.axiomatics.org (localhost [IPv6:::1]) by mail.axiomatics.org (Postfix) with ESMTP id EA5B4E741 for ; Wed, 19 Mar 2014 11:17:45 -0700 (PDT) In-Reply-To: (Johannes Schaub's message of "Sun, 16 Mar 2014 19:17:18 +0100") Original-Sender: gdr@axiomatics.org Original-Lines: 120 X-Original-Sender: gdr@axiomatics.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of gdr@axiomatics.org designates 66.228.53.191 as permitted sender) smtp.mail=gdr@axiomatics.org 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:9906 Archived-At: Johannes Schaub writes: | 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, If the parameter is non-sensical, then we don't have a template declaration. | it is | important whether or not it will be part of the specialization of the | template. If the template declaration itself is non-sensical, we don't have a declaration to specialize; do we? | 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 I am not getting why it is ill-formed. | 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. If you believe it is ill-formed, then an example that show it is well-formed would not help, right? -- Gaby -- --- 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/. .