220 28025 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Specifier to cause the destructor to be called at last use instead of end of scope Date: Mon, 29 Aug 2016 13:38:08 -0700 (PDT) Lines: 145 Approved: news@gmane.org Message-ID: References: <4387866d-169e-44a8-a858-d9aa96d54680@isocpp.org> <85dfd0dc-bf1a-4fa8-81f5-2b36e8f6465c@isocpp.org> <57C48794.6020105@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_543_1234584666.1472503088435" X-Trace: blaine.gmane.org 1472503097 31442 195.159.176.226 (29 Aug 2016 20:38:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2016 20:38:17 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBMN2SK7AKGQEVKZZQAQ@isocpp.org Mon Aug 29 22:38:12 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1beTJr-0007iF-CL for gclcip-std-proposals@m.gmane.org; Mon, 29 Aug 2016 22:38:11 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id o3sf1310666ita.0 for ; Mon, 29 Aug 2016 13:38:12 -0700 (PDT) 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:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=q1dmm8Pcjv+L2mTcCTFzSiEtiodkKXc4YFclHKWLAXI=; b=m3Yr9dlTS+I9Bd02UwN0CHjgw994Vh1qLcbQLyOFUANDlaaSK7A5htMqxkx/PGVGh9 syWr3DdQytqd8R42s7CHfGhSkHy98bmHwRfQnJiaV+TasO5QuisSg6jdtVgzmbUTZn5h l4/4QxWzVNEv2HbZr8IcJEd6W9T6bEf0pmzzP0xISvUNcqqUvyE5OEzLNDX2UvXCf+ui IXbYzL/MMQ3Iq/gB3sW53QpYoszWPz5Q6b2egPe+lBwRZSkXtoMvqab7ye0fRWLkIrAj +iXf0mQ1x9tdieyUSHOUAUwiMwOFLCIRTeZ9ZFydlrcN7C6ehCHpZC/HgaWGsn7nrMyX Z3gw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=q1dmm8Pcjv+L2mTcCTFzSiEtiodkKXc4YFclHKWLAXI=; b=ix8HO7gZOXMIeE5weqEY/FPn67tiPI9/2spQoVn2Iu+BSQoCUwj3pj7hQ+0d54JX4l WUcy484VGxWc7Yh3vi9UozlN7ssG17O25ZSqjFzCbxh4toPyPie4+6IV/UQYb8Fk7F5V f0W4N2WBSNx0QozNzgj+uWLsKsb6zmx2Qj4+WyV4sa1H8lDYJJVtjEARtIxjcBGwtNx7 akH6NoN62R/znKyI0mZv5RBgUZQnHBNP/QBg1jUMHzYJ4UVjF4RjQ84VWIXMkHQ1JzCZ 5clWt9Anmtu/t/252Rgzt29g3hYK0Bk/hEFuaasQVpUWNNVXjKSwBM13OZZs5hDBK7Cx QqYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=q1dmm8Pcjv+L2mTcCTFzSiEtiodkKXc4YFclHKWLAXI=; b=VxnDk4llPrJ16AlRd+tw599l7eZlEp9RzgKN5KkVfaZV+oKU24w6xtEz/JMuCTdFvt PWahTlcMuwC7Ae7V1n+rwjwHg5LhWyltpBKpSUsFVnGrpvfigzsGIMtKhGBHu9gn40QN V+k7Z6MwTzmDCVmefL88mo0oQEwxMSLe4QtOfOfejI46uNk1ZzTFJ+B8UrDWYaXYov7d hNgph5U3HwgFcfjr7WcBP/EwHVYjiO7onniR1BluVuNTetQ8GuEjFub5qYkNZal2As9k LndBft3xpK5eLVw9eQIsViGU2u9zga+xxS1q/oMEz8jErKoIoX8VnhWEKdEe+q0W8Uzq j/aw== X-Gm-Message-State: AE9vXwPe/ixXxboHc/WgXhFK+QrO9Aeu0qFWq3VlYDqHvO3YhzCsNxbbHggsraHgqTnTVw== X-Received: by 10.157.37.39 with SMTP id k36mr15389075otb.38.1472503091880; Mon, 29 Aug 2016 13:38:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.227.9 with SMTP id d9ls36308ith.15.gmail; Mon, 29 Aug 2016 13:38:09 -0700 (PDT) X-Received: by 10.36.107.194 with SMTP id v185mr24897itc.10.1472503089435; Mon, 29 Aug 2016 13:38:09 -0700 (PDT) In-Reply-To: <57C48794.6020105@gmail.com> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:28025 Archived-At: ------=_Part_543_1234584666.1472503088435 Content-Type: multipart/alternative; boundary="----=_Part_544_1114345054.1472503088436" ------=_Part_544_1114345054.1472503088436 Content-Type: text/plain; charset=UTF-8 On Monday, August 29, 2016 at 3:05:59 PM UTC-4, Matthew Woehlke wrote: > > On 2016-08-29 14:46, Nicol Bolas wrote: > > This problem is fundamentally identical to the temporary lifetime > extension > > problem. Namely, that this works: > > > > const auto &str = std::string(...); > > //use str > > > > While this does not: > > > > const auto &str = std::string(...).c_str(); > > //use str > > I think having explicit temporary types might help here: > > std::string::c_str() -> char const* register; // declaration > > // error: taking reference of register-qualified type. > const auto &str = std::string(...).c_str(); > > Obviously, it is too late to change std::string this way, but it would > help us write better API's going forward. How would that solve the problem? How does the compiler connect the return value's lifetime to the lifetime of one of the function parameters?* Which* parameter should it connect it to? All of them? And why would you use `register` of all things for that? > Specifically: > > > The compiler does not and *cannot* know, in all cases, whether a > > return value of a function contains a pointer/reference to an > > argument or an element of an argument. > > ...it would be a way to solve this. > > On 2016-08-29 14:52, Nicol Bolas wrote: > > So now you want `const virtual register` qualifiers on variables? Do we > > *really* need that? > > Well... *yes*. For exactly the reason given above. Making it a qualifier > makes it possible to actually *solve* some of these problems, at least > by making them explicitly ill-formed rather than just subtly broken. > P0066 provided a more comprehensive solution to lifetime analysis. And it was ultimately rejected .. -- 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/a90060ce-0316-4c11-b123-9326cf91b16d%40isocpp.org. ------=_Part_544_1114345054.1472503088436 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Monday, August 29, 2016 at 3:05:59 PM UTC-4, Matthew Wo= ehlke wrote:
On 2016-08-29 14:4= 6, Nicol Bolas wrote:
> This problem is fundamentally identical to the temporary lifetime = extension=20
> problem. Namely, that this works:
>=20
> const auto &str =3D std::string(...);
> //use str
>=20
> While this does not:
>=20
> const auto &str =3D std::string(...).c_str();
> //use str

I think having explicit temporary types might help here:

=C2=A0 std::string::c_str() -> char const* register; // declaration

=C2=A0 // error: taking reference of register-qualified type.
=C2=A0 const auto &str =3D std::string(...).c_str();

Obviously, it is too late to change std::string this way, but it would
help us write better API's going forward.

How = would that solve the problem? How does the compiler connect the return valu= e's lifetime to the lifetime of one of the function parameters? Whic= h parameter should it connect it to? All of them?

And why would = you use `register` of all things for that?
=C2=A0
Specifically:

> The compiler does not and *cannot* know, in all cases, whether a= =20
> return value of a function contains a pointer/reference to an=20
> argument or an element of an argument.

...it would be a way to solve this.

On 2016-08-29 14:52, Nicol Bolas wrote:
> So now you want `const virtual register` qualifiers on variables? = Do we=20
> *really* need that?

Well... *yes*. For exactly the reason given above. Making it a qualifie= r
makes it possible to actually *solve* some of these problems, at least
by making them explicitly ill-formed rather than just subtly broken.

P0066 provided a more comprehensive solution to life= time analysis. And it was ultimately re= jected.

--
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/a90060ce-0316-4c11-b123-9326cf91b16d= %40isocpp.org.
------=_Part_544_1114345054.1472503088436-- ------=_Part_543_1234584666.1472503088435-- .