220 36371 <39606695-51a7-46d6-874d-0ddb99fabf0e@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 15:47:52 -0800 (PST) Lines: 235 Approved: news@gmane.org Message-ID: <39606695-51a7-46d6-874d-0ddb99fabf0e@isocpp.org> 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_19434_1842324615.1514332072916" X-Trace: blaine.gmane.org 1514331958 21903 195.159.176.226 (26 Dec 2017 23:45:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Dec 2017 23:45:58 +0000 (UTC) Cc: mrpi@google.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDH2LIF7UEOBBKV7RPJAKGQED4FF4XA@isocpp.org Wed Dec 27 00:45:54 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eTyuv-0005Je-7t for gclcip-std-proposals@m.gmane.org; Wed, 27 Dec 2017 00:45:53 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id v128sf932360vkb.22 for ; Tue, 26 Dec 2017 15:47:56 -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=vixp4YKy72qsDdTg9m2axcfXIYP2SiD6/jwPqy5QacA=; b=YlxPU9hxQRyilfUyPV/kFXivD5ovfbONoSuJW1L59bHGKfoJ7Ff6SrfLsHOGdLYZAg ATEwe0KuF1CFyK5+xgUM9npSU/B4Aws2ndTrDI2dpo7l5R1y3ZAQaOX0zuSgGFxCUl7J AP3CdY5wIBtcP72OOMxuSOgXwaLjvGcvEkkwjFq2rB6REk0NQGA89Xx3p3+e3QPtWAZr HqCKhOnkNBIpZNPj+SlvsWNEOYXmUOfs+lhbZKh8stHXLlrfkF6qT1zF/bAyOaKmKDZz MV3N2Li63zyNDL+dv3HRULH8JqxeHHgPCssa5h1HuI2vOVEd1JpRv0QTUyfMlB4gj5LE CVZQ== 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=vixp4YKy72qsDdTg9m2axcfXIYP2SiD6/jwPqy5QacA=; b=E/XLJhqgWYzqRH4DcHYGe97LfbGPcpVGgLEvm2PHjim9hkcaP9S5YwUDpYXQcn1Zvy YDTp30YGMhHXGKRQqgrGAitB2wEnAOVTWVoB4p5SINm6g8KxrRDwETPkAxy7Y15Uyhs9 ytRvX3ZT16KlL4WcZaFH9Zzh7VJ9EiCVUQ+fIYKhGrDCfyjGwujgCtqKmpl5uCYecGff KaggWLCKhx+gA7pLBCwF4yOozVDSG+3wS9R7DRS6S6TpjXEn3anz9yNWkMALUiXqgOzM L0QLx292b6gnXrbWV7fRMzkgaj3fbp7ti134CCGXnTPgETHediGHNAiswQRWQtQe+1O4 5vQw== X-Gm-Message-State: AKGB3mJQvV6sKGsu5YeTeOjgQm48u9WpStbshgct/bJnxeM3wLDFp2y6 wJ0saBehp5mwWDIB/IvtCdddvA== X-Google-Smtp-Source: ACJfBosbaKXXnycfuxPWPwtKANesCmC2LEH7q/Q2EFeV8RgRAH0WkKd42AyA0aMGyDfmqGQOG+VKGg== X-Received: by 10.176.24.195 with SMTP id d3mr13501927uah.63.1514332075486; Tue, 26 Dec 2017 15:47:55 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.3.68 with SMTP id 65ls3003615vkd.8.gmail; Tue, 26 Dec 2017 15:47:53 -0800 (PST) X-Received: by 10.31.170.1 with SMTP id t1mr2484339vke.4.1514332073430; Tue, 26 Dec 2017 15:47:53 -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:36371 Archived-At: ------=_Part_19434_1842324615.1514332072916 Content-Type: multipart/alternative; boundary="----=_Part_19435_1713699576.1514332072916" ------=_Part_19435_1713699576.1514332072916 Content-Type: text/plain; charset="UTF-8" > > 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. > Would the enforcement of preventing copy-on-write implementations for std::basic_string be an ABI-breaking change? It certainly would change some assumptions about performance in certain cases. Also, in the same way, couldn't we consider the shift to enforcing default assignment operators for std::pair and std::tuple be a quality improvement, given that it helps in obtaining the transitivity of trivial copyability? 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. > Then what about the fact that each copy/move constructor/assignment could be deleted and still maintain trivial copyability? Or the fact that at least one of them must not be deleted? In the former case, due to the wording of "non-trivial," MSVC implemented it as requiring all copy/move constructors/assignments to be defined and defaulted, and the change in the wording breaks that assumption. In the latter case, lib(std)?c++ was okay with all of them being deleted, which is a far more severe breakage in that class previously considered trivially copyable are no longer so after the wording change. > Why? How in the world does this change affect you? There are some memory guarantees I want, in such a way that sizeof(type) would be an accurate estimation of its memory usage. The property of trivially copyable types in being memcpy-able is a perfect fit for deducing the most general cases. Other than that, it's a performance guarantee. Like pointed out in the old discussion , if I have a std::vector>, I would like it to be as efficient as std::vector, where MyPairOfInts is a trivially copyable struct containing two ints. It also means that copying such trivially copyable types around can use some optimized memcpy-like function instead of copying over each internal field. On Tuesday, December 26, 2017 at 1:54:41 PM UTC-8, Nicol Bolas wrote: > > 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/39606695-51a7-46d6-874d-0ddb99fabf0e%40isocpp.org. ------=_Part_19435_1713699576.1514332072916 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 wr= ong direction in most cases. They were a formal part of C++11.

Would the enforcement of preventing copy-on-write= implementations for std::basic_string be an ABI-breaking change? It certai= nly would change some assumptions about performance in certain cases. Also,= in the same way, couldn't we consider the shift to enforcing default a= ssignment operators for std::pair and std::tuple be a quality improvement, = given that it helps in obtaining the transitivity of trivial copyability?= =C2=A0

No, that's different. It was never the inten= t to make types with deleted destructors be trivially copyable. That was me= rely a mistake; fixing it had nothing to do with library variance.=C2=A0
<= div dir=3D"ltr">=C2=A0
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.
=C2=A0
T= hen what about the fact that each copy/move constructor/assignment could be= deleted and still maintain trivial copyability? Or the fact that at least = one of them must not be deleted? In the former case, due to the wording of = "non-trivial," MSVC implemented it as requiring all copy/move con= structors/assignments to be defined and defaulted, and the change in the wo= rding breaks that assumption. In the latter case, lib(std)?c++ was okay wit= h all of them being deleted, which is a far more severe breakage in that cl= ass previously considered trivially copyable are no longer so after the wor= ding change.
=C2=A0
W= hy? How in the world does this change affect you?=C2=A0
There are some memory guarantees I want, in such a way that si= zeof(type) would be an accurate estimation of its memory usage. The propert= y of trivially copyable types in being memcpy-able is a perfect fit for ded= ucing the most general cases.

Other than that, it&= #39;s a performance guarantee. Like pointed out in the=C2=A0old discuss= ion,=C2=A0if I have a std::vector<std::pair<int, int>>, I w= ould like it to be as efficient as std::vector<MyPairOfInts>, where M= yPairOfInts is a trivially copyable struct containing two ints. It also mea= ns that copying such trivially copyable types around can use some optimized= memcpy-like function instead of copying over each internal field.

On Tuesday, December 26, 2017 at 1:54:41 PM UTC-8, Nicol Bolas wrote= :
On Tuesday, = December 26, 2017 at 4:33:10 PM UTC-5, mr...@google.com wrote:
Could we possibly consid= er it a defect to be fixed?

A defect = fix from 6 years ago which requires a possibly ABI-breaking change to imple= mentations? 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 forma= l part of C++11.

Making such a change as a defect = fix is not going to make implementers more likely to make those ABI-breakin= g 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 copyabl= e" 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 jus= t took a while for them to work out a fix for it. Lastly, making such a cha= nge does not require breaking the ABI of any library implementation.
<= div>
coul= dn't we consider it a fix to clear up this ambiguity? After all, even n= ow we have slight differences (MSVC has std::pair<int, int> as trivia= lly copyable).

Differences between im= plementations are expected; that's (part of) why we have different impl= ementations instead of just pointing at a codebase and saying, "that&#= 39;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 mor= e trivial/trivially copyable wherever 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/39606695-51a7-46d6-874d-0ddb99fabf0e= %40isocpp.org.
------=_Part_19435_1713699576.1514332072916-- ------=_Part_19434_1842324615.1514332072916-- .