220 9914 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: auto variable templates? Date: Wed, 19 Mar 2014 12:39:24 -0700 Lines: 278 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: multipart/alternative; boundary=047d7b5d84ef59c27d04f4facf5a X-Trace: ger.gmane.org 1395257961 18088 80.91.229.3 (19 Mar 2014 19:39:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 19:39:21 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBB3PEU6MQKGQEOQF57AI@isocpp.org Wed Mar 19 20:39:27 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 1WQMKk-00074R-PO for gclcip-std-proposals@m.gmane.org; Wed, 19 Mar 2014 20:39:27 +0100 Original-Received: by mail-qc0-f200.google.com with SMTP id i17sf21728631qcy.11 for ; Wed, 19 Mar 2014 12:39:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender: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=aI3HwNFbQ7EydRRs0nWRCKvJxdwRvmnPBX8ZdpjcGhI=; b=gSGQdjOxOQeYVYM4WLL1k0T2HjdUxqvu7yRAmaguO2gm5cDQGjUPLp+db9ZYdqYnuH gUMNk94o3KbjcC8bWkvzEnYkgWn9p+y0RoXhcOiLKoHJ1KmQRU8tXszbk3YvQIwEFUn5 0l3pHHZFGAN2vR/0z+7ZlnEamICgNqovivcO87tJ1/wxjTDqyqFnJjPRAtTAj5P60ioJ OoiDWpCc4dJSaHbpjxAIQpVBCzeMynCtCvXOUIeiFTy1MS/c4bTfsJRKwN39Ypbh9qg8 nucL6acv6MD8qMVJzIVzG7ZBUFrWk7MFpZz+0KegYuG169LkCljjBg6uk8+Mp7UfEjpE 3Nng== X-Gm-Message-State: ALoCoQmJC5EVN6jicbdGNkWgq3NfPcmZapVvgqxvm7cE1s19rvclmEejjeH6XEUunLSpyM50Srau X-Received: by 10.58.154.228 with SMTP id vr4mr6060629veb.0.1395257965816; Wed, 19 Mar 2014 12:39:25 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.88.203 with SMTP id t69ls2754845qgd.87.gmail; Wed, 19 Mar 2014 12:39:24 -0700 (PDT) X-Received: by 10.58.132.228 with SMTP id ox4mr247033veb.54.1395257964863; Wed, 19 Mar 2014 12:39:24 -0700 (PDT) Original-Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [2607:f8b0:400c:c01::22b]) by mx.google.com with ESMTPS id fn10si3040118vdc.99.2014.03.19.12.39.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 12:39:24 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c01::22b as permitted sender) client-ip=2607:f8b0:400c:c01::22b; Original-Received: by mail-ve0-f171.google.com with SMTP id cz12so9350451veb.2 for ; Wed, 19 Mar 2014 12:39:24 -0700 (PDT) X-Received: by 10.58.154.10 with SMTP id vk10mr31635175veb.18.1395257964608; Wed, 19 Mar 2014 12:39:24 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.58.218.131 with HTTP; Wed, 19 Mar 2014 12:39:24 -0700 (PDT) In-Reply-To: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c01::22b as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@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:9914 Archived-At: --047d7b5d84ef59c27d04f4facf5a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 19, 2014 at 12:26 PM, Johannes Schaub < schaub.johannes@googlemail.com> wrote: > 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. I agree that the standard is unfortunately imprecise here. In *template-declaration:* template < *template-parameter-list* > *declaration* it's not really meaningful to ask whether the template has valid specializations if the *template-parameter-list* is ill-formed. If we assume that an ill-formed *template-parameter-list* implies that there are no valid specializations (which seems like a reasonable assumption to me), then the existing rule works, but a normative statement of something along these lines would be useful. Are there problematic cases outside the *template-parameter-list*? -- --- 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/. --047d7b5d84ef59c27d04f4facf5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 19, 2014 at 12:26 PM, Johannes Schaub <schaub.johanne= s@googlemail.com> wrote:
2014-03-19 19:17 GMT+01:00 Gabriel Dos Reis = <gdr@axiomatics.org>:
> Johannes Schaub <schaub.johannes@googlemail.com> writes:
>
> | it is
> | important whether or not it will be part of the specialization of th= e
> | 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 "templ= ate<params>
decl". If "decl" is non-sensical, then we don't have a d= eclaration 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 anyt= hing
> | 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 n= ot be
> | > | generated for the class template, since the specialization is= valid.
> | > | However, clang complains
> | > |
> | > | "main.cpp:5:13: error: 'type' is a private membe= r 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 o= f whether
> | > it can have a specialization) uses an inaccessible name.
> | >
> |
> | I understand that the example I gave is intended to be ill-formed. T= he
> | 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 no= t 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 r= ule.
> |
> | 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&#= 39;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 somethi= ng 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 explaine= d 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)

=A0 =A0 template<typename T> 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.

I agree that the standard is unfortunately imprecise here. In
<= div>
=A0 template-declaration:
=A0 =A0 template < template-parameter-list > declaration

it's not really meaningful to ask whether the templ= ate has valid specializations if the template-parameter-list is ill-= formed. If we assume that an ill-formed template-parameter-list impl= ies that there are no valid specializations (which seems like a reasonable = assumption to me), then the existing rule works, but a normative statement = of something along these lines would be useful.

Are there problematic cases outside the template-par= ameter-list?

--

---
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>.
--047d7b5d84ef59c27d04f4facf5a-- .