220 25461 article Path: news.gmane.org!not-for-mail From: eloandrheo@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Relocation as a solution for the valueless variant problem? Date: Wed, 6 Apr 2016 08:48:01 -0700 (PDT) Lines: 95 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: multipart/mixed; boundary="----=_Part_2019_535804517.1459957682184" X-Trace: ger.gmane.org 1459957688 14316 80.91.229.3 (6 Apr 2016 15:48:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Apr 2016 15:48:08 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCNIRZ77R4HBBM67SS4AKGQELSXP7II@isocpp.org Wed Apr 06 17:48:07 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f198.google.com ([209.85.220.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1anpgb-00009L-Jk for gclcip-std-proposals@m.gmane.org; Wed, 06 Apr 2016 17:48:05 +0200 Original-Received: by mail-qk0-f198.google.com with SMTP id i123sf84023840qkd.2 for ; Wed, 06 Apr 2016 08:48:05 -0700 (PDT) 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:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=D4iwr2L9GIQ9464vPXPlPMoVb003EQCcB2QbX9O/1yc=; b=kf0EET9q8wPMLa2yXj02TrMiBln9j4Ek8tLo+1/FC5xv4bfILPITGYfUtwOwq3Zztg KNWP0wd670Jz9zcoH0bvDyV9tQ1UAAK1arlHEKZc6L3RnOzdvjPvwrk1C0r4fUYT4Ymf B9qXcYLtHSuEGRv2qUSUMlHvY7GcasC4RDICqciKyRsQabfimZ9myB8J7vLxY7vs+3IZ jHNAbMBZFepTUphdWQGBCbiKV8OPM37eSZmiIcS/BrBAQDQZXtcC+84kOtt6vSEqVbJ6 xXUx7Zg/Oj/YUq7kHniy0H1DNAybbk6AUm6cKRa0ZsxsLL4wrCzRu6Rs++9VmsGc7GVY BdPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=D4iwr2L9GIQ9464vPXPlPMoVb003EQCcB2QbX9O/1yc=; b=0cashi4ZSnkVGbaF0T2dUsNrB3SErNnwnLzP3lsaVDKzW1zXisE4nkc6t3hn+ZjRbu MQHUSgGfOmnDl4yc9iZx3q6HQQ2RNV2AE0DePSsGkeLbiMVGMr2ZJ0x9gZRzuZ0xW1hn IaJv/zABhPVkQd8Ruaey4GBDZl+xS7jneAzlKP04rRckBPgsFb+ZOyGOENccpwHr53zZ y4+r2m9wpo0Ltiou0tqA3cwf8jI5GAIBY846vQvKGHMkqydxmc/Xw0IWnfllCLYvJC1d m0WFsvPeIlba7LFyUu91dLNcleVkfsv4lkBIMl2MCaBr+1luLnPfFIIILHx7pRuMycg5 wh6A== 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: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=D4iwr2L9GIQ9464vPXPlPMoVb003EQCcB2QbX9O/1yc=; b=Lk9lkkG+7cTfuPDED1RCwd8yC3+xBZKlFSy8hMYlAYz0oxljJlAai9MD47WM5fqxvF DAFtvxRURb/ZjBSk8hoAXzfEjL3oRP3PMg8tLtTA2v9jheOoLYDSs8QQYpnuhzyKTj9X SvexXcTARdNDf7LGlnGJb18pwC6ZsMfnj78L8uWEUGDstB6lfGTIZZpWmwRCHnD2E0l4 NCU9VNXBeW/fk3Ic4knlm+K1aublqq7UxJNx5MLvubsEvD1cyT3Ag3738966Va463QU9 Xbig1r0STil5XfWgX+VO3W3QZvN7vpmF1AWyh6h9aMd/se0pxwNuqr5Y/rjiPclw194s TBmA== X-Gm-Message-State: AD7BkJIALb8KqZ/SJ2z82GmfyjjmANfIo90Trpf+fJPeO3oGmeVKIK1xIsOKWx1mFJpNqg== X-Received: by 10.140.179.84 with SMTP id z81mr5740299qhz.21.1459957684631; Wed, 06 Apr 2016 08:48:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.141.4 with SMTP id p4ls459527iod.19.gmail; Wed, 06 Apr 2016 08:48:02 -0700 (PDT) X-Received: by 10.50.176.201 with SMTP id ck9mr538694igc.0.1459957682902; Wed, 06 Apr 2016 08:48:02 -0700 (PDT) In-Reply-To: <4187538d-68fa-4582-ba26-f406479abe67@isocpp.org> X-Original-Sender: EloAndRheo@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:25461 Archived-At: ------=_Part_2019_535804517.1459957682184 Content-Type: multipart/alternative; boundary="----=_Part_2020_1600044663.1459957682184" ------=_Part_2020_1600044663.1459957682184 Content-Type: text/plain; charset=UTF-8 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. On Tuesday, April 5, 2016 at 11:19:51 PM UTC-6, Sean Middleditch wrote: > On Tuesday, April 5, 2016 at 4:58:18 PM UTC-7, isocp...@denisbider.com > wrote: >> >> >> This would now be exception-safe: >> >> - without requiring pilfering; >> - and without a potentially, but almost never, valueless variant. >> > > Only for types that actually offered the relocation operation. You can't > assume that all user-defined types will support this. Thus variant must > continue to have some kind of valueless state to satisfy the other > constraints. > -- 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/eafd831f-85d2-430c-9969-7d084e6d28d2%40isocpp.org. ------=_Part_2020_1600044663.1459957682184 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Types with throwing move constructors are prime candi= dates to have a relocator, because it solves a problem specific to them. A = relocator can be implemented trivially, without changing the design of a no= n-nullable type like the particular std::list implementation. It would not = require changing the fundamental design of the type, which implementing a n= oexcept move constructor would require.

For user t= ypes, relocators would be implicitly defined by the compiler, under much th= e same terms as a move constructor.

I'm not se= eing 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.


On Tuesd= ay, April 5, 2016 at 11:19:51 PM UTC-6, Sean Middleditch wrote:
On Tuesday, April 5, 2016 at 4:58:1= 8 PM UTC-7, isocp...@denisbider.com wrote:

This would now be exception-safe:

- without requiring pilfering;
- and with= out a=C2=A0potentially, but almost never, valueless variant.

Only for types that actually offered the relo= cation operation. You can't assume that all user-defined types will sup= port this. Thus variant must continue to have some kind of valueless state = to satisfy the other constraints.

--
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/eafd831f-85d2-430c-9969-7d084e6d28d2= %40isocpp.org.
------=_Part_2020_1600044663.1459957682184-- ------=_Part_2019_535804517.1459957682184-- .