220 36366 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Default assignment operators for std::pair and std::tuple Date: Tue, 26 Dec 2017 13:54:40 -0800 (PST) Lines: 122 Approved: news@gmane.org Message-ID: References: <4110e47f-a021-4ccc-9e03-53e4ebdb8c21@isocpp.org> <4605434.q3o9RnjlYE@tjmaciei-mobl1> <5300cf40-f7db-4eb6-ad36-4742855124ae@isocpp.org> <9d1e799d-b127-457f-9bd2-c815bd914d15@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19427_464236254.1514325280914" X-Trace: blaine.gmane.org 1514325166 5135 195.159.176.226 (26 Dec 2017 21:52:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Dec 2017 21:52:46 +0000 (UTC) Cc: mrpi@google.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBIUKRPJAKGQE25FEJCI@isocpp.org Tue Dec 26 22:52:41 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTx9M-0000uF-HP for gclcip-std-proposals@m.gmane.org; Tue, 26 Dec 2017 22:52:40 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id y8sf11682353ual.17 for ; Tue, 26 Dec 2017 13:54:43 -0800 (PST) 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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=/LXJ07FST2Y3XVo3kMJ+E1Z3oWLQyAa50wLoXezbBI0=; b=gUsjQWGh2LAhuACx901+nSatA3XfX8CJb9kY9fouQHx8+vXw7jcCU1nD6WB15HmA1s iXELQ0biyGIHh7GcYE/gXALMcmMLxsdFj5rFcEgmJt7GNyF+SzYN66a+nSZr0RFXfE7L g4J4hzJ9MPVCRoZb6d1ZDV3WzrAJIYErmmlWS8H/asmzFie7YmF6mYKd2t201tdtPYsV hE5iRFSGF8DokocPdBFvypslKwxEnteIzKVBge/5nYoLD3VEpmZ/I2uaCfRXEt9TN+9W bdi84nSpvYW0OXKYHfK+86Kz/Lz3zPwxqzSzSrSE0dW2cWDjlNM6hkneyx7HWx789bHZ xeIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=/LXJ07FST2Y3XVo3kMJ+E1Z3oWLQyAa50wLoXezbBI0=; b=IRcUWYUZcGpH2XKanmBpzy8HBrIAcRs3UmiD8vH+2vZCTOSzT+FtYJg0nJMfGCpvjB rO65sTw93CKnMkbN52fqRpYKfVu3KCyxhgR5etAb8BcGCeKpzv3kZIBen6kXGKT1957I RtuOKFCGWJ9IK7Bj3p/fKOr8/Qrlp7lGuRzsgWw/lVUOl5nxoLoCGPLZRWQ6Big8N9ix 0Mo9lYGZ+nIErufdvSr2Z04gQHZevqVoapjyGH+/pTpvPX7hX22+gLV5zKoaoqLusDph 0VJT2SekMx451a3DsT6i2n9hzauXuCRMIgHb7tSs7SQVghfEEvA7mPfJbOLc58Ya4sp3 5cGQ== 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: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=/LXJ07FST2Y3XVo3kMJ+E1Z3oWLQyAa50wLoXezbBI0=; b=QtdQQLsoK2i2+CFdCk3CLDO8iB70MDGrMC2uGbfh9iESmErSb+kAWkaL8IM3HD/m0c HgIA3aTncSn/kvVZtBay8hGnFJ/TfEj/V1HWMKqCdL3MNQH0Wln96XOoR+00VJjgtnkl p+efX4lOxjnXRosyb7iuO9g/OfYIodd4JdtUOzLZPIFjKcxGF9LysW14Fglr2+EG3SfH 7q9CrrVB9O31zdlDVypMusZmAF4kjiihlIaeie5FBtLNd/F/4AbmWYG5ZAQaHbzwkW+S cDK/ZkmfrLn1ueXKmZMyFPdDQitfyLP9hXBGh+xDpG5qt3ZTVlA4Cq2v3+WO/2GtybPy khHA== X-Gm-Message-State: AKGB3mLN7telNHloTMzjiKkr0tqyEM/ux0vL+eBmUTAC/7y1D9HgtDrW sdVUlwgC/49pSLvCv+r5sDcxXQ== X-Google-Smtp-Source: ACJfBoszdOZgdcNMb5DYLYiYneBVfveZ8sLbWdXJskCvbpOtHMBi5weysgRfOdZBd8Qu7mViJ9TzJQ== X-Received: by 10.159.49.15 with SMTP id m15mr10909403uab.36.1514325283175; Tue, 26 Dec 2017 13:54:43 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.33.21 with SMTP id d21ls3414334ual.7.gmail; Tue, 26 Dec 2017 13:54:41 -0800 (PST) X-Received: by 10.31.174.75 with SMTP id x72mr2460567vke.13.1514325281415; Tue, 26 Dec 2017 13:54:41 -0800 (PST) In-Reply-To: <9d1e799d-b127-457f-9bd2-c815bd914d15@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:36366 Archived-At: ------=_Part_19427_464236254.1514325280914 Content-Type: multipart/alternative; boundary="----=_Part_19428_795676701.1514325280914" ------=_Part_19428_795676701.1514325280914 Content-Type: text/plain; charset="UTF-8" On Tuesday, December 26, 2017 at 4:33:10 PM UTC-5, mr...@google.com wrote: > > Could we possibly consider it a defect to be fixed? > A defect fix from 6 years ago which requires a possibly ABI-breaking change to implementations? I rather doubt it. The changes to `std::basic_string` which prevent COW implementations were not considered "defects", even though I would certainly consider COW implementations "quality" in the wrong direction in most cases. They were a formal part of C++11. Making such a change as a defect fix is not going to make implementers more likely to make those ABI-breaking changes. 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++, > No, that's different. It was never the intent to make types with deleted destructors be trivially copyable. That was merely a mistake; fixing it had nothing to do with library variance. Also, that defect was first reported in 2013; it just took a while for them to work out a fix for it. Lastly, making such a change does not require breaking the ABI of any library implementation. 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). > Differences between implementations are expected; that's (part of) why we have different implementations instead of just pointing at a codebase and saying, "that's the standard". 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. > -- 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/e651d733-db30-4097-a7d4-d1e713aef120%40isocpp.org. ------=_Part_19428_795676701.1514325280914 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, December 26, 2017 at 4:33:10 PM UTC-5, mr...@g= oogle.com wrote:
Could we possibly consider it a defect to be fixed?

A defect fix from 6 years ago which requires a possibly A= BI-breaking change to implementations? I rather doubt it.

The changes to `std::basic_string` which prevent COW implementation= s were not considered "defects", even though I would certainly co= nsider COW implementations "quality" in the wrong direction in mo= st cases. They were a formal part of C++11.

Making= such a change as a defect fix is not going to make implementers more likel= y to make those ABI-breaking changes.

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 defin= ition 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 betw= een MSVC and lib(std)?c++,

No, that&#= 39;s different. It was never the intent to make types with deleted destruct= ors be trivially copyable. That was merely a mistake; fixing it had nothing= to do with library variance.

Also, that defect wa= s first reported in 2013; it just took a while for them to work out a fix f= or it. Lastly, making such a change does not require breaking the ABI of an= y library implementation.

couldn't we consider it a fix to clear= up this ambiguity? After all, even now we have slight differences (MSVC ha= s std::pair<int, int> as trivially copyable).
=
Differences between implementations are expected; that's= (part of) why we have different implementations instead of just pointing a= t a codebase and saying, "that's the standard".
A= long with the changes to std::optional and std::variant, we can also make t= his a trend in pushing for types to be more trivial/trivially copyable wher= ever possible.

--
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/e651d733-db30-4097-a7d4-d1e713aef120= %40isocpp.org.
------=_Part_19428_795676701.1514325280914-- ------=_Part_19427_464236254.1514325280914-- .