220 36374 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 16:58:37 -0800 (PST) Lines: 239 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> <39606695-51a7-46d6-874d-0ddb99fabf0e@isocpp.org> <1ea1e6b6-321c-47b4-ba97-945daecf992f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19845_339820878.1514336317799" X-Trace: blaine.gmane.org 1514336203 20046 195.159.176.226 (27 Dec 2017 00:56:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Dec 2017 00:56:43 +0000 (UTC) Cc: mrpi@google.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDH2LIF7UEOBBP7ARPJAKGQEOBMUBPQ@isocpp.org Wed Dec 27 01:56:39 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 1eU01N-0004nc-On for gclcip-std-proposals@m.gmane.org; Wed, 27 Dec 2017 01:56:38 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id 7sf23733357uap.5 for ; Tue, 26 Dec 2017 16:58:40 -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=+DltE0CwRRR71YisQcM2je76lXLRCJreA2D1n6AHjYM=; b=DrE/CdMZ4LoH34BOKdSfPejkrxIG8L9rJXdfpVo2zx39sRXrblt6IjvGgJS4qb2MxY YLvgJCKgQZKFl5TkGI52La4J4q7HHCQFuYwYiQS/fsm6Y04514LIZ0TB1fy77E2+Fhge qWNMTjPBU/g8+/mRjUAjM/vWGEZL6BCxcuzXu3WT5uUe3QPbmJ3sunW053Qz4MOjZwcp mdrz67R/ijTR7meUV9OANySPT499N/RhSNZuigv5Ia0TeF/3zeAtyUSGQkQwpz99xggE IWjmEF9jVj6npqlKkue5LC8YHcNvqDLDFdoCh10+kN6DN8/GNumVe2ZhKkZNqkb8ICwD hHsA== 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=+DltE0CwRRR71YisQcM2je76lXLRCJreA2D1n6AHjYM=; b=rCHl38uoCPawW414FsY9iWYH5dwlVysgbB3/qfujJwIeLq7Nt7kHR+QyIdweuVI5jj tMxj4a1KQw1cKaGUvDzWBa7keFrXTYwZJs1w9Lo8Wi4rjBfTiL+kLpR1BHlFg+cS7gq5 H/LZu1VLbMcUQNJrHQDc/A5/LbzBQ62JQypjkE6w3yMG2TnxcDMwsACxbNZQCkTOcbsy sdvT3mXevP9HUyWRORtHm/9G7TNxsFa1iGOIjRooUdmh3qhJXpZEY4ixBQItIMzTdPW8 zm2xeLn4G5JJTdDp8CWwvnF8yf9rJZrb6tFrPvazypKKM29IwFxej6r+SMBB6/EXC538 wL8g== X-Gm-Message-State: AKGB3mIpsFNM5dfBN9KKI1xlxderV8EL43X7b/aZe/ecxq31ILfBWeGQ tUQb1TBLopiwySva6/PnjyPT4w== X-Google-Smtp-Source: ACJfBovaKl9wPL7b5ji1GYUaKTSZbIwuQ7p+Z2QWV4Swh8GMIgnb7Bjww5wAq/iHN0Z/p6SmJfTIow== X-Received: by 10.31.237.129 with SMTP id l123mr13361286vkh.121.1514336320363; Tue, 26 Dec 2017 16:58:40 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.63.208 with SMTP id m199ls3134419vka.14.gmail; Tue, 26 Dec 2017 16:58:38 -0800 (PST) X-Received: by 10.31.96.72 with SMTP id u69mr2485283vkb.11.1514336318296; Tue, 26 Dec 2017 16:58:38 -0800 (PST) In-Reply-To: <1ea1e6b6-321c-47b4-ba97-945daecf992f@isocpp.org> 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:36374 Archived-At: ------=_Part_19845_339820878.1514336317799 Content-Type: multipart/alternative; boundary="----=_Part_19846_379493373.1514336317799" ------=_Part_19846_379493373.1514336317799 Content-Type: text/plain; charset="UTF-8" > > But it would not be a* defect* change; that's what we're talking about. > The magnitude of such a change is such that it's not something that's > reasonable for a mere defect report & fix. It would have to be a genuine > feature of an actual language version, like forbidding COW strings. > I see. Thanks for making that clear! In that case, how difficult would it be to push for a proposal to have a feature in, say, C++20 to forbid custom/non-trivial copy/move assignment operators for std::pair and std::tuple? > None of those are ABI changes. Are you sure you have an understanding of > what an ABI change would be? > Maybe I'm misunderstanding it, but I thought it was a change in some core, possibly internal, behavior of the library, in such a way that backwards compatibility is difficult if not impossible. For example, in the std::basic_string case, the lack of COW means people can no longer rely on the relatively trivial copying if the string is unchanged. The opposite of an ABI breakage would be to simply add additional functionality and leave the original ones alone. I guess that's the wrong way to think of it. What does it mean to be an ABI change then? > Also, the only classes which would lose trivial copyability under the new > wording are those that deleted their* destructors*. People generally > don't do that. > Not really. The condition that at least one copy/move constructor/assignment must be non-deleted was only added afterwards by defect report 1734. Originally, classes that were both non-copyable and non-movable were, under the lib(std)?c++ implementation, considered trivially copyable until the change in wording. And such classes, although relatively rare, do exist. For example, I recall there was this regex library that had a class with trivial members and had neither a copy nor move constructor/assignment, and it has lost its trivial copyability from the wording change. On Tuesday, December 26, 2017 at 4:32:15 PM UTC-8, Nicol Bolas wrote: > > On Tuesday, December 26, 2017 at 6:47:52 PM UTC-5, mr...@google.com wrote: >> >> 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? >> > > Almost certainly yes. I'm not an expert on COW string implementations, but > I'm not sure that it's reasonable for a COW `basic_string` to have the same > internal representation as a non-COW version. And even if they could, they > certainly wouldn't have the same ABI as an SSO-based `basic_string`, which > means that's an optimization you would be unable to provide. > > 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? >> > > But it would not be a* defect* change; that's what we're talking about. > The magnitude of such a change is such that it's not something that's > reasonable for a mere defect report & fix. It would have to be a genuine > feature of an actual language version, like forbidding COW strings. > > 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. >> > > None of those are ABI changes. Are you sure you have an understanding of > what an ABI change would be? > > Also, the only classes which would lose trivial copyability under the new > wording are those that deleted their* destructors*. People generally > don't do that. > -- 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/f3a9fa10-0ea8-4715-8cbc-328f01410f34%40isocpp.org. ------=_Part_19846_379493373.1514336317799 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But it would not be a=C2=A0defect=C2=A0ch= ange; that's what we're talking about. The magnitude of such a chan= ge is such that it's not something that's reasonable for a mere def= ect report & fix. It would have to be a genuine feature of an actual la= nguage version, like forbidding COW strings.

I see. Thanks for making that clear! In that case, how di= fficult would it be to push for a proposal to have a feature in, say, C++20= to forbid custom/non-trivial copy/move assignment operators for std::pair = and std::tuple?
=C2=A0
None of those are ABI= changes. Are you sure you have an understanding of what an ABI change woul= d be?

Maybe I'm misunde= rstanding it, but I thought it was a change in some core, possibly internal= , behavior of the library, in such a way that backwards compatibility is di= fficult if not impossible. For example, in the std::basic_string case, the = lack of COW means people can no longer rely on the relatively trivial copyi= ng if the string is unchanged. The opposite of an ABI breakage would be to = simply add additional functionality and leave the original ones alone.

I guess that's the wrong way to think of it. What = does it mean to be an ABI change then?
=C2=A0
Also, the= only classes which would lose trivial copyability under the new wording ar= e those that deleted their=C2=A0destructors. People generally don= 9;t do that.

Not real= ly. The condition that at least one copy/move constructor/assignment must b= e non-deleted was only added afterwards by defect report 1734. Originally, = classes that were both non-copyable and non-movable were, under the lib(std= )?c++ implementation, considered trivially copyable until the change in wor= ding. And such classes, although relatively rare, do exist. For example, I = recall there was this regex library that had a class with trivial members a= nd had neither a copy nor move constructor/assignment, and it has lost its = trivial copyability from the wording change.

On Tuesday, December = 26, 2017 at 4:32:15 PM UTC-8, Nicol Bolas wrote:
On Tuesday, December 26, 2017 at 6:47:52= PM UTC-5, mr...@google.com wrote:
The changes to `std::basic_string` which prevent C= OW implementations were not considered "defects", even though I w= ould certainly consider COW implementations "quality" in the wron= g direction in most cases. They were a formal part of C++11.

Would the enforcement of preventing copy-on-write i= mplementations for std::basic_string be an ABI-breaking change?
=

Almost certainly yes. I'm = not an expert on COW string implementations, but I'm not sure that it&#= 39;s reasonable for a COW `basic_string` to have the same internal represen= tation as a non-COW version. And even if they could, they certainly wouldn&= #39;t have the same ABI as an SSO-based `basic_string`, which means that= 9;s an optimization you would be unable to provide.

It cer= tainly would change some assumptions about performance in certain cases. Al= so, in the same way, couldn't we consider the shift to enforcing defaul= t assignment operators for std::pair and std::tuple be a quality improvemen= t, given that it helps in obtaining the transitivity of trivial copyability= ?

But it would not = be a defect change; that's what we're talking about. The mag= nitude of such a change is such that it's not something that's reas= onable for a mere defect report & fix. It would have to be a genuine fe= ature of an actual language version, like forbidding COW strings.

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.=C2=A0
=
=C2=A0
Also, that defect was first reported in 2013; it j= ust took a while for them to work out a fix for it. Lastly, making such a c= hange 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 trivia= l copyability? Or the fact that at least one of them must not be deleted? I= n the former case, due to the wording of "non-trivial," MSVC impl= emented it as requiring all copy/move constructors/assignments to be define= d and defaulted, and the change in the wording breaks that assumption. In t= he 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 triviall= y copyable are no longer so after the wording change.

None of those are ABI changes. Are you s= ure you have an understanding of what an ABI change would be?
Also, the only classes which would lose trivial copyability und= er the new wording are those that deleted their destructors. People = generally don't do that.

--
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/f3a9fa10-0ea8-4715-8cbc-328f01410f34= %40isocpp.org.
------=_Part_19846_379493373.1514336317799-- ------=_Part_19845_339820878.1514336317799-- .