220 25477 <66a44c9c-21f9-4854-81ab-37235408eb4f@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Relocation as a solution for the valueless variant problem? Date: Thu, 7 Apr 2016 22:07:27 -0700 (PDT) Lines: 105 Approved: news@gmane.org Message-ID: <66a44c9c-21f9-4854-81ab-37235408eb4f@isocpp.org> References: <4187538d-68fa-4582-ba26-f406479abe67@isocpp.org> <105d82bc-e1cf-4795-894c-112cd591c3af@isocpp.org> <4f31b957-05be-47cf-a1ca-03f33a9900c0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_109_456967907.1460092047539" X-Trace: ger.gmane.org 1460092052 7026 80.91.229.3 (8 Apr 2016 05:07:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Apr 2016 05:07:32 +0000 (UTC) Cc: isocppgroup@denisbider.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBEHZTS4AKGQEJ6QCJAA@isocpp.org Fri Apr 08 07:07:31 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aoOdm-0006Qk-GE for gclcip-std-proposals@m.gmane.org; Fri, 08 Apr 2016 07:07:30 +0200 Original-Received: by mail-ob0-f199.google.com with SMTP id fg3sf39043443obb.3 for ; Thu, 07 Apr 2016 22:07:30 -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=IarF6wHCywLEJwVzwKwjQ2IU/1RHQRi+NVB/fHL/kmQ=; b=WdkzSTAq/uB45ze8sXeCjAfNEDkqtb0aOFVgNm7OXw4Rwpux198ISOICkObYhL1JLr aWFalEffH6+DcSkkhBUwZTxn2YglE5nGHd+k3b5HP3Rq9OOFpFwLmqoWGZ8oZ5ixP8vw EAV3btLlbx01FJeJ9LCjcTeuO5G7xiTA/yStuFrib1Z70jN8lkwGxnk4oG7oR9/Cg1sy wv0rkleOyzddPxnhkBXfqIB2OLpGl2mKWfgLT74Xw63V8hYy8iOwn6sos/ukQRqoBJ62 iLR2W7MRr5HIUFAoS/SUNKGsGZLl2ompybD3dTablK/c2gCNJiNtimtww/RUe3Zx216S ssDw== 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=IarF6wHCywLEJwVzwKwjQ2IU/1RHQRi+NVB/fHL/kmQ=; b=NGvxZp1K2Z+CjnUoNUuMP0kyWVyb17pMrAkVhbFAB43PBvWvSy3y4FQmYqfQ2v/AGZ YSsa5wMeLDwnWZW82lS97vydzfFmP8d9UcgUnnoSEJcYrXIQoI+FZj+mtT0mulBJUcUU szzq602iA+O41Yo4o7ojbqCBTPpnEFs+RBpI64ehk/gX+2UT48120q7/xhD+OoiRrbsF AqeGZJUlN5br/oxpEwr5pk9+3CtxMA0xWFOsGYbVz1kTRHs4NFkhIuS3V3YN9zTkZo1M Mr7J0HQc+qSf943xXQ8c+mOIc6Hq956v4i1erBzGcG2+inFtZj4M6T8SnVZbdj+dChTg nPsQ== 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=IarF6wHCywLEJwVzwKwjQ2IU/1RHQRi+NVB/fHL/kmQ=; b=QoIUMf1Hk6Zm55pTZEHp/gUHPPDF+7dE1S9SSdmDIRLp1Ih5KM9ZNVbzi+xOlecI0O kVIdE7gjSfGVQPTxpmKjwey92rtJfY1rXheY5UsBGkjV04gdbvza1jU9Sg4PXdT7wHp1 7guGgf3ewGEBS6aRvMUJlvArZ15q02eJinHKchkTDkwZo/ASY7AGmE+myiQDIPyJr3Uo bFKzCNEfmaEQZbH+EPVuzjzlMYoh+nos8mPdZt4hB+GCVOnzQc2ZKq2VR8EoO9RgBjmW sWQcpTm9Ses3Gdr4XF6N/3v5JwNyKXMAG91CsinwsNCjN2FBwV3DEgIyPk0yQYrwSHSj UnGw== X-Gm-Message-State: AD7BkJKjw4KGlu35JtupaYkKNICsrNi0cOVsCTUmIqlvChyngeyNTqJDbdxRxagre+zT0Q== X-Received: by 10.157.33.137 with SMTP id s9mr4267054otb.25.1460092049390; Thu, 07 Apr 2016 22:07:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.43.162 with SMTP id x2ls80622igl.34.gmail; Thu, 07 Apr 2016 22:07:28 -0700 (PDT) X-Received: by 10.50.147.8 with SMTP id tg8mr23508igb.8.1460092048580; Thu, 07 Apr 2016 22:07:28 -0700 (PDT) In-Reply-To: <4f31b957-05be-47cf-a1ca-03f33a9900c0@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:25477 Archived-At: ------=_Part_109_456967907.1460092047539 Content-Type: multipart/alternative; boundary="----=_Part_110_337853907.1460092047539" ------=_Part_110_337853907.1460092047539 Content-Type: text/plain; charset=UTF-8 On Friday, April 8, 2016 at 12:38:14 AM UTC-4, isocp...@denisbider.com wrote: > > Hey Sean, > > if you would like to see move destruction / relocation proposed in a safer > form, do you have any ideas about what that safer form would look like? > > You refer to that modern C++ discourages direct use of new and delete. > Well, yes, of course. But libraries still need to use new and delete, as > well as placement new, to implement containers. How would you propose > implementing the standard library without these features? > > It is not the intention of this Relocator proposal to be used directly by > end users. The intention is that it would be used in STL implementations, > to solve problems that a lack of destructive move makes difficult. > > Language users should not have to worry about invoking or implementing > relocators, in much the same way they shouldn't have to worry about move > constructors. Language users should use standard library types, and it's up > to the library types to implement relocators and move constructors. > It's a nice fantasy to believe that the standard library can cover every use case. Or that compiler-generated move constructors are sufficient. But at the end of the day, it is little more than a fiction. In the real world, people have to learn how to write move constructors. Most C++ programmers have to do this. And they have to learn to write them *correctly*. Whatever your personal intention may be, if you add some form of destructive move/relocation/whatever-you-want-to-call it, lots of C++ programmers are going to have to learn how to use it. They're going to have to learn how to write destructive move operations and they're going to have to learn how to invoke them. Correctly and safely. You cannot just handwave away such issues. -- 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/66a44c9c-21f9-4854-81ab-37235408eb4f%40isocpp.org. ------=_Part_110_337853907.1460092047539 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, April 8, 2016 at 12:38:14 AM UTC-4, isocp...@de= nisbider.com wrote:
Hey Sean,

if you=C2=A0would like to see= =C2=A0move destruction / relocation proposed in a safer form, do you have a= ny ideas about what that safer form would look like?

You refer to that modern C++ discourages direct use of new and delete. W= ell, yes, of course. But libraries still need to use new and delete,=C2=A0a= s well as=C2=A0placement new,=C2=A0to implement containers. How would you p= ropose implementing the standard library without these features?
=
It is not the intention of this Relocator proposal to be use= d directly by end users. The intention is that it would be used in STL impl= ementations, to solve problems that a lack of destructive move makes diffic= ult.

Language users should not have to worry about= invoking or implementing relocators, in much the same way they shouldn'= ;t have to worry about move constructors. Language users should use standar= d library types, and it's up to the=20 library types to implement relocators and move constructors.

It's a nice fantasy to believe that the standard lib= rary can cover every use case. Or that compiler-generated move constructors= are sufficient. But at the end of the day, it is little more than a fictio= n.

In the real world, people have to learn how to write move constru= ctors. Most C++ programmers have to do this. And they have to learn to writ= e them correctly.

Whatever your personal intention may be, if= you add some form of destructive move/relocation/whatever-you-want-to-call= it, lots of C++ programmers are going to have to learn how to use it. They= 're going to have to learn how to write destructive move operations and= they're going to have to learn how to invoke them. Correctly and safel= y.

You cannot just handwave away such issues.

--
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/66a44c9c-21f9-4854-81ab-37235408eb4f= %40isocpp.org.
------=_Part_110_337853907.1460092047539-- ------=_Part_109_456967907.1460092047539-- .