220 36328 <0f45770f-dc62-4459-8e1c-6aece46d05e6@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Trivial copyability and `optiona/variant`. Date: Sun, 24 Dec 2017 17:40:14 -0800 (PST) Lines: 149 Approved: news@gmane.org Message-ID: <0f45770f-dc62-4459-8e1c-6aece46d05e6@isocpp.org> References: <390b06f2-0c86-465e-9a11-d0ebb3501970@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14011_1141074066.1514166014789" X-Trace: blaine.gmane.org 1514165899 8001 195.159.176.226 (25 Dec 2017 01:38:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 25 Dec 2017 01:38:19 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIIBLUB2ICRUBDBPHFKW@isocpp.org Mon Dec 25 02:38:15 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTHiY-0001jO-SV for gclcip-std-proposals@m.gmane.org; Mon, 25 Dec 2017 02:38:15 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id z134sf8749955vkd.5 for ; Sun, 24 Dec 2017 17:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; 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; bh=CNXxcn7kI22WIEaXaH+1b1KLuX4BLMIsqCwdKaL0o/8=; b=Gu2BITivquFxLJ3/yzq1HXlA0kqpc4EZM1vuq2ocV9owXvXIiiG1XqbVW1wFPS3/A5 on/vkj9ShvRD+55Oa+ngr79RvwtIbosvZgOO0/GdxG0mtn++VcBD5kG5cJOWYoJ/288R +gYGAW8gtBBCgV040c0cNEs5Yr8//1N4HjhVEKM5bX1TrvewMrx8l1oYfLnNi2UHqJLo UNx8223tGDsHLXbp0jVez1ocANZLa4OJMgDXQeWvPGPttPOB487QZD7wEspaXARvyo61 /Gs9DDp70lCtcj7EzeiYBx8R6zWlemAeU5pVu2UKHyK8Q0vqguRa1rXK4k725+Pu1/Yi cETQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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; bh=CNXxcn7kI22WIEaXaH+1b1KLuX4BLMIsqCwdKaL0o/8=; b=U2/Jq6BJrVHO6zNsFbNNQVrx4HVzvBHcx/9HzYP04ggfgyXCVzcrU1ehJZUX+cbMvD K3IHTgZ8lA/lf4P9yc80181xGHlQ3yaZ6ZpqqCsKXENOx/8F7+KVRI3O+tFl+k3Q1CTm +vvYrBT7Evtg+38A45BKEY6nFfpBiSH6RnwbVkxOnia3K6WGImJncuahSuzxAJcPmFaD m3a/SV5A+KS1p4MQarhQSccfhRF+RbbUI/8eDUYPrn+KnZ16iABsZVboGZXW9nNXtnHh 5AZCN6/eVNJYMybSqSjWaqtiHB2kdzWbQBPeu91m9WvqwBZlxuBatlojKJKsY0NjdaDi 5rnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=CNXxcn7kI22WIEaXaH+1b1KLuX4BLMIsqCwdKaL0o/8=; b=jgDyCbOWsg8Khmjj52NKkQ/Vxx1aGmgjVk6RiSE8n6UeVo5QKhODbod0Sx0dF0f7Vh tOmGrnnuMUZQokueZ5B2Sft2SMQqgCNngKHPEiFRwLNr0JbKyAHuU334FqfO+67YyKI4 dMZJXVJDim1xwbcKByNSEtdYDAk7hTPTo1QHrFauVBdd1f0mNFFv54q6UlP4lwdeTyCX QheLvyRysQlw4RmmBAz+qnrWXYCyQQm+rBnUjoIiOQ+mYogUyIYyVe46OmL+JZ9ZvKzr EimbAlF3WR39/ChNsgpR2E8wEgROn7/rQ9w936YGEFzRayHg5fteM/bti96C5Xj+wET3 AOPQ== X-Gm-Message-State: AKGB3mLsMo9hhnA94MwC6f2K0mPE+VZdmOIagGkDzWnx0teDdFoD/eVx 1qj2BdEzj2fV6gJLToHGJMkhng== X-Google-Smtp-Source: ACJfBouQeg+a1KXYj6LJHJkcCWUQ6MJzeDoK9kfXYG/PUmuGbsqx297QL8Bpp/4xBC7kT647ffmIqQ== X-Received: by 10.159.38.36 with SMTP id 33mr11198034uag.90.1514166017322; Sun, 24 Dec 2017 17:40:17 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.197.3 with SMTP id v3ls2052253vkf.16.gmail; Sun, 24 Dec 2017 17:40:15 -0800 (PST) X-Received: by 10.31.149.200 with SMTP id x191mr1163118vkd.3.1514166015278; Sun, 24 Dec 2017 17:40:15 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@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:36328 Archived-At: ------=_Part_14011_1141074066.1514166014789 Content-Type: multipart/alternative; boundary="----=_Part_14012_539206530.1514166014790" ------=_Part_14012_539206530.1514166014790 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Saturday, December 23, 2017 at 4:47:05 AM UTC-8, Ville Voutilainen wrote= : > > On 23 December 2017 at 14:17, Andrey Davydov > wrote:=20 > > Is there any progress being made on this? As I see now the Microsoft an= d=20 > > libc++ implementation maintain trivial copyability, but libstdc++=20 > doesn't:=20 > > https://godbolt.org/g/tL29Hd=20 > > The proposal for that hasn't apparently been adopted yet, so this=20 > hasn't popped up as a high-priority=20 > item on the libstdc++ todo list. I suppose I should implement it=20 > anyway, but I can't make any promises=20 > that it'll make it into gcc 8. > Coincidentally, "trivial copyability of std::optional" just popped up over= =20 on the SG14 list as well: https://groups.google.com/a/isocpp.org/forum/#!msg/sg14/ZqrAbZ2Vq9s/iNVCL3n= aDAAJ The fundamental problem (IMO) is that if you make optional trivially=20 copyable, then you have optional a =3D 42; // correctly constructs an `int` and begins it= s=20 lifetime optional b =3D a; // trivially copies some bits into the memory= =20 address of `b` In the `b` case, there is no `int` object actually constructed (assuming=20 the common implementation of `optional` as containing a union of a dummy= =20 char and a `T` object, where the `T` object is not constructed by default).= =20 So the first access to `b.value()` invokes undefined behavior, as far as=20 I'm aware. I believe that this problem (A) does not cause incorrect codegen in=20 practice because compilers don't optimize on lifetime information yet; and= =20 (B) is actively being tackled by papers such as Ville & Richard's P0593r1= =20 so that such optimizations might be implementable in the future. If P0593r1 is adopted in its current form, then optional will be able to= =20 be trivially_copyable whenever T is trivially_copyable; however, there will= =20 be cases where the trivialness of the copy constructor cannot be propagated= =20 because of a non-trivial destructor, or vice versa. =E2=80=93Arthur --=20 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 e= mail 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/0f45770f-dc62-4459-8e1c-6aece46d05e6%40isocpp.or= g. ------=_Part_14012_539206530.1514166014790 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Saturday, December 23, 2017 at 4:47:05 AM UTC-8, Ville = Voutilainen wrote:
On 23 Decemb= er 2017 at 14:17, Andrey Davydov <andrey.a...@gmail.com> wrote:
> Is there any progress being made on this? As I see now the Microso= ft and
> libc++ implementation maintain trivial copyability, but libstdc++ = doesn't:
> https://godbolt.org/g/tL29Hd

The proposal for that hasn't apparently been adopted yet, so this
hasn't popped up as a high-priority
item on the libstdc++ todo list. I suppose I should implement it
anyway, but I can't make any promises
that it'll make it into gcc 8.

= Coincidentally, "trivial copyability of std::optional" just poppe= d up over on the SG14 list as well:

The fundamental problem (IMO) is that if you ma= ke optional<T> trivially copyable, then you have

=
=C2=A0 =C2=A0 optional<int> a =3D 42; =C2=A0// correctly constru= cts an `int` and begins its lifetime
=C2=A0 =C2=A0 optional<in= t> b =3D a; =C2=A0// trivially copies some bits into the memory address = of `b`

In the `b` case, there is no `int` object a= ctually constructed (assuming the common implementation of `optional<T&g= t;` as containing a union of a dummy char and a `T` object, where the `T` o= bject is not constructed by default). So the first access to `b.value()` in= vokes undefined behavior, as far as I'm aware.

I believe that this problem (A) does not cause incorrect codegen in practi= ce because compilers don't optimize on lifetime information yet; and (B= ) is actively being tackled by papers such as Ville & Richard's P05= 93r1 so that such optimizations might be implementable in the future.
=

If P0593r1 is adopted in its current form, then optiona= l<T> will be able to be trivially_copyable whenever T is trivially_co= pyable; however, there will be cases where the trivialness of the copy cons= tructor cannot be propagated because of a non-trivial destructor, or vice v= ersa.

=E2=80=93Arthur

--
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/0f45770f-dc62-4459-8e1c-6aece46d05e6= %40isocpp.org.
------=_Part_14012_539206530.1514166014790-- ------=_Part_14011_1141074066.1514166014789-- .