220 28323 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Trivial copyability and `optiona/variant`. Date: Thu, 22 Sep 2016 15:19:03 -0700 Lines: 114 Approved: news@gmane.org Message-ID: References: <47c7c8cf-13f4-4026-acf4-41ca1d2a3e53@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c18ffbea85907053d200cd1 X-Trace: blaine.gmane.org 1474582758 4790 195.159.176.226 (22 Sep 2016 22:19:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Sep 2016 22:19:18 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBWFRSG7QKGQEFYZMDVA@isocpp.org Fri Sep 23 00:19:13 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnCKe-0007xJ-0H for gclcip-std-proposals@m.gmane.org; Fri, 23 Sep 2016 00:19:04 +0200 Original-Received: by mail-oi0-f69.google.com with SMTP id i193sf237018254oib.3 for ; Thu, 22 Sep 2016 15:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:x-original-sender:x-original-authentication-results :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=BIo/KD2d5U2GClsjE8Ry1aNlQ5bmuPU1FnuuasP9UD4=; b=L/49tM3wxZXC/X8L96bH+rNBU/qiFGpFVg30vLobR9DPWKY05N21XeFaiWul3NCt4z CsOq0lkdbOrAYrpqmnLfCEIolXXdj6lodFv4M4SLaeZpMdxtxiujbFrPfzX6ki5eWbBQ q2s0oM+VUPPM8tCBpjjSz9ePFy93sSFuYR/5A79QcZFn+oeGrp3DmmIoqpUu4zFSyLWM BpP+2K32ijxGOQvT8rLz7uu2t/ec97oZbl13a+9cM3M8NRaYDGK3fNevf7yrH1SxNlNO 3CMjQKm6rVqkqkmQQxzKMTBJxLTVIxVVjW8DEDmi3fuu+pCTUWT1imWwLgBEPF1q5wNN XKiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=BIo/KD2d5U2GClsjE8Ry1aNlQ5bmuPU1FnuuasP9UD4=; b=DkxtkVs0FmipOiqSOcWm1oFChISuoCt3Oic81AOiDXUAu4qrH6oUPzG/Rk/jo5AfTL wBVoKx6junHkoiyWSzcB+KsMX/qOszJ5ycuPoxwpiGciQ3G7BXxXXPLfkJBV19QI+9wa 5oFouKARxtRweccWyfnGfoXG4oQeW94Ocif27HOZSr561SiGvSux21TjeD1YVOY94NF9 OqtEX3uAmo/IzCPLmRLVcfEBCpzSsJIXDSEmg68RKdShQst2hI+mbm7XUSSDVa73ty9X nB2Xx2/QkdvKJRnDRg/0JaKhxCk7FpvJnpZFLu7RNlKO2apkWAzjdmUFBNEeQVl63GqS 4P/A== X-Gm-Message-State: AA6/9Rmr31xAfdoultn5scijQYDjTheVb3UyMN1su4p0oKduATiOozrqJadENl9yu+L6eQ== X-Received: by 10.157.13.112 with SMTP id 103mr814283oti.51.1474582745372; Thu, 22 Sep 2016 15:19:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.8.10 with SMTP id 10ls7967990oty.10.gmail; Thu, 22 Sep 2016 15:19:04 -0700 (PDT) X-Received: by 10.176.2.176 with SMTP id 45mr1845883uah.120.1474582744643; Thu, 22 Sep 2016 15:19:04 -0700 (PDT) Original-Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com. [2607:f8b0:400c:c08::22e]) by mx.google.com with ESMTPS id w57si1705152uaw.189.2016.09.22.15.19.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Sep 2016 15:19:04 -0700 (PDT) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:400c:c08::22e as permitted sender) client-ip=2607:f8b0:400c:c08::22e; Original-Received: by mail-ua0-x22e.google.com with SMTP id 15so15166670uai.3 for ; Thu, 22 Sep 2016 15:19:04 -0700 (PDT) X-Received: by 10.176.82.41 with SMTP id i38mr1841456uaa.75.1474582744141; Thu, 22 Sep 2016 15:19:04 -0700 (PDT) Original-Received: by 10.103.78.213 with HTTP; Thu, 22 Sep 2016 15:19:03 -0700 (PDT) In-Reply-To: <47c7c8cf-13f4-4026-acf4-41ca1d2a3e53@isocpp.org> X-Original-Sender: calabrese@x.team X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@x.team; spf=pass (google.com: domain of calabrese@google.com designates 2607:f8b0:400c:c08::22e as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=x.team X-Original-From: Matt Calabrese 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:28323 Archived-At: --94eb2c18ffbea85907053d200cd1 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 22, 2016 at 2:46 PM, Casey Carter wrote: > On Thursday, September 22, 2016 at 12:06:04 PM UTC-7, Nicol Bolas wrote: >> >> `optional` is not required to be trivially copyable if `T` is trivially >> copyable. And yet, I cannot imagine an implementation of `optional` where >> that is not at least *possible*. After all, the bit saying whether the >> `optional` is empty is likely a basic type. So why should trivial >> copyability not be possible? >> >> Similarly, if all of the `Ts` for a `variant` are trivially copyable, it >> should be possible to make the variant itself trivially copyable. >> >> Is there an implementation problem I'm not aware of, or was this an >> oversight? Should a national body comment be filed or a defect report be >> sent? >> > > Those requirements are implementable: the Microsoft implementations of > optional and variant maintain trivial copyability of the contained types. > It seems to be QoI to me; I see no strong motivation to *require* that > behavior. > I mostly agree. I don't think it's a defect, but I do think that requiring triviality is the direction that we should go in a future standard. My main reason for thinking we should require triviality post-c++17 is mostly just because I think having a somewhat-usable constexpr variant is worthwhile. At the moment, due to language restrictions (that I personally consider defects) it is not possible to implement a constexpr copy or move operation for a variant *unless* the copy/move operation is trivial. So while I think it's useful to be able to guarantee triviality, I think the more important thing is guaranteeing at least some variant instantiations are a reasonable literal type, which in practice ends up requiring the operation to be trivial anyway. Apart from constexpr, there is at least one other reason to require triviality eventually anyway -- while it is rare, it is sometimes a requirement of niche datastructures to have an element type that is trivially copyable (i.e. certain lockfree datastructures). It would be pretty cool if a standard variant with appropriate parameters (or any algebraic data type for that matter) were guaranteed to meet these requirements. -- 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/CANh8DEmfYFNbUgbzrn9aV0ZKwAPQbqw78tfSQfyOs118PvyqcQ%40mail.gmail.com. --94eb2c18ffbea85907053d200cd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 22, 2016 at 2:46 PM, Casey Carter <cartec69@gmail.com> wrote:
On Thursday, September 22, 2016 at 12:06:04 PM UTC-7, Nicol Bolas wro= te:
`optional` is n= ot required to be trivially copyable if `T` is trivially copyable. And yet,= I cannot imagine an implementation of `optional` where that is not at leas= t possible. After all, the bit saying whether the `optional` is empt= y is likely a basic type. So why should trivial copyability not be possible= ?

Similarly, if all of the `Ts` for a `variant` are trivially copyab= le, it should be possible to make the variant itself trivially copyable.
Is there an implementation problem I'm not aware of, or was this a= n oversight? Should a national body comment be filed or a defect report be = sent?

Those requirements a= re implementable: the Microsoft implementations of optional and variant mai= ntain trivial copyability of the contained types. It seems to be QoI to me;= I see no strong motivation to *require* that behavior.

I mostly agree. I don't think it's a defec= t, but I do think that requiring triviality is the direction that we should= go in a future standard. My main reason for thinking we should require tri= viality post-c++17 is mostly just because I think having a somewhat-usable = constexpr variant is worthwhile. At the moment, due to language restriction= s (that I personally consider defects) it is not possible to implement a co= nstexpr copy or move operation for a variant unless=C2=A0the copy/mo= ve operation is trivial. So while I think it's useful to be able to gua= rantee triviality, I think the more important thing is guaranteeing at leas= t some variant instantiations are a reasonable literal type, which in pract= ice ends up requiring the operation to be trivial anyway.

Apart from constexpr, there is at least one other reason to require= triviality eventually anyway -- while it is rare, it is sometimes a requir= ement of niche datastructures to have an element type that is trivially cop= yable (i.e. certain lockfree datastructures). It would be pretty cool if a = standard variant with appropriate parameters (or any algebraic data type fo= r that matter) were guaranteed to meet these requirements.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmfYFNbUgbz= rn9aV0ZKwAPQbqw78tfSQfyOs118PvyqcQ%40mail.gmail.com.
--94eb2c18ffbea85907053d200cd1-- .