220 37130 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Use of "implement" when overriding a virtual method that does not have an implementation, yet. Date: Wed, 28 Feb 2018 15:09:27 -0800 (PST) Lines: 187 Approved: news@gmane.org Message-ID: References: <8462ee66-9e9a-4579-8246-64861bf4a349@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6742_1749788284.1519859367945" X-Trace: blaine.gmane.org 1519859248 13149 195.159.176.226 (28 Feb 2018 23:07:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2018 23:07:28 +0000 (UTC) Cc: cristian64@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBKHN3TKAKGQENO4RFMA@isocpp.org Thu Mar 01 00:07:24 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erAol-0002td-Tq for gclcip-std-proposals@m.gmane.org; Thu, 01 Mar 2018 00:07:24 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id q192sf2317384vke.19 for ; Wed, 28 Feb 2018 15:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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; bh=zqmilNVNtH6Gu2Yn/NT09fW+DgNIkLihXj85PdFhGTM=; b=eSLKlMafvBHW8EunOj+cdRQLdSZKZLlWfeNjvJAKiw4ALiQPk8RsPifu3pJhYIvC/V 3qfgGqMnlLSWy+2EWq7TkUmTKcZf7Qq86Qg3Li3SFvVOLoZe35RhjucHYpCd6YBwZXMz mROoZ+EQxowKGgF+VZZlkxWcsFDgZ/RAWedPQ7tY2ys3vUG/9mW0OQxZWKNLOsiiqOXS 7zPHBJsWBSgPiO2h38AVuPOfeDjwrcufZsdKE6/YxZVvrvZ9BlYTAvpdJ+SSkbsuY0+W 2eaL+mYMxcRk3uHqEJ6P4IPoppyY0SV9bLvrqVnfcgGOG+WuzuRnn0LkeKmnfMzeOcI7 3mRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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; bh=zqmilNVNtH6Gu2Yn/NT09fW+DgNIkLihXj85PdFhGTM=; b=qFxNdseEk75XidCZvQWQrk1pe81Zbyorf6EKtHcShyv347u8AckHCMGNAhOC/35TA9 yr/h8C8Gh8yrvpNXTEvsxMYB9cG2scQE0JWGO0yAqTB/QaV3LFTYDBMMjk9b4AYVlHhw ZUrSBeSkMPD1VhfkSq7B/ljQUyU6FL9CffaCwkws+0Q43kfipbEj0NwEA+4uxoFHdeNL ct8OGJHLRjL9S3+XJrTKqOydXvlAeDXtHAS3p0B2HsZZjLADJfe8x8Tft8+ANJOYXHsN lZoHJcWSm5pKWTPa+m0GgIkXJqltme1FJPTqg9iKZ9uYO8Pii82k9YYIBCXV5GtZKb1K aznw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=zqmilNVNtH6Gu2Yn/NT09fW+DgNIkLihXj85PdFhGTM=; b=AaG1IJV5y6r1V0U9h15xqV0w52y1/mmlM2bEGk/So4TrYQ5moOjM3z21GuuqKXy3SF 8AQMOxGhM7pTDNusrY3QgX3P9A83uJPTCoA4W34zW4/Cgl6jPlmV5BKdTPzfdtKni7ce 31jfRHFaLaaNL6cEHJvc5bJYrUHV6BBlCDJKOk/bWBQCzSdQdTTfOTDMMaMM8NWuHAWv lvgOaEbFGXP+Uuvy87pdZTi76ne3sIM3Ltxtoe0z9eZN89Svqw4erx8lrqOsDToBT/In 23E3vvADBm3KD+hDShQVqHBBJn+S141kyyEXE4gfABe7tpBZnhg0A6aU2XgoSHiGmxp7 L8Cw== X-Gm-Message-State: APf1xPC4+Dd2qVCJ7aExqjaV602ElX2Btl+SYzC9OSKy+lJOgyyY5TaM E/e34tXceNGuAFObmkWzxprh6A== X-Google-Smtp-Source: AG47ELtO5/Xo37IJMR3tmlUp/sdemE2Astd9a3tKox5gG4vCQlCiFDa8McvJDVjBHBRfuy70db4uGw== X-Received: by 10.176.5.67 with SMTP id 61mr9431321uax.88.1519859370127; Wed, 28 Feb 2018 15:09:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.146.138 with SMTP id u132ls2847451vkd.13.gmail; Wed, 28 Feb 2018 15:09:28 -0800 (PST) X-Received: by 10.31.48.198 with SMTP id w189mr2072109vkw.1.1519859368541; Wed, 28 Feb 2018 15:09:28 -0800 (PST) In-Reply-To: <8462ee66-9e9a-4579-8246-64861bf4a349@isocpp.org> X-Original-Sender: jmckesson@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:37130 Archived-At: ------=_Part_6742_1749788284.1519859367945 Content-Type: multipart/alternative; boundary="----=_Part_6743_123117070.1519859367946" ------=_Part_6743_123117070.1519859367946 Content-Type: text/plain; charset="UTF-8" On Wednesday, February 28, 2018 at 5:04:42 PM UTC-5, crist...@gmail.com wrote: > > Pretty often I find myself wanting to declare a method as *implement*, as > opposed to using *override*. > > Here an example: > > #include > > class A > { > public: > virtual ~A() {} > virtual void foo() { std::cout << "A::foo" << std::endl; } > virtual void bar() = 0; > }; > > class B : public A > { > public: > void foo() override { std::cout << "B::foo" << std::endl; } > void bar() implement { std::cout << "B::bar" << std::endl; } > }; > > It helps readability. The use of *override* implies that an implementation > already exists and is going to be overridden, which is not the case for > *A::bar*. > *implement* would just fit in this case. > OK, the point of the `override` special identifier was to allow the compiler to complain if there was no matching base class `virtual` function that is being override. Without the keyword, if a base class virtual function signature is changed without modifying all of the derived class overrides of it, the compiler will still compile successfully despite being broken logically. With the keyword, that becomes a hard error. The lack of a hard error represents a real problem that real people encountered in real code. So, what "real problem" is being solved by using "implement" instead of "override"? Is a function that uses "override" on a pure virtual function genuinely *broken*? If not, then this is simply a matter of notation. On the other hand, *implement* would become a reserved keyword of the C++ > programing language. > "`override`" isn't even a reserved keyword of C++. It's a special identifier; it only takes on special meaning when used in exactly one place. And I really wish C++ had more special identifiers. -- 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/b1ee2c48-dba3-4553-9743-62908c6d9adc%40isocpp.org. ------=_Part_6743_123117070.1519859367946 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, February 28, 2018 at 5:04:42 PM UTC-5, crist= ....@gmail.com wrote:
Pretty often I find myself wanting to declare a method as imple= ment, as
opposed to using override.

Here an example:
<= span style=3D"color:rgb(136,0,0)">#include <iostream>

class A
{
public:
=C2=A0 =C2=A0 virtual ~A() {}
=C2=A0 =C2=A0 virtual void foo() { std::cout <= span style=3D"color:rgb(102,102,0)"><< "A::foo" << std::endl; }
=C2=A0= =C2=A0 virtual void bar() =3D 0;
};
=C2=A0
class B : public A
{
public:
=C2=A0 =C2=A0 void foo() <= span style=3D"color:rgb(0,0,136)">override {<= span style=3D"color:rgb(0,0,0)"> std::cout << "B::foo" <<= std::endl; }
=C2=A0 =C2=A0 void bar() implement { std::cout << = "B::bar" <&= lt; std::endl; }
};

It helps readability. The use of override implie= s that an implementation
already exists and is going to be overridden, w= hich is not the case for A:= :bar.
implement would just fit in this case.
=

OK, the point of the `override` special identifier wa= s to allow the compiler to complain if there was no matching base class `vi= rtual` function that is being override. Without the keyword, if a base clas= s virtual function signature is changed without modifying all of the derive= d class overrides of it, the compiler will still compile successfully despi= te being broken logically. With the keyword, that becomes a hard error. The= lack of a hard error represents a real problem that real people encountere= d in real code.

So, what "real problem" is being solved by= using "implement" instead of "override"? Is a function= that uses "override" on a pure virtual function genuinely bro= ken? If not, then this is simply a matter of notation.

On the other han= d, implement would become a reserved keyword of the C++
programin= g language.

"`override`" isn't= even a reserved keyword of C++. It's a special identifier; it only tak= es on special meaning when used in exactly one place.

And I really= wish C++ had more special identifiers.

--
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 https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/b1ee2c48-dba3-4553-9743-62908c6d9adc= %40isocpp.org.
------=_Part_6743_123117070.1519859367946-- ------=_Part_6742_1749788284.1519859367945-- .