220 25462 article Path: news.gmane.org!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Relocation as a solution for the valueless variant problem? Date: Wed, 6 Apr 2016 09:07:09 -0700 Lines: 48 Approved: news@gmane.org Message-ID: References: <4187538d-68fa-4582-ba26-f406479abe67@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 1459958833 1166 80.91.229.3 (6 Apr 2016 16:07:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Apr 2016 16:07:13 +0000 (UTC) Cc: isocppgroup@denisbider.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCDODCNR2QPRBLXISS4AKGQEQKFN2XI@isocpp.org Wed Apr 06 18:07:12 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f197.google.com ([209.85.213.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1anpz6-00084T-33 for gclcip-std-proposals@m.gmane.org; Wed, 06 Apr 2016 18:07:12 +0200 Original-Received: by mail-ig0-f197.google.com with SMTP id fn8sf89073656igb.1 for ; Wed, 06 Apr 2016 09:07:11 -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:sender:in-reply-to:references:date :message-id:subject:from: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=UV8i/w8ZjSXnfMkW57koSDNsGfC4X3eN0k/1fVFsKhg=; b=mvZa6n3hFE7zyybvTiAwD/ZIx1Deytz4k1gLUpswwmNGJeiBiQHBemgeW4bOVMVvPw GEbVx2Bq8L7v3/KLOCzBcgmNgLzqAYn37TyAyHEGIUkgt5nU1wFWSbpZ4BckWqWuzxvV ClVdJ9yWiq76CBf8ae3e+sFrMjASseiErHGvRTaCh+JnlvDXE7awstvdfLbhOpdf0qzn iJGiqU3Sri1kpEQzzqe7RZzlhhnA6cMgz8Wk0v0GZHsmdoAFCOCn2uwle6ZH4U8W6n+5 k1BNho/m3xw6qDDJ/3Ei0DYiq6kMuiXIC3HlHMDURw7n1XxQhYCRj2EF8kPYKGd+OsEW /Oeg== X-Gm-Message-State: AD7BkJKk7YXD3aE4fHLdC605uxN8mKKzXssNupayIWCMDzshwauYvDWcmaJHVe/tzMzsMg== X-Received: by 10.182.125.1 with SMTP id mm1mr3593481obb.9.1459958831096; Wed, 06 Apr 2016 09:07:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.88.233 with SMTP id t96ls922498qgd.49.gmail; Wed, 06 Apr 2016 09:07:09 -0700 (PDT) X-Received: by 10.31.170.196 with SMTP id t187mr11776593vke.66.1459958829802; Wed, 06 Apr 2016 09:07:09 -0700 (PDT) Original-Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com. [2607:f8b0:400c:c05::242]) by mx.google.com with ESMTPS id l62si767797vke.71.2016.04.06.09.07.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Apr 2016 09:07:09 -0700 (PDT) Received-SPF: pass (google.com: domain of sean.middleditch@gmail.com designates 2607:f8b0:400c:c05::242 as permitted sender) client-ip=2607:f8b0:400c:c05::242; Original-Received: by mail-vk0-x242.google.com with SMTP id e185so7943092vkb.2 for ; Wed, 06 Apr 2016 09:07:09 -0700 (PDT) X-Received: by 10.176.0.8 with SMTP id 8mr7417620uai.67.1459958829457; Wed, 06 Apr 2016 09:07:09 -0700 (PDT) Original-Sender: sean.middleditch@gmail.com Original-Received: by 10.159.41.103 with HTTP; Wed, 6 Apr 2016 09:07:09 -0700 (PDT) In-Reply-To: X-Original-Sender: sean@middleditch.us X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of sean.middleditch@gmail.com designates 2607:f8b0:400c:c05::242 as permitted sender) smtp.mailfrom=sean.middleditch@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:25462 Archived-At: On Wed, Apr 6, 2016 at 8:48 AM, wrote: > Types with throwing move constructors are prime candidates to have a > relocator, because it solves a problem specific to them. A relocator can be > implemented trivially, without changing the design of a non-nullable type > like the particular std::list implementation. It would not require changing > the fundamental design of the type, which implementing a noexcept move > constructor would require. > > For user types, relocators would be implicitly defined by the compiler, > under much the same terms as a move constructor. > > I'm not seeing a plausible usage case where you would want a type to have a > throwing move constructor, and not implement a relocator. It seems plausible > this combination could be unsupported. Much existing code simply wouldn't support relocation properly until someone went in and wrote the relocator functions. You can't generate correct relocations for all types, e.g. those with non-trivial move constructors that do who-knows-what. Those existing types would become incompatible with variants were variant to rely on relocation. That level of requirements has so far been a show stopper for suggestions to "fix" variant. The committee can mandate that standard library types all have relocators added where necessary but it can do no such thing for user types. However, the committee _does_ want to allow variant to be used with those same problematic user types. I personally find this relocation proposal currently incomplete and in need of a lot more iteration. With your proposal, it's way too easy to accidentally leave some object in an undefined state where the compiler has no idea and is stuck calling the destructor anyway. All it takes is passing an object via pointer to some function and *bam* insta-pain, as the caller has no way to know what the function will do and the function has no way to know what the caller wanted to allow, other than comments and documentation (no compiler support for error checking). Standardizable relocation support in C++ is likely to require more work on value categories and probably some kind of new reference or wrapper type (one that cannot be very easily and accidentally bound to sub-objects or glvalues). -- 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/CALQmNFggBQSADjEqS7pEzcdPSStGJfXkJdX0d2CwW_TmwqA%3DyQ%40mail.gmail.com. .