220 7669 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: negated virt-specifiers Date: Sun, 10 Nov 2013 16:55:16 +0200 Lines: 114 Approved: news@gmane.org Message-ID: References: <527DC205.2040409@gmail.com> <934be6fc-f973-4682-bcc3-a6e36b26fc20@isocpp.org> <527ED9E5.8020902@gmail.com> <527EEEB2.1030102@gmail.com> <527F904C.6050205@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1384095316 14348 80.91.229.3 (10 Nov 2013 14:55:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Nov 2013 14:55:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBVF472JQKGQEFLH4RYQ@isocpp.org Sun Nov 10 15:55:20 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VfWQ3-0002Li-0x for gclcip-std-proposals@m.gmane.org; Sun, 10 Nov 2013 15:55:19 +0100 Original-Received: by mail-vc0-f198.google.com with SMTP id hz11sf232085vcb.9 for ; Sun, 10 Nov 2013 06:55:18 -0800 (PST) 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:content-transfer-encoding; bh=SiT4Vx1ICh5YIWUBx/kAXOp3VT5RCXOTb5jK8aslp+E=; b=TydIl1yP+uPwgFqEPnc0Zz3IheuNXBqvYYkfG5mNa9ppDwiEumQpwQbCT2p6YKboLm 4ngcYWS2FBKqw7iZZctSYBjL9aUXOzft7ptEP7z18XAIrIAx9iPVg+jLgPNh0ZlJH11i +Bfm19x3X1SECweltCgKjIua5Hdidv/8wEaiil9YlA4xp9jImvFAIb3Ig8EMFkchhJu6 L57Wuu7OBmHqsiQCsfA2kYf9hHIk5kZZEA9L9mZjJ760HYIzlZ+T7BGdecwGf5RmkWnR ii2ospkmWdhQ8MTc03pQ7VBs/UWrZmEZzQ9BlDyfSdFSU9CcxMPWQ3JfTxxOaNi2ka74 kGcw== X-Gm-Message-State: ALoCoQm7h6BCeyXcQjJO2tx5sug+ntpaUz0tOpi+x+U34uVgSFqY80H2CjdlKJMKG1Sojks1tbuD X-Received: by 10.58.188.113 with SMTP id fz17mr8089538vec.26.1384095318227; Sun, 10 Nov 2013 06:55:18 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.49.34 with SMTP id r2ls634614qen.7.gmail; Sun, 10 Nov 2013 06:55:16 -0800 (PST) X-Received: by 10.229.54.65 with SMTP id p1mr4868641qcg.18.1384095316555; Sun, 10 Nov 2013 06:55:16 -0800 (PST) Original-Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [2607:f8b0:400d:c01::231]) by mx.google.com with ESMTPS id q2si3511398qeu.7.2013.11.10.06.55.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 06:55:16 -0800 (PST) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::231 as permitted sender) client-ip=2607:f8b0:400d:c01::231; Original-Received: by mail-qc0-f177.google.com with SMTP id b10so1047941qcw.36 for ; Sun, 10 Nov 2013 06:55:16 -0800 (PST) X-Received: by 10.229.137.69 with SMTP id v5mr17629968qct.4.1384095316415; Sun, 10 Nov 2013 06:55:16 -0800 (PST) Original-Received: by 10.224.11.197 with HTTP; Sun, 10 Nov 2013 06:55:16 -0800 (PST) In-Reply-To: <527F904C.6050205@gmail.com> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::231 as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:7669 Archived-At: On 10 November 2013 15:55, David Krauss wrote: > > On 11/10/13 8:00 PM, Ville Voutilainen wrote: >> >> On 10 November 2013 04:25, David Krauss wrote: >>> >>> Override provides a means of expressing signature control. Either you d= o >>> or don't want to "allocate" a vtable entry. Accidentally allocating an >>> entry is the more common error, but accidentally reusing one is essenti= ally >>> in the same vein. Both result from either design confusion or template >>> interaction. >>> >> Override was, as mentioned, designed for cases where the virtual functio= n >> is already >> "allocated". > > > Yes=85 I'm not proposing to change override, but to add a flip side to it= .. I understand that. I have considered such a flip side myself. I have failed to find sufficient motivation for it. > > > >>> If nothing else, it just feels strange to go through a program and mark >>> derived class members "override" and leave bases with "maybe override, >>> maybe not" when the program would clearly be broken if they were overri= des. >>> >> Clearly? I don't think it's clear that a program is broken if a signatur= e >> is an override. >> I have practical cases where a program is broken if an intended override= is >> not >> an override, but thus far I have trouble finding the brokenness of the >> opposite. > > > Fair point. The facility is purely opt-in so it would be up to the design= er whether a class must be the root base for its interface or not. As menti= oned, I expect that collisions most likely occur with special functions suc= h as operator()() or operator int (). Are you concerned with abuse, that in= terfaces might adopt !override gratuitously and restrict users from impleme= nting valid designs? No, I'm not concerned by abuse. I fail to find why it's important to be able to say that a class is "the root base for its interface". I don't know what design that would express, nor do I know what bug it would prevent. I don't see how a virtual function= that happens to be an override is a "collision". >> We did have [[new]] as a work-in-progress attribute, as mentioned, but i= ts >> motivation remains questionable. It was meant to work as "not an overrid= e, >> doesn't hide". The "not an override" part doesn't seem very significant,= the >> "doesn't hide" is something implementations already diagnose as a >> quality-of-implementation >> facility. > The problem is that hiding a private function is still hiding. I don't th= ink that kind of facility would work without a means of preemptive hiding. = We do need something like that anyway. Module models tend I'm not sure I follow what you're saying here. > > to default to hiding private members at the module boundary. How that act= ually works, and how it should interact with virtual functions, are among t= he many hand-wavy things about modules. It has been communicated to the SG2 people already in Kona that modules can= not hide private virtual functions, since those can be overridden outside modul= es. > > > Isn't Sutter still opposed to standard attributes on the grounds that the= y're not supposed to modify program semantics? That's why overload and fina= l aren't attributes, right? > > I don't think he's opposed to attributes, he has been consistently opposed to attributes that have semantic effects, and yes, that's why override and final are not attributes. --=20 ---=20 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 e= mail 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-proposa= ls/. .