220 25933 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: pure specifiers on function definitions Date: Wed, 18 May 2016 17:23:21 -0700 Lines: 203 Approved: news@gmane.org Message-ID: References: <1380ff95-7204-4092-afe9-a43812d355cf@isocpp.org> <5d514e26-9931-4b4f-90c9-06f3becb1386@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114ca0384d6b14053326fb29 X-Trace: ger.gmane.org 1463617404 26920 80.91.229.3 (19 May 2016 00:23:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 May 2016 00:23:24 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDVNBJG4YAIBB6MO6S4QKGQE5D5XMGY@isocpp.org Thu May 19 02:23:24 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b3BkJ-0002xf-Gi for gclcip-std-proposals@m.gmane.org; Thu, 19 May 2016 02:23:23 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id y6sf134697991ywe.0 for ; Wed, 18 May 2016 17:23:23 -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:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=mPQFwEveV8RQBqm7gFcjiVJz+blAcDKhnP2NteKXQGI=; b=meJjXJQEhq6+cegeZ0N4tEKWAhC6iUeRMFF34Dmjp/StSTY2UPomOyThqcaLvMuZYz rHC6oxYCQLB0nWbTpDvIsXvWRysg/M2vtTJRgk89S2ba8lYrg6iLV8FCtAESXEQ8NoJl JbWuy92+H8/EFeca47rLqOF8TU2vEed9g+r63yCFP3y3Jw6OOfNYogoDW2Ygfs2G//qj 2JAYpHNVWzyGL+6m/80ehxVWwQTQIvjGx4dsF62futHWhLtxQa6JK297ivDQTFUTosCs b8dHCAenbBiVQHVvqn+t/tDEA5anGjurXfck0ROBfyV93i4bdgGMVcq7UfutqmCnvkKG O7pw== X-Gm-Message-State: AOPr4FWLHhmbdi3nP/2b7gnNApx1uL6b4lIH3ly/Y8JEXDHtSWa5Fj8bxHARrJDApzFUDg== X-Received: by 10.129.157.80 with SMTP id u77mr29693131ywg.1.1463617402580; Wed, 18 May 2016 17:23:22 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.31.66 with SMTP id e60ls1380742qge.1.gmail; Wed, 18 May 2016 17:23:21 -0700 (PDT) X-Received: by 10.140.39.242 with SMTP id v105mr10491252qgv.29.1463617401771; Wed, 18 May 2016 17:23:21 -0700 (PDT) Original-Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com. [2607:f8b0:400d:c09::230]) by mx.google.com with ESMTPS id n69si3515209qke.27.2016.05.18.17.23.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 May 2016 17:23:21 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400d:c09::230 as permitted sender) client-ip=2607:f8b0:400d:c09::230; Original-Received: by mail-qk0-x230.google.com with SMTP id n63so39584521qkf.0 for ; Wed, 18 May 2016 17:23:21 -0700 (PDT) X-Received: by 10.55.4.131 with SMTP id 125mr11124359qke.86.1463617401479; Wed, 18 May 2016 17:23:21 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.237.50.36 with HTTP; Wed, 18 May 2016 17:23:21 -0700 (PDT) In-Reply-To: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400d:c09::230 as permitted sender) smtp.mailfrom=metafoo@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:25933 Archived-At: --001a114ca0384d6b14053326fb29 Content-Type: text/plain; charset=UTF-8 On Wed, May 18, 2016 at 5:13 PM, Patrice Roy wrote: > Hum. Wouldn't [[abstract]] suggest the compiler can see it as a suggestion > rather than a constraint? > Yes, a low-quality conforming C++2{ compiler could choose to issue a diagnostic when it sees the attribute and then (outside of SFINAE contexts) compile the rest of the program ignoring its presence. In exactly the same way, a low-quality conforming C++1z compiler could choose to issue a diagnostic when it sees a =0, and then (outside of SFINAE contexts) not diagnose uses of the class that are ill-formed only because it's abstract. If you don't use low-quality implementations, the problem goes away. Alternatively, you could handle it as a context-sensitive keyword like 'final'. The point is that it's something you specify on the class, not on some arbitrarily-chosen member function. 2016-05-18 19:50 GMT-04:00 Richard Smith : > >> On Wed, May 18, 2016 at 8:09 AM, Ville Voutilainen < >> ville.voutilainen@gmail.com> wrote: >> >>> On 18 May 2016 at 18:05, Nicol Bolas wrote: >>> > My feelings on the whole idea comes down to this: what does it mean >>> for a >>> > base class to define a function that is pure-virtual? What is the code >>> > trying to say about that function? Here's what I mean. >>> >>> It means that the base class doesn't want to decide how to implement >>> the functionality, >>> but can provide a helpful implementation that a derived class can call >>> if it finds that >>> implementation suitable. There are articles describing these things, >>> look for Dobbs/CUJ >>> treatise of the subject. >>> >>> > There is a use case that almost seems legitimate: pure-virtual >>> destructors. >>> >>> It's plenty legitimate if the destructor is the only virtual function >>> you can make pure. >>> Such designs occur occasionally. >> >> >> Right. But in such cases, declaring the destructor as pure virtual is a >> hack; if we want better language support for such designs, we should allow >> a class to be made abstract despite not having pure virtual member >> functions. Personally, I think committee cycles would be better spent on >> adding an [[abstract]] attribute rather than supporting virtual =0 {} >> syntax. >> >> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com >> >> . >> > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com > > . > -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnrc7_3LhamPBRSfD5crwZ%3Dx36wyp-Ss7cCGe5SDhpjZg%40mail.gmail.com. --001a114ca0384d6b14053326fb29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 18, 2016 at 5:13 PM, Patrice Roy <patricer@gmail.com> wrote:
Hum. Wouldn= 9;t [[abstract]] suggest the compiler can see it as a suggestion rather tha= n a constraint?

Yes, a low-quality co= nforming C++2{ compiler could choose to issue a diagnostic when it sees the= attribute and then (outside of SFINAE contexts) compile the rest of the pr= ogram ignoring its presence. In exactly the same way, a low-quality conform= ing C++1z compiler could choose to issue a diagnostic when it sees a =3D0, = and then (outside of SFINAE contexts) not diagnose uses of the class that a= re ill-formed only because it's abstract. If you don't use low-qual= ity implementations, the problem goes away.

Altern= atively, you could handle it as a context-sensitive keyword like 'final= '. The point is that it's something you specify on the class, not o= n some arbitrarily-chosen member function.

2016-05-18 19:50 GMT-04:00 Richard Smith <richard= @metafoo.co.uk>:
On Wed, May 18, 2016 at 8:09 AM, Ville Voutilain= en <ville.voutilainen@gmail.com> wrote:
On 18 May 2016 at 18:05, Nicol Bolas <jmckesson@gmail.com> wrote:
> My feelings on the whole idea comes down to this: what does it mean fo= r a
> base class to define a function that is pure-virtual? What is the code=
> trying to say about that function? Here's what I mean.

It means that the base class doesn't want to decide how to imple= ment
the functionality,
but can provide a helpful implementation that a derived class can call
if it finds that
implementation suitable. There are articles describing these things,
look for Dobbs/CUJ
treatise of the subject.

> There is a use case that almost seems legitimate: pure-virtual destruc= tors.

It's plenty legitimate if the destructor is the only virtual fun= ction
you can make pure.
Such designs occur occasionally.

=

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-propo= sals/CAOfiQqn-fizi4Q8tS2eSReokKasqgmB8qc9sDoo19x46V-abbg%40mail.gmail.com.

--
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-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-propo= sals/CAKiZDp3LhV-6t-zngETiGzA5dAh_n0K6FrKSbxcM41xV9SkgxA%40mail.gmail.com.

--
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.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqnrc7_3Lh= amPBRSfD5crwZ%3Dx36wyp-Ss7cCGe5SDhpjZg%40mail.gmail.com.
--001a114ca0384d6b14053326fb29-- .