220 36364 <9d1e799d-b127-457f-9bd2-c815bd914d15@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: "mrpi via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Default assignment operators for std::pair and std::tuple Date: Tue, 26 Dec 2017 13:33:10 -0800 (PST) Lines: 136 Approved: news@gmane.org Message-ID: <9d1e799d-b127-457f-9bd2-c815bd914d15@isocpp.org> References: <4110e47f-a021-4ccc-9e03-53e4ebdb8c21@isocpp.org> <4605434.q3o9RnjlYE@tjmaciei-mobl1> <5300cf40-f7db-4eb6-ad36-4742855124ae@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19781_629448826.1514323990603" X-Trace: blaine.gmane.org 1514323877 30535 195.159.176.226 (26 Dec 2017 21:31:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Dec 2017 21:31:17 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDH2LIF7UEOBBGEARPJAKGQELN6VMQA@isocpp.org Tue Dec 26 22:31:13 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 1eTwoZ-0007WP-5g for gclcip-std-proposals@m.gmane.org; Tue, 26 Dec 2017 22:31:11 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id a67sf12448116vki.21 for ; Tue, 26 Dec 2017 13:33:14 -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=hnrpdW2Em4f0qYdqPetbZBP+77U6NrYEVCpdaBuNp8g=; b=HN1iR8izvDowhhTJArtaJQ2iU10mEPRE1wxwMVw+zpvwBd/UDjsRbenPv89Ku5DQqM AZnrs/F/1Bmq6nm3pQBp2KBp0N6/QJEQOJdUiLOX33PKiiLlY9QvpTeJCN4bbfPMpaZ7 MobrnA//EPB2h2rs21rDzAjH6g2BHzgC8I/T6F3ot9QPMHXv6qWIpmGs0/crLly4cDS1 JrHJpBLx81Czwb4bcmbNu3Lum9Uyg6lc9Kl4m+Mon37269jlHCM5sJr7IGe3bLqRNoNZ kM/FYJhvVHuzWDEVcilmq9p1EKiS6xE9g0mYMt+mVefUHsMyc+o1qG/gdpMQSh5CQGKo othA== 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=hnrpdW2Em4f0qYdqPetbZBP+77U6NrYEVCpdaBuNp8g=; b=VBt0Ggjdq780kXj7pibSMiGtwbB/+wJ753/ETB5+o0f8DbYpAa6XwrY1yxNIbukRlu Js7dAVTZDmvVoRV8DNBKNK1F/9Fcj8OpoPctXBwKHrzGRIT8UgYxWWO2zx3SKs4wkh3A Ba2W+I2cXjPyWvEMEGf/Gbtt8r3Vo/k8o6FALBwj1F/2QJ1GbP6lE4VbZQrIywwUqEij W2Tk1kEN6aWpRbIJBepyrhHpSUdcfynZEPtugpyoQNDd7d99NydUAxLljnXH3C+jr8JM ykiFiYeh+GdBfdWAVMZRocwUItwzyJTcrNjKsO/rJmdJ/DkDJOTMPSqb37pZCWM8bFH4 94ug== X-Gm-Message-State: AKGB3mJYLMt2ThPo2f9cHeXIo4s9D57yqzAEiF3KBxXkuTvRCQ4d/Kgm EPWYGfnGvrU+n0OGib8VOtMrgg== X-Google-Smtp-Source: ACJfBou+7fYmjnOpmsH0vTGV2ZtbSYg4TtdXqNDdUE/Q0x1VmbU2WkUOoRLOttvthHbu0tfI8gkK8w== X-Received: by 10.176.89.108 with SMTP id o41mr4532037uad.47.1514323993533; Tue, 26 Dec 2017 13:33:13 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.150.196 with SMTP id y187ls3468435vkd.10.gmail; Tue, 26 Dec 2017 13:33:11 -0800 (PST) X-Received: by 10.31.96.72 with SMTP id u69mr2454317vkb.11.1514323991023; Tue, 26 Dec 2017 13:33:11 -0800 (PST) In-Reply-To: X-Original-Sender: mrpi@google.com X-Original-From: mrpi@google.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:36364 Archived-At: ------=_Part_19781_629448826.1514323990603 Content-Type: multipart/alternative; boundary="----=_Part_19782_119203547.1514323990603" ------=_Part_19782_119203547.1514323990603 Content-Type: text/plain; charset="UTF-8" Could we possibly consider it a defect to be fixed? There never was a good reason other than history for them not being guaranteed trivially conditional when templated on trivially copyable types. In the same manner as how the definition of "trivially copyable" has been retroactively changed for the C++11 standard post-C++14 (e.g. that the destructor must not be deleted) to clear up the difference in behavior of std::is_trivially_copyable between MSVC and lib(std)?c++, couldn't we consider it a fix to clear up this ambiguity? After all, even now we have slight differences (MSVC has std::pair as trivially copyable). Along with the changes to std::optional and std::variant, we can also make this a trend in pushing for types to be more trivial/trivially copyable wherever possible. On Tuesday, December 26, 2017 at 12:11:21 PM UTC-8, Ville Voutilainen wrote: > > On 26 December 2017 at 21:51, mrpi via ISO C++ Standard - Future > Proposals > wrote: > > Doesn't the same argument about optionals and variants apply? Just > recently > > std::optional and std::variant weren't yet made trivially copyable (nor > have > > any recent draft of the standard accepted it yet). What I'm asking about > is > > doing the same for std::pair and std::tuple. > > The difference is that optional and variant were introduced in C++17, > and are still considered > experimental by (some) implementations. Both tuple and pair have been > there since C++11 or before. > > > And furthermore, what sort of problems would pop up from enforcing > > std::tuple to be trivially copyable? > > > No other problems besides the ABI break, I think. Implementation-wise > there's nothing The Elf or his > Mighty Maintainer could not do, and the same applies to other > implementations and their authors; > making such types conditionally trivial is not particularly hard. The > warts arise because the C++11 > types weren't specified or necessarily known how to write in > fully-constexpr (constexpr was enhanced > in C++14) or fully-triviality-reflecting fashion, and changing that, > while doable in a pure C++17 environment, > is not always so straightforward when C++11 (and ABI) compatibility is > a concern. > -- 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/9d1e799d-b127-457f-9bd2-c815bd914d15%40isocpp.org. ------=_Part_19782_119203547.1514323990603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Could we possibly consider it a defect to be fixed? There = never was a good reason other than history for them not being guaranteed tr= ivially conditional when templated on trivially copyable types. In the same= manner as how the definition of "trivially copyable" has been re= troactively changed for the C++11 standard post-C++14 (e.g. that the destru= ctor must not be deleted) to clear up the difference in behavior of std::is= _trivially_copyable between MSVC and lib(std)?c++, couldn't we consider= it a fix to clear up this ambiguity? After all, even now we have slight di= fferences (MSVC has std::pair<int, int> as trivially copyable).
<= br>
Along with the changes to std::optional and std::variant, we = can also make this a trend in pushing for types to be more trivial/triviall= y copyable wherever possible.

On Tuesday, December 26, 2017 at 12:11= :21 PM UTC-8, Ville Voutilainen wrote:
On 26 December 2017 at 21:51, mrpi via ISO C++ Standard - Future
Proposals <std-pr...@isocpp.org> wrote:
> Doesn't the same argument about optionals and variants apply? = Just recently
> std::optional and std::variant weren't yet made trivially copy= able (nor have
> any recent draft of the standard accepted it yet). What I'm as= king about is
> doing the same for std::pair and std::tuple.

The difference is that optional and variant were introduced in C++17,
and are still considered
experimental by (some) implementations. Both tuple and pair have been
there since C++11 or before.

> And furthermore, what sort of problems would pop up from enforcing
> std::tuple<int> to be trivially copyable?


No other problems besides the ABI break, I think. Implementation-wise
there's nothing The Elf or his
Mighty Maintainer could not do, and the same applies to other
implementations and their authors;
making such types conditionally trivial is not particularly hard. The
warts arise because the C++11
types weren't specified or necessarily known how to write in
fully-constexpr (constexpr was enhanced
in C++14) or fully-triviality-reflecting fashion, and changing that,
while doable in a pure C++17 environment,
is not always so straightforward when C++11 (and ABI) compatibility is
a concern.

--
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/9d1e799d-b127-457f-9bd2-c815bd914d15= %40isocpp.org.
------=_Part_19782_119203547.1514323990603-- ------=_Part_19781_629448826.1514323990603-- .