220 12995 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Idea for new contextual keyword Date: Fri, 19 Sep 2014 10:30:56 +0300 Lines: 85 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: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1411111864 24022 80.91.229.3 (19 Sep 2014 07:31:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2014 07:31:04 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBMFX56QAKGQEXVWV3WA@isocpp.org Fri Sep 19 09:30:59 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f70.google.com ([209.85.219.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XUseg-0003nb-Ll for gclcip-std-proposals@m.gmane.org; Fri, 19 Sep 2014 09:30:59 +0200 Original-Received: by mail-oa0-f70.google.com with SMTP id m1sf3021372oag.9 for ; Fri, 19 Sep 2014 00:30:57 -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: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=bbRUSC7s3JPIWJ566YkafPz/Q9xkC7UEFDMX1aAUyDA=; b=QDZSl9dNow7qG9NfCLUqPhfrn2CME81TCvNvHXPZZlIPP7v+O6RRHFIyoEBqqGzDl7 bkurYOPBnLQeXDsaW7UQh5wdtW3jBupiZWaJeyOGkF8iSvwtKhUxG16Qb/XXDvcq89Aa ca2fjP5Q/rUk2QcRLMdRhmLib+Y0iD2XTdaKjIt1p7yjh9UnyKvqzf8USs94RWH+yZhJ pRd11Zy59tTHIjCHDRMRV1s1vaqN6pEX/vGtqelX72p/uX2w0Ow9+u5xY/wh9PL+qAiF 97ZgFjJ4r60/CTWY8KF8UDbw6D5KMt8oR7aXpLeoqBQIHPyA59CXvUGNJqf2yHPh0dUX v95Q== X-Gm-Message-State: ALoCoQmpQ0MrOwXC7qRVAbiw6nKsbDGLPaHD+5WQkybm0RdhKhjtANfONdnIGrWNljvOxE2A3hPC X-Received: by 10.50.66.234 with SMTP id i10mr26555846igt.5.1411111857737; Fri, 19 Sep 2014 00:30:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.52.137 with SMTP id t9ls942316obo.64.gmail; Fri, 19 Sep 2014 00:30:56 -0700 (PDT) X-Received: by 10.182.65.65 with SMTP id v1mr6519988obs.58.1411111856595; Fri, 19 Sep 2014 00:30:56 -0700 (PDT) Original-Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [2607:f8b0:4003:c06::22b]) by mx.google.com with ESMTPS id s10si1355724oei.25.2014.09.19.00.30.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Sep 2014 00:30:56 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:4003:c06::22b as permitted sender) client-ip=2607:f8b0:4003:c06::22b; Original-Received: by mail-oi0-f43.google.com with SMTP id v63so1236538oia.2 for ; Fri, 19 Sep 2014 00:30:56 -0700 (PDT) X-Received: by 10.182.60.98 with SMTP id g2mr6599832obr.6.1411111856379; Fri, 19 Sep 2014 00:30:56 -0700 (PDT) Original-Received: by 10.76.151.196 with HTTP; Fri, 19 Sep 2014 00:30:56 -0700 (PDT) In-Reply-To: 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:4003:c06::22b 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:12995 Archived-At: On 19 September 2014 04:48, Leor Zolman wrote: > 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. It's referring to a language design facility where a design decision in a piece of code restricts what design decisions other pieces of code can make, especially facilities where a design decision in a base class restricts the design decisions derived classes can make. Virtual functions are 'viral', especially destructors. Final member functions are 'viral'. Virtual bases are 'viral'. This 'invariant' would also be, in the same sense. >> 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 > 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 Yes, in the sense that a virtual function would not establish a similar invariant. The question is, then, whether allowing the same keyword (whichever it may be) on virtual functions as well is confusing and/or wrong, or whether it's perhaps the right thing to do. :) > 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 This sort of hiding is an "escape hatch". Code like in my example is sometimes (I bet not too often) used to change an interface of a function in a class hierarchy. Several design guideline authors like Meyers recommend against doing it, but sometimes it may be necessary, especially in cases where the base classes in the hierarchy are not easily modified (they may be part of a library that can't be modified for various reasons). > 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 Not necessarily in any way. While we were considering being able to mark deliberate hiding functions, (see, for example, http://open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3206.htm) we thought it correct that a using-declaration would turn off facilities that would diagnose the hiding cases. Perhaps we would want to do the same here, for 'invariant' and/or 'nohide'. That way the decoration in the becomes less 'viral' since its effects can be turned off. > 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. That's a nice idea, but such designs where derived class authors have no chance to state that they really really really _need_ to muck things up do not always work well in practice. The whole facility becomes more palatable if it's a "diagnose by default, people who know what they are doing can turn off the diagnostic" rather than "establish a strict rule that cannot be escaped". See the paper linked above. The hiding control that was considered at that time was not at all 'viral', it was pure opt-in for people who want checks additional to what the language traditionally provides. This proposal of yours is fundamentally less opt-in, although it can be made more so. Also consider that there are existing ways to make sure the invariant over class hierarchy cannot be broken - you can detect it with tests, for example, or you can static_assert (in the base class) that the types of the addresses of B::f and D::f are the same. -- --- 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/. .