220 11112 <667b8cba-8368-426b-a592-5737ee1fbda0@isocpp.org> article Path: news.gmane.org!not-for-mail From: Douglas Boffey Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Core Issue: deleted templates Date: Fri, 6 Jun 2014 07:46:51 -0700 (PDT) Lines: 316 Approved: news@gmane.org Message-ID: <667b8cba-8368-426b-a592-5737ee1fbda0@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_531_17925646.1402066012394" X-Trace: ger.gmane.org 1402066022 8412 80.91.229.3 (6 Jun 2014 14:47:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Jun 2014 14:47:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDSIZVXVVUFBBXNIY6OAKGQEI74L6CQ@isocpp.org Fri Jun 06 16:46:56 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WsvPz-0005QN-Ol for gclcip-std-proposals@m.gmane.org; Fri, 06 Jun 2014 16:46:56 +0200 Original-Received: by mail-ie0-f200.google.com with SMTP id to1sf5476151ieb.7 for ; Fri, 06 Jun 2014 07:46:54 -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=9zbEQlxpukxncTDLbsdRfZXObD2rngz/dWvBRd2bo/E=; b=suHZdNiwDuQNiXwK60paVgjrBpoJmqTpnfAYfs/zqhP2Fwso2ov51BAupjOU7yTWhu 3uHScPRui6AxZzgypzYFi9CtejurNzmBsP5s5kCK5a8tfEqxjHJgFuv+J2G5pFvc4aWJ l8y3PqsMy6I847WtLeI2EffU/BbOXlyG8j5EgPJUYJzkwNnvdO65rmBd0iVmz7YZwUec 2oG/xwfQ47pT3Gh206Z8N3ZerAenu6GoQFa4EHqppwqt6heqXqRViSzEzIbtD7/l8dbd 7KjwZDSF1mZdyCELp6k/JPe/NtI47QZN1t+9cian/AoLOmkYTKxzCPtJKJzELOCLe87L PfBA== 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=9zbEQlxpukxncTDLbsdRfZXObD2rngz/dWvBRd2bo/E=; b=WkFp5GsGKP13fQojUy7aMfQHWRCW4d24sF5wcRWfCyk8VepH4Puqxo8/Qc7zQYqmSY I3HyYR+e/3DLNoroExRtjmRAoNSHtB7jVGggOQmrrtz6sQtG6zITlgIXyustfB2sciwO 6ru3kg1FcEyLnOJcrnbaajermeKR6KjWUqn9ZBtOsmNFk6bbXBGTK9n0sfAlkUT0qMKi M1v0sBopvhn148m7ZN/bZ4NpkMGmoMuVdJhmNxrJNTplGpQTE8IPj7LvOhEXLpVe7p6g nCiKO3c3UWUQIn/MRi2IsNXGCpbCsdqu+xpLzlWUQIvanF1EkmWZRHigjyLRR2yhFW+o AG5w== X-Gm-Message-State: ALoCoQkIu4bz4CmXIWPdGTSUQj0msyvIlUPpkarIfqgDMCwfgvmN6KohET8zIzpPhRMFATxQyHHa X-Received: by 10.182.20.195 with SMTP id p3mr2773202obe.26.1402066014650; Fri, 06 Jun 2014 07:46:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.91.201 with SMTP id z67ls757595qgd.94.gmail; Fri, 06 Jun 2014 07:46:53 -0700 (PDT) X-Received: by 10.140.27.244 with SMTP id 107mr37869qgx.18.1402066013801; Fri, 06 Jun 2014 07:46:53 -0700 (PDT) In-Reply-To: X-Original-Sender: douglas.boffey@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:11112 Archived-At: ------=_Part_531_17925646.1402066012394 Content-Type: multipart/alternative; boundary="----=_Part_532_24644067.1402066012394" ------=_Part_532_24644067.1402066012394 Content-Type: text/plain; charset=UTF-8 Latest version: -- --- 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_532_24644067.1402066012394 Content-Type: text/html; charset=UTF-8 Latest version:

--

---
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_532_24644067.1402066012394-- ------=_Part_531_17925646.1402066012394 Content-Type: text/html; charset=windows-1252; name=deletions.html Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=deletions.html X-Attachment-Id: 0e1f78db-45b8-4c92-aad1-6b70758f7396 Content-ID: <0e1f78db-45b8-4c92-aad1-6b70758f7396> Class deletions

Class deletions

Document number: Nnnnn=3Dyy–nnnn
Date: 2014–05–28
Project: Programming Language C++, Evolutionary Working Group
Reply-to: Douglas Boffey <DougABoffey@netscape.net>

Table of Contents

Introduction

Motivation and Scope

Impact on the Standard

Design decisions

Technical Specifications

Acknowledgements

References

Change Log

Introduction

This proposal is for the introduction of deleted classes, allowing th= e following class definition:

class Foo =3D delete;

This would make any further reference to class Foo an error.

Motivation and Scope

There are two problems this proposal addresses:

  1. templates that are not substantiable—sometimes, yo= u may need to create a template class, but only specialisations haave any meaning. Al= ternatively, a specialisation of a group of specialisations needs to be deleted, for example, to disallow a zero-dimensional matrix (see, for example, page 844 in [ST= RO2013]); and
  2. deprecated classes—after a class has been deprecat= ed, it may no longer be supported. This is best done by deleting it.
The notation was chosen to mirror the way functions can be deleted at= the moment.

One shortcoming is that there would be no method of indicating the re= ason for the deletion, except within documentation.

Impact on the Standard

This would allow a class definition to indicate that the class was de= leted.

Design Decisions

There are currently two methods of achieving this:

  1. not creating a class definition—this would leave the prog= rammer to write his/her own, this negates the purpose of not defining the= class; and
  2. adding a std::static_assert to the body of the cla= ss—this has the following problems:
    • having a static_assert seems to be abusing the rôle o= f a static_assert, and
    • code to indicate a class is not to be substantiated should = be part of the header, not the body of the definition.
This could alternatively be solved by adding an attribute, for exampl= e, [[poison]], but this would be changing the standard in a way that is contrary t= o the current language.

It was decided not to be able to create a pointer to a deleted class.= There are a couple of problems with allowing such:

  • such a class could never be constructor (no constructor) or des= troyed (no destructor).
  • deleted classes should not have state, but accessing a derived = deleted class through its base’s methods (whether virtual or not) would cause pro= blems.
Regarding the sizeof of a deleted class, there are three reasonable a= lternatives:
  • take its size to be the size of an empty class with the same ba= se list
  • take its size to be the size of an empty class with no base cla= sses
  • disallow a call of sizeof on a deleted class
Since it is not clear what sizeof should return, the best alternative= is simply to disallow it.

Technical specifications

A class deletion would define a class that could not be used. It wou= ld have the following properties:

  • Deleted classes can be declared any number of times, but only d= efined once (as per the ODR). [EXAMPLE: class A;

    class A =3D delete; // ok

    class A; // ok

    class A {}; // error: class deleted

    class A =3D delete; // error: violation of ODR=
    – –END EXAMPLE]
  • Deleted classes can have base classes, and only deleted classes= can derive from a deleted class. [EXAMPLE: class A {};

    class B : A =3D delete; // ok: the base class = is ignored

    class C : B {}; // error: class B deleted

    class D : B =3D delete; // ok
     – –END EXAMPLE]
  • Deleted classes cannot be substantiated or pointed to. [EXAMPL= E: class A;

    A *a;

    class A =3D delete; // error: class A in use

    class B;

    class C {
      B *b;
    };

    class B =3D delete; // error: class in use=

    class D =3D delete;

    D *d; // error: D deleted
    D d; // error: D deleted
    void fn1(D d); // error: D deleted
    void fn2(D *d); // error: D deleted
    void fn3(D &d); // error: D deleted
    void fn4(D &&d); // error: D deleted
    D fn5(); // error: D deleted
    D *fn6(); // error: D deleted
    D &fn7(); // error: D deleted
    D &&fn8(); // error: D deleted
     – –END EXAMPLE]
  • Deleted classes can be befriended. [EXAMPLE: class A =3D delete;

    class B {
      friend class A; // ok
      friend class C;
    };

    class C =3D delete; // ok
     – –END EXAMPLE]
  • Deleted classes can be aliased. [EXAMPLE: class A =3D delete;

    typedef A B; // ok: B treated as deleted
    using C =3D A; // ok: C treated as deleted

    B *b; // error: A deleted
    C *c; // error: A deleted
     – –END EXAMPLE]
  • sizeof cannot be called on a deleted class, but typeid can be. = operator new is not allowed to return a deleted class. [EXAMPLE: class A =3D deleted;
    auto s{sizeof(A)}; // error: A deleted
    auto t{typeid(A)}; // ok

    auto b =3D new A; // error: A deleted
    auto c =3D new A[10]; // error: A deleted<= br/> auto d =3D new (/* whatever */) A; // error: A= deleted
     – –END EXAMPLE]
  • Similarly, casting to a pointer to a deleted class is an error.= [EXAMPLE: – –END EXAMPLE]
  • In some instances, it may not be possible to detect violations in a single compilation unit, and such detection would need to be done at link time. [EXAMPLE: /* compilation unit a.hpp */

    class A;

    /* compilation unit a.cpp */

    #include "a.hpp"

    class A =3D delete;

    /* compilation unit b.cpp */

    #include "a.hpp"

    A *a; // error: only detectable at link time
     – –END EXAMPLE]

Acknowledgements

I would like to give thanks to everyone who has provided advice on th= e proposal website.

References

[STRO2013] Stroustrup, B. The C++ Progra= mming Language, 4th edition Addison-Wesley, 2013, p. 844

Change Log

  • 2014–06–05
    • added this change log
    • added title
    • removed all inappropriate <code> tags
    • removed the ‘unconditional=92 from the static_assert
    • made a first draft at the technical specifications
    • changed the format of the references
  • 2014–06–06
      corrected <p> tags
      changed rule for classes derived from a deleted class
      added rationale for not allowing pointers to deleted classes, u= sing sizeof on them
------=_Part_531_17925646.1402066012394-- .