220 9912 article Path: news.gmane.org!not-for-mail From: Johannes Schaub Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: auto variable templates? Date: Wed, 19 Mar 2014 20:26:28 +0100 Lines: 106 Approved: news@gmane.org Message-ID: References: <87y50a8tr4.fsf@euclid.axiomatics.org> <87r45ykq7q.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 1395257183 8938 80.91.229.3 (19 Mar 2014 19:26:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 19:26:23 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCQPNCEZSQNBBZW6U6MQKGQEZ4ZTHDI@isocpp.org Wed Mar 19 20:26:34 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f200.google.com ([209.85.128.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WQM8G-0005Do-2k for gclcip-std-proposals@m.gmane.org; Wed, 19 Mar 2014 20:26:32 +0100 Original-Received: by mail-ve0-f200.google.com with SMTP id oy12sf22560608veb.3 for ; Wed, 19 Mar 2014 12:26:31 -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=WeB4fkzmENxga7b8OdfGcP2H5cjBK8h8xQOMNiMONnA=; b=OK6NizJ9rYpBVGhDwFpOcGx6iXoGAMq0lAO8DZyIr3hnQwq+KWQeoYM1oM/h4tgeo1 iF31vYWzestfSnY7mNPFgUdkCf9BZXZYMEH5G1uGvaUm33cCOcCfWJF3UQRpNM4RVPO4 hA8o9HGTgYzhRzvi8kuY8sioqKlqncnmQ6QwRjFFl2nII98k51HeW2yR/ZU49CE9JKvV TuuI95JS6oseUeje0/AGAcaTnRbwOgwq7c1KWa578/8zOjcPArTLiNjpVdSKrM+Rp2YC PAKQKbwwCi1RaK3At6nuaYuWXS3ywBYq5rDUKSWgWAarDkTXUy5PUcCL5lxzPLysSS2g 0qFw== 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=WeB4fkzmENxga7b8OdfGcP2H5cjBK8h8xQOMNiMONnA=; b=CX711wKg7t2FYqtBMIszML3y1zpu/7v8gXFusTSKZ+DhWmlsBV1WN2EKm8tVU66xVq 4h49OYHO68QcVGMwLKIyHNSKJ2x+teDK6Uf1b2k5wNeQRHaWA+GnKD/8LcjUrsk7IICw U/s23Ut9sSoiUMtM3/ALCvwVDwgrr66jTsoFAfHzQUBTYDSsiCV9twMWI6tepiSD1Ze5 31cKraq1o9FEcGGg5UvhoOqRqPZcf5369YfcZtGzb8C8PuhXMM97KcunRl/Ue78BkE8w 5QGD0ll9ojbsE2sic+BT2cXs9YraWHA0Pi8SNdwfI2Gwi1oYdmK7QB5zVqCO24OZBGFb ooiw== X-Gm-Message-State: ALoCoQmSqpguOWcEXRPIYSLhWX4+I1PDitNEtBkIMFN7o4VFDwNhfKYF/1MsoOO35LEn5G0Bl0eC X-Received: by 10.224.20.133 with SMTP id f5mr15312723qab.8.1395257191240; Wed, 19 Mar 2014 12:26:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.13.68 with SMTP id f4ls2640758igc.36.canary; Wed, 19 Mar 2014 12:26:30 -0700 (PDT) X-Received: by 10.68.44.71 with SMTP id c7mr42061557pbm.24.1395257190206; Wed, 19 Mar 2014 12:26:30 -0700 (PDT) Original-Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [2607:f8b0:400e:c02::233]) by mx.google.com with ESMTPS id nc6si9011276pbc.323.2014.03.19.12.26.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 12:26:29 -0700 (PDT) Received-SPF: pass (google.com: domain of schaub.johannes@googlemail.com designates 2607:f8b0:400e:c02::233 as permitted sender) client-ip=2607:f8b0:400e:c02::233; Original-Received: by mail-pd0-f179.google.com with SMTP id w10so9038069pde.24 for ; Wed, 19 Mar 2014 12:26:29 -0700 (PDT) X-Received: by 10.68.34.225 with SMTP id c1mr42489817pbj.116.1395257189041; Wed, 19 Mar 2014 12:26:29 -0700 (PDT) Original-Received: by 10.68.216.97 with HTTP; Wed, 19 Mar 2014 12:26:28 -0700 (PDT) In-Reply-To: <87r45ykq7q.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:c02::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:9912 Archived-At: 2014-03-19 19:17 GMT+01:00 Gabriel Dos Reis : > Johannes Schaub writes: > > | 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? > Right, but the same can be said about "decl" in "template decl". If "decl" is non-sensical, then we don't have a declaration to specialize. > | 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. > Because it uses "auto" in a context not explicitly allowed (the context here is a variable template). The rule that Richard quoted is intended to make it well-formed eventually, but the wording does not actually convey that intent IMO (see below). > | 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? > I don't believe anymore that it is ill-formed, after you explained the model of templates and a compiler writer (Richard) explained the model they assume the Standard to take. The sentence Richard quoted is "No diagnostic shall be issued for a template for which a valid specialization can be generated.", which is the reason that the ill-formed template isn't actually diagnosed. The next sentence is "If no valid specialization can be generated for a template, and that template is not instantiated, the template is ill-formed, no diagnostic required.". And the example that it shows is (shortened) template void g() { +; } Now, this surely is a soup of tokens, but not a template. But the sentence is intended to be applicable to this code, so it makes the "template" be "ill-formed; no diagnostic required", for the benefit of compilers that just collect a token soup when they are given a template, instead of parsing them completely. Well, this state of affairs may be tolerable, because we have an example that shows the real intent of this rule. Similar things seem to go on with th efirst sentence that Richard quotes, where an ill-formed template is required to be *not* diagnosed if certain things apply. IMO it is *not* tolerable that there is no example that shows what this is intended to mean. > -- 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/. -- --- 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/. .