220 36373 <1ea1e6b6-321c-47b4-ba97-945daecf992f@isocpp.org> 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 16:32:14 -0800 (PST) Lines: 153 Approved: news@gmane.org Message-ID: <1ea1e6b6-321c-47b4-ba97-945daecf992f@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> <39606695-51a7-46d6-874d-0ddb99fabf0e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_19669_316424259.1514334734996" X-Trace: blaine.gmane.org 1514334623 32018 195.159.176.226 (27 Dec 2017 00:30:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Dec 2017 00:30:23 +0000 (UTC) Cc: mrpi@google.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBD6URPJAKGQEFXCTG7Q@isocpp.org Wed Dec 27 01:30:18 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 1eTzbq-0007kY-E9 for gclcip-std-proposals@m.gmane.org; Wed, 27 Dec 2017 01:30:14 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id x135sf2019457vke.10 for ; Tue, 26 Dec 2017 16:32:17 -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=wv/rduTrtmr+0LXgvilv+b1JTkQbuep+kDGawS5HQnk=; b=fERaZeM/QRKrVu5algWb6Pc905lzGFeJsusYsHHLk0JZ6OgKH/uolo99kUL6jSLXGu YACgXQ8lfI4EZVVqCf/rW7xHPp1133xqqkx8C0WEsbTm9fHzQ2innMPAJ+vfK13Ov6fh PuTpkRRAXNSiunoGcIAXeUkMt7wo+E/FS0UcKJ8/tPBHT8j1AGxtb3MibTOsYpv1YGkC pbpLMLMgpktfM2GXtiuDXUIJbu1vSobe6qQGNqozogT9gme069lTLGN7mtvUyMXm8X0Y QrGCGVfJikM3AOd4w/JvFNihv14noEMGoVdiomtRLDiQ+p4RMJ/eaoeabXZ4cpjOXYbQ yUgw== 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=wv/rduTrtmr+0LXgvilv+b1JTkQbuep+kDGawS5HQnk=; b=Yn1F3vmrlOATjwps99BD342O+60bD4vvjSbFBj0UO7wcDA5DA0drj3c2LulRyLftVM 2f0O4bSEXGxKx/sc6oRhqK8iNBnqnATDA4nwWdX5bUID0xxLpz2lR13B0pbQVe/OiVeC XnbY08OZpF/tDlFPwbZ9I4mnu1TKZ+MdCJ/Q1ltxUmiqTBmzuHn0ITLWNFJLTCOrjlMd vA1lfoT6SPo/JCuhaVqHP3PzezK+WN3VYCSjdOCrVDRakDqC9oB/pey5lXAqt6XNORcA aMfgvpU7CFroryQ0xG8dt5g/dtZwK0uk6SDF2PCsZJpvK3CTNUyTv8dL9IJvO7CfsIbn W6sw== 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=wv/rduTrtmr+0LXgvilv+b1JTkQbuep+kDGawS5HQnk=; b=IuS8g2+BEoL4ys8mGh/Hf8Y5GixL4xfSd5bwt04gyE00BduG4b3lxHA3sBUt40l+B/ atx/blkFASVcKOHAGIaoHeA1f7BrQ+AnKx8C9zmijqj/jmHQizjvNmigJsOIXotMAw6Y wPWw1ziwZoD8P/4SLmr8bmZjv9aQr43QQYLj5VBG1ZwQ+Z3EWotcUhy8jCVTB4BkKMKn Gplt71P5RjRtGxlVZ/s5+7/E55jcnQXYDrMWxq3KLZ5jrxoXOkZ+mp5DUMXEl8sQs545 bX7fJ6gBsAoVtof8d5/xgBAM52Aa9VGNmWslcWPaqX+N/ads4rf1RHlsxo5h7x/sa9rZ AjPg== X-Gm-Message-State: AKGB3mKjQZsgZ41xoSiBAOh5f6ajuRpvatkAvXVuoY77xjs0S3JK3JnY nJo4A3gX4x2AyJLuAliKW2+dGg== X-Google-Smtp-Source: ACJfBot4+f0eQRbg4OMD+g5GXoSODcHNxB7dlgbnoM+mqm2ammmlOCNUQ/Rj49OJ86eMuu+hJBTXDg== X-Received: by 10.176.14.10 with SMTP id g10mr13836007uak.31.1514334737039; Tue, 26 Dec 2017 16:32:17 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.171.19 with SMTP id u19ls3223145vke.9.gmail; Tue, 26 Dec 2017 16:32:15 -0800 (PST) X-Received: by 10.31.61.149 with SMTP id k143mr2479384vka.7.1514334735518; Tue, 26 Dec 2017 16:32:15 -0800 (PST) In-Reply-To: <39606695-51a7-46d6-874d-0ddb99fabf0e@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:36373 Archived-At: ------=_Part_19669_316424259.1514334734996 Content-Type: multipart/alternative; boundary="----=_Part_19670_2120470870.1514334734996" ------=_Part_19670_2120470870.1514334734996 Content-Type: text/plain; charset="UTF-8" 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/1ea1e6b6-321c-47b4-ba97-945daecf992f%40isocpp.org. ------=_Part_19670_2120470870.1514334734996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, December 26, 2017 at 6:47:52 PM UTC-5, mr...@g= oogle.com wrote:
The changes to `std::basic_string` which prevent COW implementations w= ere not considered "defects", even though I would certainly consi= der COW implementations "quality" in the wrong direction in most = cases. They were a formal part of C++11.

<= div>Would the enforcement of preventing copy-on-write implementations for s= td::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 ch= ange some assumptions about performance in certain cases. Also, in the same= way, couldn't we consider the shift to enforcing default assignment op= erators for std::pair and std::tuple be a quality improvement, given that i= t helps in obtaining the transitivity of trivial copyability?

But it would not be a defect<= /i> 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 me= re defect report & fix. It would have to be a genuine feature of an act= ual language version, like forbidding COW strings.
=
N= o, that's different. It was never the intent to make types with deleted= destructors be trivially copyable. That was merely a mistake; fixing it ha= d nothing to do with library variance.=C2=A0
=C2=A0
Also, that defect was first reported in 2013; it just took a w= hile for them to work out a fix for it. Lastly, making such a change does n= ot require breaking the ABI of any library implementation.

Then what about the fact that each copy/move co= nstructor/assignment could be deleted and still maintain trivial copyabilit= y? 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 a= s requiring all copy/move constructors/assignments to be defined and defaul= ted, and the change in the wording breaks that assumption. In the latter ca= se, lib(std)?c++ was okay with all of them being deleted, which is a far mo= re severe breakage in that class previously considered trivially copyable a= re 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 w= ording are those that deleted their destructors. People generally do= n'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/1ea1e6b6-321c-47b4-ba97-945daecf992f= %40isocpp.org.
------=_Part_19670_2120470870.1514334734996-- ------=_Part_19669_316424259.1514334734996-- .