220 34988 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Andrew Hunter' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Contra P0722R0 "destroying operator-delete" Date: Tue, 17 Oct 2017 12:39:58 -0700 Lines: 87 Approved: news@gmane.org Message-ID: References: <89c7d198-0eec-4099-ba31-bad92706ebae@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1508269218 29496 195.159.176.226 (17 Oct 2017 19:40:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 17 Oct 2017 19:40:18 +0000 (UTC) Cc: Richard Smith , "ISO C++ Standard - Future Proposals" To: "Arthur O'Dwyer" Original-X-From: std-proposals+bncBCOJLR4WVMJRBD5ZTHHQKGQE2CNCGGI@isocpp.org Tue Oct 17 21:40:12 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e4XiU-0004l1-1l for gclcip-std-proposals@m.gmane.org; Tue, 17 Oct 2017 21:39:54 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id r15sf2581587ith.18 for ; Tue, 17 Oct 2017 12:40:01 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1508269200; cv=pass; d=google.com; s=arc-20160816; b=qtIdbmouSGwualbTvehruyOfD2ezs/LWGm7pqScZwdH4fB19rTTbdrGbqyiWT+1HQV TF9uzbo9c7F/krpPTiH6u+2sIxAOzCCJ4qGlQnCYJUZD6FqdU7EKVMROoLAJk57ag0AL qIahdFtIRbU+SYogdLI8LTEfS8Dxx4hPvfoxX5ksQQpwhBmPG0g5WimBC07AS+mN7epQ 0R2A/G4HpGbThVwUm1WFOn13kVSLejKBHsl0FGbKZWXPOF7EtLmoTkj/uiqnilB9yxop PORFZoWPaM1+vN1A6aw38yXZIk08cRP068oC+evVVLnfrEmGCQY3Mjpx2YeNv+9POph4 xqwA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:cc:to:subject:message-id :date:from:references:in-reply-to:mime-version :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=7INlYpJKxYihp0OO0aOHlhYOqlekgQjbezIFbCJGyHg=; b=gHERQpRMRgCEDxo/XrG3Q+5wBA9/EToCABvP7Iy82Z7Fpf0LwhVClxaiYHR+w+QxPu VJDDPI9XlWEr5abU03424P1Erug9SjOojGhZLc7GJOmU6AVhfDZsa472cKs0Qdnsr/11 QISphzur1Iey/7spafb8cVeJgpwZew1hzQyEmmLL0KrDPKpxkCS8MewiAPqXjYmbB6ZV PKEBU1QstEBhFen63BOCNTwZsBxc/4eNncJ5fg9/41xV0P2WoOVeVvF2GaqGfMl1py09 07h0khMBd/D7pRhMW7mR2MVthBV05tlNug7e0FJh0cnU9R9kp0YpJ55Ztd0kBoU6by/d Sywg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dImxz3Zx; spf=pass (google.com: domain of ahh@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ahh@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=7INlYpJKxYihp0OO0aOHlhYOqlekgQjbezIFbCJGyHg=; b=daYJnCTpbAHFTU/h17+Ef8F5rHE0VsL8ctzCkhadFiHOzvERP/1o8BKmknUjPojGN0 /URgNkDYny2RB3ViCTvGqIVnOKXEaeEzr6O1LXvqn/FhjIBfvsbHVh4Y/lKQU89O5HaB NxL4Ugv6QEQjKpgbrVy2Bim81pGMF2nlObGS1LxujxBOJiA4aWlk8BWDhx567SMxRuVY J5DlUzJyOHIVBFTZoChYO17iJccbGGNDmMSZU3AaoA55qJGcsS9vLZImOh4tykqCZYpB n87/dgAIlIHoPdM06YaoeiVG5wiBXgly5G5VL+gqe34lEXJmJ0WCngYqynACWN/KS08x +QMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=7INlYpJKxYihp0OO0aOHlhYOqlekgQjbezIFbCJGyHg=; b=EfbK7imZ/L3mbD5ov7srsiBD8P3AaGEo+6Us27EqmKvZ/TdqSjR5kCdpaUaHxqtUNy AcHyLt7fahf5sDsmLLcycjlFmhyqqV9MZyRU9lIYSI3/NLTbfMkjzdgKpNRQ0Y8yGsS0 ctR9SpsRwj3HfSUw7cPwqxJKWHztDsQqgOF2TOoXQNyWx/ocUgGFGkCGpaCuGW7jV2i1 PcBGDVIoiyUocbDFVm60LnO7n9NlIX2pj62IsjJzX9jMUkDk4ILEiJhhXTlDez71QDhU bYllJl8Qq4Ax09Y17GnbvQ+pDXn5O4GJ+TajIPorO59qgnuOWkIf/E/FnKliOcOuET/Q NLZg== X-Gm-Message-State: AMCzsaWt7rxKaT8I9ODrssu3F3uZ8w1q8j6ykRJbeO/2U2ZZ+wlaWpfd tk8un7P0ZglwfmZ71SDba8E= X-Google-Smtp-Source: ABhQp+SGHZx3gPkrFWoeCwteDiJNEVqyJfxN1TwEGvaUPt+79iBTnxGonMhIwEFq7hPBhz91aCu1iw== X-Received: by 10.36.208.215 with SMTP id m206mr3511173itg.37.1508269200810; Tue, 17 Oct 2017 12:40:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.111.143 with SMTP id x137ls561960itb.0.gmail; Tue, 17 Oct 2017 12:39:59 -0700 (PDT) X-Received: by 10.107.201.69 with SMTP id z66mr17204545iof.118.1508269199687; Tue, 17 Oct 2017 12:39:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508269199; cv=none; d=google.com; s=arc-20160816; b=0D4p/5UxqrYFm9F1LPVn1Trh48RO36ZqvcibehJqsWJRKsEBMA0aOeXXKySAG7w4ad RcxF/JiepfCAIJWRKED18m1Ke9HaMgGndnbOJk5Kmp9AYjCUiep3FyFb9OLjIkqxRW9Z q+0xKfzjreUzNybScCZMuPHzW/0oXf6AeWrZwylqlcHe6KeMx4AFP7IoNk9ZTYg7M7FU Si4RJlQpRYovGjUHARYqCwx0KQSB0ZyTIECgexYm2wcSf1FldOF6oiB5bV8ezz5qylOE o0AVA/CLgS1sKC8hMzNOdyPgART5i30wdwJmALZ9aQvPppAzchAY3OZl44kjV5A8YXVV Q6Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; bh=+yYPw4BQaeVK0nY1c9bwYkXO2cIBsXZtTQi8jyCU+DM=; b=ym15Axo0OpO2sIIDj+A2UCjr1G0MHAz5287n3JVf8QMJkQdtE4M6xZZObUdC4OqfBh iHT30kIlsIJtA2NZJOpwokjAGKk1l/6X5jtzteLcSDIin2frRXrBPUl/g6SoGhMeUn6r dyJ6FF7DZISCtZ8bQRgLMBSumh6hK/X1ceIdOII46tVyCQumwMWqnSYnMmIlcwgzYHOk PBJPTO5xKrqQNG2mYQh4cWEg1h6oc/2SfRut+EUL6dUVN4B1F104WK7nJZwfP1NsIpMQ Hh2M2yAPPiw7hgiB30MR8P2FeuVAqKqAZ5VxHZwKYaSQsE//P0npbI5UHP8v40G4JVR2 BiWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dImxz3Zx; spf=pass (google.com: domain of ahh@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ahh@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id q18sor5956972itb.84.2017.10.17.12.39.59 for (Google Transport Security); Tue, 17 Oct 2017 12:39:59 -0700 (PDT) Received-SPF: pass (google.com: domain of ahh@google.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.36.81.21 with SMTP id s21mr7211642ita.144.1508269199156; Tue, 17 Oct 2017 12:39:59 -0700 (PDT) Original-Received: by 10.107.13.5 with HTTP; Tue, 17 Oct 2017 12:39:58 -0700 (PDT) In-Reply-To: X-Original-Sender: ahh@google.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dImxz3Zx; spf=pass (google.com: domain of ahh@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ahh@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Original-From: Andrew Hunter 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:34988 Archived-At: On Tue, Oct 17, 2017 at 11:30 AM, Arthur O'Dwyer wrote: > Yes, this is accurate. The programmer should never expect "delete > expressions" to work with objects that were not created via "new > expressions". Which programmer? Suppose I have 10,000 programmers who make use of a particular string-like class (as a matter of fact, I actually do.) There are only a very few sources of this object, but plenty of consumers. It currently uses no hanky-panky in allocation; therefore everyone happily deletes them, stores them in unique_ptr, and so on. There is X00 kLOC of code doing this. Now someone realizes that this class, on a number of hot paths, would benefit from inlining allocation as in the example. We can either rewrite every line of code, and train every programmer to only use Destroy, and enforce use of custom-deleter unique_ptrs, and ban every container that doesn't have full support for that...or we can make "delete s" do the right thing. As the paper points out, this is in fact already possible to do; defining operator delete on the type works and is well-defined. But it gives up efficiency in a sized-delete world. > Sometimes the appropriate "glue factory" is "delete p", but it should be > unsurprising that sometimes the appropriate "glue factory" is not "delete > p". I do not think this is an argument against making it possible to have that deallocation function be "delete p" where we can. > * The local choice of deallocation strategy leaks out to clients of the > code. > For example, a custom deleter must be specified when using unique_ptr, > and make_unique and make_shared can't be used any more. > > Note that the standard requires specializations of default_delete to have > the same effect as calling "delete p;", so specializing default_delete is > not > a correct alternative in C++17. We could lift that restriction, but that > would > not help for other (perhaps user-defined) resource management types that use > new and delete to manage objects. > > The last bullet and its subsequent paragraph seem to hold two competing > views of how-and-whether to extend C++. The bullet says, "We want to use > 'delete' on factory-made pointers and have it Just Work. We must change the > language to make that syntax work!" But the paragraph says, "You want to > use 'default_delete' on factory-made pointers and have it Just Work? No, > that would just complicate the language." You may be misreading that section? We are saying that without P0722 or a similar fix, it is not possible to make default_delete work, as overriding it would violate the spec. And while changing *that* rule, instead of adding the feature we propose, would solve the problem for std::unique_ptr specifically, it would do nothing for all the *other* possible users. > Whereas my attitude is "You want to use anything other than the > corresponding factory method to deallocate factory-made pointers and expect > it to work? Just say no." > I think you are perhaps not seeing the proper perspective: we are trying to widen the already large set of cases where "delete p" *is* the appropriate factory deletion method. This is already an extremely common pattern, and one with numerous advantages (the paper specifies some of them.) Remember in particular that there are many reasons where factory-creation is a useful pattern without any funny business happening on the allocation (the trivial example being creation of an object chosen dynamically from some virtual hierarchy.) Are you saying that Widget *Widget::Make(string widget_spec); is badly designed unless I always also specify Widget::Destroy? (If so, why do we have virtual destructors at all?) We simply want to be able to use delete as our "factory deallocation method" in some additional cases. -- 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/CADroS%3D7yejukTCXZT8KW-T3bouQZUU-_xxLq42vfZQsmUULP_Q%40mail.gmail.com. .