220 38486 <8365b751-0310-4199-8be7-d6222b078aff@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Restricting the valid use of certain methods upon temporary objects Date: Mon, 4 Jun 2018 21:30:58 -0700 (PDT) Lines: 184 Approved: news@gmane.org Message-ID: <8365b751-0310-4199-8be7-d6222b078aff@isocpp.org> References: <81b39e17-fe78-41ab-b9c9-3b830e32dbf5@isocpp.org> <709f2ceb-5059-4217-8475-288a8f4ecd44@isocpp.org> <48ae754e-18c0-4350-922b-8b6faac0df16@isocpp.org> <73c26f59-2aa0-4d89-b783-ebf73282a0bf@isocpp.org> <1ff61a56-191f-49c2-849d-b3bb47b52930@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_38184_1693041824.1528173058786" X-Trace: blaine.gmane.org 1528172957 12790 195.159.176.226 (5 Jun 2018 04:29:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Jun 2018 04:29:17 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBA5E3DMAKGQEB5YIP4I@isocpp.org Tue Jun 05 06:29:13 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f198.google.com ([209.85.213.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQ3ap-0003CE-Lm for gclcip-std-proposals@m.gmane.org; Tue, 05 Jun 2018 06:29:11 +0200 Original-Received: by mail-yb0-f198.google.com with SMTP id h29-v6sf843131ybj.22 for ; Mon, 04 Jun 2018 21:31:22 -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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=xXTqVCwZ/uuT7pLlNQQSnihzpJNZun2ueWyR1zOM7Og=; b=XUIk9pyW1UtaJ5YoGukUGbN1BKmnsEGRyPHZiLqG48eBnqDbpI7Rj6GhPuL9hNpGlS JrCKPgq0CT84hDP7+xxDcXBe7wyCUh0E1sshSGHqmw9Q+7iuXDDyflxRyjHwOS9Sjplg bPVuQDyr96tOPaUlyEHGDCYwEZbk/mQ9en3MZ7AOOSOCkz+iRkdcqOQ2mCrClNg038bQ Xe3XrXG5YJFXUOTrA9j1zrlgwvPqzOqKtL7MweHh1ULpx4Nk6o9iXA9a4YHWQVfFe9Vp VghA53/8HwxaRTOkuHPyjloVmU0M57Uo4Nqz1GywmXR6jBqV2ugm7x4jCUq3ZVNz0FVb dwLw== 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=xXTqVCwZ/uuT7pLlNQQSnihzpJNZun2ueWyR1zOM7Og=; b=ZNXQRTRSc6MzbVA2wtQAezYrlUIdilYImXiIFaHrLR7OQG5zTmDF1R4uV8qBTdOOqQ QB1nw7QnfnzR5UW9t49Xxj3phUrtbnPPDB7dMamzWxCGm6Nzc4LgN2Pbn/BWRgYKTvUP WjdTHaalVPRnfU4DfLH9xXcpHWa4Xm29YYkAer8E6rt5n7julhC2pTKlY00dTQeNULsk Z2ATjPJKjUqww/G8WZuB6Fxzzc/cywxNQ6oXaJ7Aqq/xsw8CfcB7nEVR72oguP0rO6AJ Jc5nvorHAvV3jeTRw+FZkYPg2GCq+j2t8FfKcs4d9ZVe/s5G3/+5D/xxwqbQrpaBjeUh wv2w== 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=xXTqVCwZ/uuT7pLlNQQSnihzpJNZun2ueWyR1zOM7Og=; b=XLma8Tu7RK46n/fnPGCnnwHzo8cEQqQAn72ZJNb3A6GL4TV7EISEII6yQ3omgFxCiO 8vkV56bqYTj1I0MmMmludKEjMz73ZI11LlKEuEvjbAXxus5zQkBssm4tXZqXRajHTt9e M8mlAfM/KQwqrpXAU5dXmFFdJ8j/qwm6IhwLsM/bKJTxIfcdY861dCBaVVxu+vGwzy/r BTkx4WwxDEd06R8UuDpYiOCoEznNYv6OypYegvxtMaPY5LI+hcKEzjG1x04Jehe70JY0 iULO8XdwulGc/os/6tY1Mv4i3tX9YMSlc3y1ffA9tVnLwsk7N+B9bNttUdvEoGEDGrSb 8rQQ== X-Gm-Message-State: APt69E24MUjBHIFT19IyT3nzGb7r163rSeBMi1rKtbIAE8OQaXmHxAKa 4hY+12BI06/7Ge8M//tpsBCDzw== X-Google-Smtp-Source: ADUXVKLlG3VtCUDBjq1U3nlOsRysK85DgsuvHhWvDam+6B+x2XRro68P2R+W/2kotWUtw76mdNaguA== X-Received: by 2002:a81:ed10:: with SMTP id k16-v6mr1244384ywm.68.1528173082434; Mon, 04 Jun 2018 21:31:22 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:c0cf:: with SMTP id c198-v6ls2511118ybf.16.gmail; Mon, 04 Jun 2018 21:30:59 -0700 (PDT) X-Received: by 2002:a25:aaa1:: with SMTP id t30-v6mr65244ybi.13.1528173059334; Mon, 04 Jun 2018 21:30:59 -0700 (PDT) In-Reply-To: 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:38486 Archived-At: ------=_Part_38184_1693041824.1528173058786 Content-Type: multipart/alternative; boundary="----=_Part_38185_1761327257.1528173058787" ------=_Part_38185_1761327257.1528173058787 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, June 4, 2018 at 8:29:41 PM UTC-4, Gareth Lloyd wrote: > > So after a long walk today I finally have been able to point at what make= s=20 > me uneasy about the lifetime extension approach. In short, if we depend= =20 > upon more than one lifetimebound object which are temporaries, then as it= =20 > currently stands they are unsequenced. Consider the following example: > =E2=80=8B=20 > > #include #include > struct Foo > { > static int counter; > =20 > std::string s; > =20 > Foo(std::string const & _s) : s{_s + std::to_string(counter++)}=20 > {=20 > std::cout << "ctr " << s << '\n'; > } > ~Foo(){std::cout << "dtr " << s << '\n';} > }; > int Foo::counter =3D 0; > auto f0(Foo const & foo1 /*lifetimebound*/, Foo const & foo2 /*lifetimebo= und*/) > { > return [&](){std::cout << foo1.s << '-' << foo2.s << '\n';}; > } > int main() > { > using namespace std::string_literals; > auto x =3D f0("a"s, "b"s); > x(); > } > > With or without lifetime extension, the temporaries that foo1 and foo2 ar= e bound to have undefined sequence of construction. This is a=20 > problem for temporaries as it currently is, but if we enhance lifetime ex= tension and encourage the use of temporaries then this will=20 > possibly be a common pitfall. > > I don't see how this would be any more of a problem in the future than it= =20 is now. If `f0` didn't store those temporaries in the return value, they=20 would still "have undefined sequence of construction" relative to one=20 another. Yet people write code that constructs multiple temporaries in=20 function parameters *all the time*. So I fail to see how the possibility of= =20 such faults will be significantly raised by lifetime extension. --=20 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 e= mail 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/8365b751-0310-4199-8be7-d6222b078aff%40isocpp.or= g. ------=_Part_38185_1761327257.1528173058787 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, June 4, 2018 at 8:29:41 PM UTC-4, Gareth Lloyd = wrote:
So afte= r a long walk today I finally have been able to point at what makes me unea= sy about the lifetime extension approach. In short, if we depend upon more = than one lifetimebound=20 object which are temporaries, then as it currently stands they are unsequen= ced. Consider the following example:
=E2=80=8B 
#include <string>
#include <iostream>

struct Foo
{
    static int counter;
   =20
    std::string s;
   =20
    Foo(std::string const & _s) : s{_s + std::to_string(counter++)}=20
    {=20
        std::cout << "ctr " &l=
t;< s << '\n';
    }
    ~Foo(){std::cout <<=
; "dtr "=
 << s << '\n';}
};

int Foo::counter =3D 0;

auto f0(Foo const & foo1 /*lifetime=
bound*/, Foo con=
st & foo2 /*lifetimebound*/)
{
    return [&](){std::cout << foo1.s << '-' << foo2.s << '\n';};
}

int main()
{
    using namespace std::string_literals;
    auto x =3D f0("a"s, "b"s);
    x();
}



With or without lifetime extension, the temporaries that fo=
o1 and foo2 are bound to have undefined sequence of construction. This is a=
 
problem for temporaries as it currently is, but if we enhance lifetime=
 extension and encourage the use of temporaries then this will 
possibly=
 be a common pitfall.

<= div>I don't see how this would be any more of a problem in the future t= han it is now. If `f0` didn't store those temporaries in the return val= ue, they would still "have undefined sequence of construction" re= lative to one another. Yet people write code that constructs multiple tempo= raries in function parameters all the time. So I fail to see how the= possibility of such faults will be significantly raised by lifetime extens= ion.

--
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/8365b751-0310-4199-8be7-d6222b078aff= %40isocpp.org.
------=_Part_38185_1761327257.1528173058787-- ------=_Part_38184_1693041824.1528173058786-- .