220 36354 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: Default assignment operators for std::pair and std::tuple Date: Tue, 26 Dec 2017 05:46:21 -0800 (PST) Lines: 67 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18743_2133865005.1514295981992" X-Trace: blaine.gmane.org 1514295875 11194 195.159.176.226 (26 Dec 2017 13:44:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Dec 2017 13:44:35 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDH2LIF7UEOBBL5FRHJAKGQEGYQ2QUA@isocpp.org Tue Dec 26 14:44:31 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTpWn-00028l-Pr for gclcip-std-proposals@m.gmane.org; Tue, 26 Dec 2017 14:44:21 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id j7sf556402uak.18 for ; Tue, 26 Dec 2017 05:46:24 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=MJPY+PS65rlF+Ygj5SkaaR+9Xp2AyQGfUi/OUiIAkX8=; b=gFxMH34CON1CjnaxuPRRRIrs6V4+PiQcMWsq7SPgjQI3cGfIaW6am6CdHP1MIaAyWZ mzpKbl9jqhUR1JHaTTOnIaWO0rHcQxbbQcU3Z2yFqPq2b1QvYd3Z1pFCHlPX0t+7qMZC wF7uwePJQ2Dm3unaZS96ZFZxHyGjfH9WherL8lGSIZ2ZPTJnr/HvA5OnQwP3d11r3OiA OrSgWxZqj/gyx+Dp2TSbbB9hisdXICn2h4ybVguTKZS6fFqi6QiTQiiBvnSCB+1L0sbX zkRkrfOKJMTjj6wYVYG4dHVtEXlow8nGw8T7C9iEW6njoNuf7INxpnHQgNwVg+bceB+D es6A== 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: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=MJPY+PS65rlF+Ygj5SkaaR+9Xp2AyQGfUi/OUiIAkX8=; b=DRMYTQyerZZiXKTUFLviUrTBR88BLUtmBR1TQj2Nxk0s0G1WRgm4xQiydpm2I2GTq5 0A5w+ekxII6NeFcg6mvZcPcd5MElq4hCguxeLG20hzSXDUdmdT1WLIE3XFDxcDnUijyS Apf/vZV9gtXiN811LwVTvLg1T46EbEEHyiVg1cSWuGeYjmZf0tetLUbDFqz27kSM1EqG tUb4/oBrBLnmIn/qGsk2y780zof9rnZubewIAmZPup/8lKtPb4DTRYDHOlfCVFNnH0UE 7POjn3J3EbEqVmIU+5e6OHCEV3NEMA9v4KK5lNfl2WJb1DweBvfF9lWQq/wvYsblr/jA 1hYg== X-Gm-Message-State: AKGB3mIQIKtKv8XdMIYqbiPYBKpKMhsVKY+Hp8rgoLmu5MJl8LQjYBct lSVeqozlTefinRfkFNuRf4HMOQ== X-Google-Smtp-Source: ACJfBouw3sXNNWbJq8FYoRlX3sjd8IrlbyOtZP+E7c1pYfyj3aOqjfKWIVU7bNUnS94Op4l0/cUGgA== X-Received: by 10.159.56.45 with SMTP id p42mr13575958uad.83.1514295984335; Tue, 26 Dec 2017 05:46:24 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.159.150 with SMTP id i144ls3060253vke.11.gmail; Tue, 26 Dec 2017 05:46:22 -0800 (PST) X-Received: by 10.31.96.72 with SMTP id u69mr2356045vkb.11.1514295982436; Tue, 26 Dec 2017 05:46:22 -0800 (PST) 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:36354 Archived-At: ------=_Part_18743_2133865005.1514295981992 Content-Type: multipart/alternative; boundary="----=_Part_18744_1063934103.1514295981992" ------=_Part_18744_1063934103.1514295981992 Content-Type: text/plain; charset="UTF-8" Given that the copy and move constructors of both std::pair and std::tuple are defaulted, why shouldn't we enforce the same for their respective assignment operators? It seems strange that assigning these types would invoke non-trivial work compared to just copy constructing them, and as a result of this difference, currently both types are not considered trivially copyable. Based on an old discussion , it seems that this discrepancy in the requirement caused some compilers to make std::pair trivially copyable while others don't. Furthermore, someone on StackOverflow hacked up an implementation for std::tuple that was trivially copyable. It would be nice if future proposals can provide some potential guarantees on this matter. -- 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/ceb89ead-99c9-41fc-a40e-876eac97a6f1%40isocpp.org. ------=_Part_18744_1063934103.1514295981992 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given that the copy and move constructors of both std= ::pair and std::tuple are defaulted, why shouldn't we enforce the same = for their respective assignment operators? It seems strange that assigning = these types would invoke non-trivial work compared to just copy constructin= g them, and as a result of this difference, currently both types are not co= nsidered trivially copyable.

Based on an old discussion, it seems that this discrepancy in the requirement ca= used some compilers to make std::pair<scalar> trivially copyable whil= e others don't. Furthermore, someone on StackOverflow=C2=A0hacked up an implementation for std::tuple that was trivially copyable. It would be nice if future pr= oposals can provide some potential guarantees on this matter.

--
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/ceb89ead-99c9-41fc-a40e-876eac97a6f1= %40isocpp.org.
------=_Part_18744_1063934103.1514295981992-- ------=_Part_18743_2133865005.1514295981992-- .