220 12989 article Path: news.gmane.org!not-for-mail From: Leor Zolman Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Idea for new contextual keyword Date: Thu, 18 Sep 2014 18:48:46 -0700 (PDT) Lines: 166 Approved: news@gmane.org Message-ID: References: <2ff42d9d-16df-4040-8ae1-0a17d4f78d97@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2353_1503115465.1411091326401" X-Trace: ger.gmane.org 1411091335 24712 80.91.229.3 (19 Sep 2014 01:48:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2014 01:48:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDMMPPEW7UBRB74W52QAKGQETCSJBNA@isocpp.org Fri Sep 19 03:48:49 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f71.google.com ([209.85.219.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XUnJY-0005id-N8 for gclcip-std-proposals@m.gmane.org; Fri, 19 Sep 2014 03:48:49 +0200 Original-Received: by mail-oa0-f71.google.com with SMTP id jd19sf10330290oac.2 for ; Thu, 18 Sep 2014 18:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=mfrBpnuwUZCBH7WPodgPYXn8vFXjABEDl14mOaMc68c=; b=A8eyPe8pwMUuZZ17yH331mOM3639DB5XLSqsCIT0W4E5+pFI+IM6YrpJQ7alz7gIcy xSMq3cr6jvVmZKdGgLOYcl0OPMyHC98YSB9rWQXpXWu0KIZD2J7jCF3sengFFJV0jUe1 kPr8ONzC+ooP82djTpYAuh5lzE2WLqxWgEXnb3kzGr/k3Z0+djJmmGmYSkYYBkDWgdzG gv7Sd2eQmqKyixpaL40zLFTUFUcxJ+rvi7iikzeWUp8n5unA+tk7XROnOAwPGiFH+Xcf sNtYw6lnXLZ/1WF2Lr/vwV5P1qcjMcww06uV/+u2POK46HoLVN8mQexGpVtF4fIdXRwl WsEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=mfrBpnuwUZCBH7WPodgPYXn8vFXjABEDl14mOaMc68c=; b=krgtLd8AyTMPqimuRLGKvOP6/As215dbF+LqKKFsi2dHS4vLbrtLyLre7QCt9BpevF 26I11IH3DBNSVCSTxhJRDmWa4s02toFX5l4Ihp0u5faaPTTWTboGPIJzYPejTfC6XGXz +glwNo+RC+mwA9vwkdJyJiHbSG/4yUZNBvT/ihR7bk7l/ZuLaEOyH9LMEOUP1UusFsb/ 6g2Go7Bwx4YRazwCSL1Mz67VlsJdp3AlNQuEtmGeQBx3I9VYT5iKHSGrOB7+fPJ0Y4qE oBCGi6BhF8sKJnEbUBGDo44PT2ePOH3fGlu8OHbEwuIH2gcVgeI/r2d3ogVNJM7JxjSJ TtCQ== X-Gm-Message-State: ALoCoQnFd7qDpO8xBzgErb79NPpZL7WpobW2azVMhdu7DP/hxWnyIq+wTT2ElB92jw9t5ol84k9+ X-Received: by 10.50.112.68 with SMTP id io4mr30363644igb.0.1411091327773; Thu, 18 Sep 2014 18:48:47 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.89.101 with SMTP id u92ls190826qgd.79.gmail; Thu, 18 Sep 2014 18:48:47 -0700 (PDT) X-Received: by 10.140.37.39 with SMTP id q36mr407qgq.10.1411091326992; Thu, 18 Sep 2014 18:48:46 -0700 (PDT) In-Reply-To: X-Original-Sender: leorzolman@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:12989 Archived-At: ------=_Part_2353_1503115465.1411091326401 Content-Type: text/plain; charset=UTF-8 On Thursday, September 18, 2014 7:08:25 PM UTC-4, Ville Voutilainen wrote: > Seems reasonable. Do remember, though, that whatever decision we make > for such a 'viral' facility, it's going to be hard to change that > decision afterwards > because such changes are always breaking. For example, if we decide that > ok, the keyword applies to functions only, and to non-virtual functions > only, > it's bloody difficult to decide later that "oh, I guess it should > apply to virtual functions as well". > > OK. Can I ask you, though, to please define the term "viral" as you're using it here? I'm just not familiar with the word being used in the context of a language feature. Thanks. > > Consider > > struct B > { > virtual void f(int); > }; > > struct D : B > { > void f(double, double=0.0); > }; > > > int main() > { > D d; > d.f(5); > } > > > D::f hides B::f. The call is not ambiguous. clang warns about the > hiding, gcc does not. > For such cases, it might be very beneficial to say "do not hide in > derived classes" for > virtual functions as well. You may end up in situations where > initially there is no > D::f, but such a function is added later, and then it changes the > meaning of code > silently. Being able to say that B::f can't be hidden would protect > from such mistakes. > We may, then, actually have the need for two different keywords. My use of 'invariant' only makes sense for non-virtual functions. The other purpose would be purely to disallow any form of hiding, hence perhaps 'nohide'. This could apply to virtual functions (perhaps even non-virtual ones, to offer a superset of 'invariant' functionality) plus many other types (data members, enums, typedef/using, etc.) At this point I'd need to know the use-cases for hiding. I've never seen any (but that's more likely due to my need to get out of the house more often, rather than my necessarily thinking it's a totally pointless language capability.) If 'nohide' were to become part of the language, how would its use in a base class potentially cause grief to a derived class designer? I don't know. I'm less concerned about the use of 'invariant' on non-virtual functions... if a base class designer wants a non-virtual function to be an invariant, the derived classes should be given no opportunity to muck things up. -- --- 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/. ------=_Part_2353_1503115465.1411091326401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, September 18, 2014 7:08:25 PM UTC-4, Ville Vo= utilainen wrote:
Seems reas= onable. Do remember, though, that whatever decision we make
for such a 'viral' facility, it's going to be hard to change that
decision afterwards
because such changes are always breaking. For example, if we decide tha= t
ok, the keyword applies to functions only, and to non-virtual functions= only,
it's bloody difficult to decide later that "oh, I guess it should
apply to virtual functions as well".

 
OK. Can I ask you, though, to please= define the term "viral" as you're using it here? I'm just not familiar wit= h the word being used in the context of a language feature. Thanks.
&nb= sp;

Consider

struct B
{
    virtual void f(int);
};

struct D : B
{
    void f(double, double=3D0.0);
};


int main()
{
    D d;
    d.f(5);
}


D::f hides B::f. The call is not ambiguous. clang warns about the
hiding, gcc does not.
For such cases, it might be very beneficial to say "do not hide in
derived classes" for
virtual functions as well. You may end up in situations where
initially there is no
D::f, but such a function is added later, and then it changes the
meaning of code
silently. Being able to say that B::f can't be hidden would protect
from such mistakes.

We may, then, actually have the need for two diff= erent keywords. My use of 'invariant' only makes sense for non-virtual func= tions. The other purpose would be purely to disallow any form of hiding, he= nce perhaps 'nohide'. This could apply to virtual functions (perhaps even n= on-virtual ones, to offer a superset of 'invariant' functionality) plus man= y other types (data members, enums, typedef/using, etc.)

At this po= int I'd need to know the use-cases for hiding. I've never seen any (but tha= t's more likely due to my need to get out of the house more often, rather t= han my necessarily thinking it's a totally pointless language capability.) = If 'nohide' were to become part of the language, how would its use in a bas= e class potentially cause grief to a derived class designer? I don't know. = I'm less concerned about the  use of 'invariant' on non-virtual functi= ons... if a base class designer wants a non-virtual function to be an invar= iant, the derived classes should be given no opportunity to muck things up.=



--

---
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>.
------=_Part_2353_1503115465.1411091326401-- .