220 36698 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Hodges Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Static analysis and the future of C++ Date: Thu, 18 Jan 2018 15:40:55 +0100 Lines: 329 Approved: news@gmane.org Message-ID: References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <6e78f3c4-267d-40c4-bcde-a026e90c3838@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113f836c9a27fb05630df390" X-Trace: blaine.gmane.org 1516286365 24050 195.159.176.226 (18 Jan 2018 14:39:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 18 Jan 2018 14:39:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRB6PDQLJQKGQEZKTYJMA@isocpp.org Thu Jan 18 15:39:21 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecBLC-0004at-Mm for gclcip-std-proposals@m.gmane.org; Thu, 18 Jan 2018 15:38:55 +0100 Original-Received: by mail-io0-f197.google.com with SMTP id b184sf7698095iof.21 for ; Thu, 18 Jan 2018 06:40:58 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1516286458; cv=pass; d=google.com; s=arc-20160816; b=M1gVBO1zv1/RpuoRyqTW0O5p1jEeMgjjpepAD40E6TLK9lfTRuKkRb6fA/TrfUps8F RsRqFAyXN4nTIVi9QZ4/jCV2pMExRJpRQu0P7sO07udcoFtTwDN9zaTGobWCQFfAPWHu xzIDMzv8cWAUBRJwidXX2LbziQ93+FWWv4oZJ40n2w6B3XSFnyQZMOQZv7kOHc48Q2v+ 6fZ5ENvFXDh4tsA0jnMlo6A1GufW77boISqcIIeNaChCjHCCnCS9eQBgVG1P2DHTu0ad YUnns3RbNuSyjENJeGL2s6qaUwyepsiAjpcCrzP6zYaDiOHfkiZpVIzU7XLRud1de6VP aBcw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=H+7jghJb8LsaUeFUpT/LkahD+nYOS0KTCzFlxR0JQCU=; b=R5s8JzyoTnpWojOpFuY8rB02WU7ai7BnzKuzXSWnsC1hgrBnVb0P+whuTZlLe2A1E5 ncD9ncSCP46LNU/4lwszkD/fdlouZpJOke31acQIT3QGKFipJw2Uyql1Awxg8qRJLcdK 7Pei5aAB2bSSjK/YCNm5eizsvS1K+JFUZ6FHnBfAv4bpGUHJckOyBnzpOQmE5I4uuumW lyWR0Ua+4Xc7wnkgGIoMjFZjnCX28XpTyBVcJHuapqiLin7I3goY5L4c8Oa0FabJhjdT 5veLD6LjYtRhAZNk6D+SeAs2I5hekYs7UtRyntskCsk/0Z3xfCluBPkr+ue6wavCb/cG /XMw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nXDDJyhM; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=H+7jghJb8LsaUeFUpT/LkahD+nYOS0KTCzFlxR0JQCU=; b=FVuOBlenTAbzLFystdecc/Lx+JgQBG+nh5EbTtpyz4Z8+hYvnWQBweqTFlwCrAr0s6 qTXlPX2xZqSyizp74nzEsBQXae/YCi2XlY/yfCY/Id0BBNUlCHgg0mCWMfKRb57dNEfi BUJM9qNuJru+eFSKDsVzG08H24lK/ft24H3Xr9jipJfWLDoKMIvwafjzamtV8wMX9Ra6 a6r6A8wIuC1GI2DSKu4TJbA0IMwtFDVGD+XE7dYcBGPoYVyLoxrHFo/qb8pYKKoR0y4w ZWKZq550LQH1gRTu0IDi232shjw8JVSNMZ8pqn1F9dehuLZUfGUtRFSuKK9G3Z8spAsc P1mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=H+7jghJb8LsaUeFUpT/LkahD+nYOS0KTCzFlxR0JQCU=; b=DpXDp2f7cRhv1pqXyFPsXV1BBr+UUVPO3vBjMzj5hRi42hs2IsDtsmU9IB0z6tPPBd glGS2BLoTpsYegaJYh5eV+Ey91NaVJN9cOnhW5V5wKwYSxpa60uBtJbLq9prH70uzziX 5UGZI+Rlhj5Iv6Z8HlOZB+1fyFH6/ExsZqh8XcGHyURBAXlXD2mCCW2n5qhmh3e4PycT TWiMuGm5JEr2Xz+BSpaJntmdQXOMi3XIp+Lt2oIZWx2l+7ePYSZ/Fr3TarJ6z58UdqNV ljxretq/UJ6QSAv6GttnesuGV7x9wev4/OBc+KFz2qHBfVOntNg5UfY3wszemupLivKX c0gg== X-Gm-Message-State: AKwxytfkMvUx6LF2an6/ClIL/JB9lfFj360ANBycaOCQBNv1PwPOOwe8 yWPyoTaU8DADzC545eJyGYIb6w== X-Google-Smtp-Source: ACJfBotH0tsymseaTXwQJCrYuZaANrleXCehFzgfCjvKZIG+2iN1h6Q5Mz1sHa+oHQ3RJ7OKYXM+cQ== X-Received: by 10.36.41.138 with SMTP id p132mr17906963itp.13.1516286458185; Thu, 18 Jan 2018 06:40:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.41.131 with SMTP id p125ls391608itp.0.canary-gmail; Thu, 18 Jan 2018 06:40:56 -0800 (PST) X-Received: by 10.107.16.8 with SMTP id y8mr26218996ioi.213.1516286456869; Thu, 18 Jan 2018 06:40:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516286456; cv=none; d=google.com; s=arc-20160816; b=0mXqw1VFdtakEe+jrkzIk6gp1A2SORut781qQFPrW0lcCNfbdeT+fOWn1VGpDkZVrM /lnp/OzhFYtdJxgM83b+WXdmEq5/LgJe8Iv+Glo9DshXDUav50xm5PaNHEK6p2eE+Nqf 9o/tEd3XlxoipCryUg4Fei2NL4xZwaERrMBXVi5St6FfvN0k3uCTrq18ottM18iDVCbL gQyYhdnodoaE4tHRb01fsRDfRIyts6WZp92c3pmfvG4debh48r3whJ86OIJCkwfKSNru Xc011R1AbJbFEFzcJDSIjSmguXh0lWgOIL2i2dxGWhpYlTclYs62SP/60ezc3Suqfc6h kZmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=NtgVmmp/LI7WezophuGCtchb8EM/fYy/McyABTQitMY=; b=FFHTJ3yvtxHlxeqA7MpuCTjxEmz8fQ8qySQtvBGO3Z7hERLUa2GkqFu9e/yrmUDK8p 21H1DrWF4s1wVGdd672GG8MMpD5LZLkRxu+qg7rUhooyri9EhGEIpDoZeYpNuPtBoHP0 c3HiYCdGmIMjp3I2BTNQeIOLLxV8fatxb9/N9cbf+Z8ahlrJ3HyWk69Dd+TC22jI1Lze 1Z7Mi795tRhaix/G8jlmChnnu4szoRpAGgzPzPaMqkjiMjysDzmSA6iu71CBrfnFYadq lIQNi7u1kIvSSCS9WM0AbPwN9Qm8jMLSFkYPRT7nwaoJBgN4KHbvIVSa69gveAeO9nyn 1svg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nXDDJyhM; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id c184sor4364313itg.7.2018.01.18.06.40.56 for (Google Transport Security); Thu, 18 Jan 2018 06:40:56 -0800 (PST) Received-SPF: pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.36.118.77 with SMTP id z74mr26144453itb.37.1516286456240; Thu, 18 Jan 2018 06:40:56 -0800 (PST) Original-Received: by 10.2.126.75 with HTTP; Thu, 18 Jan 2018 06:40:55 -0800 (PST) In-Reply-To: <6e78f3c4-267d-40c4-bcde-a026e90c3838@isocpp.org> X-Original-Sender: hodges.r@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=nXDDJyhM; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:36698 Archived-At: --001a113f836c9a27fb05630df390 Content-Type: text/plain; charset="UTF-8" On the whole I completely agree with you. However: auto up1 = std::make_unique(5); auto p = up1.get(); // dependent... auto up2 = std::move(up1); // ...sort of std::string_view should never have been implicitly convertible from std::string. Unhappily, the committee seems to favour encouraging dangerous coding practices at the moment. Consider: std::string foo(); std::string_view x = foo(); x.anything(); // boom! whereas: std::string const& x = foo(); // perfectly safe auto x = foo(); // again, safe auto&& x = foo(); // yet again IMHO proliferating reference types in the c++ standard library is a grave error which will haunt us for years. On 18 January 2018 at 13:35, wrote: > For the sake of completeness, in cases when the viewed class creates the > view, then the && overload should be marked as [[dependent_lifetime]] > > class string > { > ... > [[dependent_lifetime]] operator string_view() && { return {c_str(), > size()}; } //< (probably not the correct place to set the attribute, but > you get the idea) > }; > > Now the returned value (the variable created from it) depends on the > lifetime of *this and should not be used after *this is dtor is called. > > *Further investigation * > > Consider that case: > > void f() > { > string_view v; > > if(const auto str = getString(); str == "something") > { > v = str; > } > > // 'v' is either empty or dangles! > } > > The above mistake can happen even to an experienced programmer (if he is > used to ref-counted strings for instance). People learning C++ and junior > developers are basically guaranteed to fall in there at some point. > > Here it is *painfully* obvious the compiler knows the right usage - he > just keeps it shut! We *should* be able to make him speak. > > BTW, that is an interesting case, as it is not about initialization, but > assignment. However, does it matter? It is still clear the scope of > tracking - from assignment tor dtor. > > Even if we have a more involved case > > void f( string_view& v) > { > if(const auto str = getString(); str == "something") > { > v = str; > } > } > int main() > { > string_view& v; > f(v); > return 0; > } > > The compiler still knows all that is needed, doesn't it? As long as the > view is an automatic variable the compiler can always detected if, during > its lifetime, it is used after the pointed-to dtor is called. > Isn't that always the case? Isn't that that case even if the pointed-to is > heap allocated? > > o_view v = o_p->getView(); > > The compiler can still tell if *o_p is destroyed before v is destroyed. Am > I mistaken here? > > Considering view classes are 99.9% of the time used as automatic > variables, there is no good reason for them to be unsafe. > > (Or maybe there is, I might be missing something) > > > *And lets talk copies.* > > Nothing is actually preventing this tracking to work for copies of the > view as well - the rules are exactly the same - if before view.~view() > there is a call to object.~object() there should be no view,access(). > How many views are, it does not matter at all as long as they are > automatic. > It also does not matter if ~object() was called by the compiler > (automatic), the user (delete p_object;) or by a ref counted shared_ptr! > > With that in mind. > > void f(view vb) //< by copy > { > destroy_b_unknowingly(); > vb.use(); //< warning, dtor of b was called already > } > > *Even further investigation* > > template > class unique_ptr > { > ... > [[dependent_lifetime]] T* get() { return _p; } > ... > T* _p; > }; > > Now the variable of type T* is a view to the unique_ptr. If ~unique_ptr() > is called before the (automatic) T* variable, created/assigned by get, goes > out of scope, it will be an error to use that variable. > > But, lets take this to the next level: > > template > class unique_ptr > { > ... > [[dependent_lifetime(*_p)]] T* get() { return _p; } > ... > T* _p; > }; > > Now it is an error to use T* after ~T(), and ~T(), can come from any > place - shared_ptr, manual delete, another, moved into unique_ptr. > Everywhere. > And the rules are still the same - no use of this T* variable, after a > ~T(), until this T* variable goes out of scope ("as if" it has a dtor > called). > The relationship is still b/w an automatic variable and a dtor call. > > Am I fooling myself here? Isn't that mighty useful? Isn't that all > implementable today? What is the harm? It does not even writes off lifetime > extension and what not - it just reinforces safe use of the language, the > way this language is right now. > No new semantics, no new rules! > > > -- > 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/6e78f3c4-267d-40c4- > bcde-a026e90c3838%40isocpp.org > > . > -- 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/CALvx3hb2oDZ6VwFF-3Ra0rN29bTgtEgwtifLo2w2uzBpkm--3A%40mail.gmail.com. --001a113f836c9a27fb05630df390 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On the whole I completely agree with you.

However:

au= to up1 =3D std::make_unique<int>(5);
auto p =3D up1.get();=C2=A0 =C2=A0// dependent...
auto up2 =3D std::move(up1= );=C2=A0 // ...sort of

std::string_view should never have been implicitly c= onvertible from std::string. Unh= appily, the committee seems to favour encouraging dangerous coding practice= s at the moment. Consider:

std::string foo();

std::st= ring_view x =3D foo();
x.anything(); // boom!

whereas:
= std::string const& x =3D foo();=C2= =A0 // perfectly safe
= auto x =3D foo(); // again, safe
auto&& x =3D foo(); // yet again

IMHO proliferating reference types in the c++ standard= library is a grave error which will haunt us for years.
<= font face=3D"monospace, monospace">


On 1= 8 January 2018 at 13:35, <mihailnajdenov@gmail.com> = wrote:
For the sake of completeness, in cases when the viewed class c= reates the view, then the && overload should be marked as [[depende= nt_lifetime]]


Now the return= ed value (the variable created from it) depends on the lifetime of *this an= d should not be used after *this is dtor is called.

Further investigation

Consider that case:

void f()
{<= br>=C2=A0 string_view v;
=C2=A0
=C2=A0if(const auto str =3D getString= (); str =3D=3D "something")
=C2=A0{
=C2=A0=C2=A0=C2=A0 v = =3D str;
=C2=A0}
=C2=A0
=C2=A0// 'v' is either empty or d= angles!
}

The above mistake can happen even to an experienced programme= r (if he is used to ref-counted strings for instance). People learning C++ = and junior developers are basically guaranteed to fall in there at some poi= nt.

Here it is painfully obvious the compil= er knows the right usage - he just keeps it shut! We should be able = to make him speak.

BTW, that is an interesting cas= e, as it is not about initialization, but assignment. However, does it matt= er? It is still clear the scope of tracking - from assignment tor dtor.

Even if we have a more involved case

void f( string_vi= ew& v)
{
=C2=A0if(const auto str =3D getString()= ; str =3D=3D "something")
=C2=A0{
=C2=A0=C2=A0=C2=A0 v =3D = str;
=C2=A0}
}
int main()
{
=C2=A0string_view& v;
=C2=A0f(v);
=C2=A0return 0;
}

The com= piler still knows all that is needed, doesn't it? As long as the view i= s an automatic variable the compiler can always detected if, during its lif= etime, it is used after the pointed-to dtor is called.
Isn't = that always the case? Isn't that that case even if the pointed-to is he= ap allocated?


The compiler can still tell if *o_p is d= estroyed before v is destroyed. Am I mistaken here?

Considering view classes are 99.9% of the time used as automatic variabl= es, there is no good reason for them to be unsafe.

(Or maybe there is, I might be missing something)


And lets talk copies.

Nothing = is actually preventing this tracking to work for copies of the view as well= - the rules are exactly the same - if before view.~view() there is a call = to object.~object() there should be no view,access().
How many v= iews are, it does not matter at all as long as they are automatic.
It also does not matter if ~object() was called by the compiler (automat= ic), the user (delete p_object;) or by a ref counted shared_ptr!
=
With that in mind.

void f(view<B> vb) //< by copy
{
=C2=A0=C2=A0 dest= roy_b_unknowingly();
= =C2=A0 vb.use(); //< warning, dtor of b was called already
}

Even= further investigation

template<class T>
class unique_ptr
{
= =C2=A0 ...
=C2=A0 [[dependent_lifetime]] T* get() { return _p; }
=C2= =A0 ...
=C2=A0 T* _p;
};

Now the variable of type T* is a view to the unique_pt= r. If ~unique_ptr() is called before the (automatic) T* variable, created/a= ssigned by get, goes out of scope, it will be an error to use that variable= ..

But, lets take this to the next level:

template<class T>
class= unique_ptr
{
=C2=A0 ...
=C2=A0 [[dependent_lifetime(*_p)]] T* get= () { return _p; }
=C2=A0 ...
=C2=A0 T* _p;
};

Now it is an error = to use T* after ~T(), and ~T(),=C2=A0 can come from any place - shared_ptr,= manual delete, another, moved into unique_ptr. Everywhere.
And t= he rules are still the same - no use of this T* variable, after a ~T(), unt= il this T* variable goes out of scope ("as if" it has a dtor call= ed).
The relationship is still b/w an automatic variable and a d= tor call.

Am I fooling myself here? Isn't tha= t mighty useful? Isn't that all implementable today? What is the harm? = It does not even writes off lifetime extension and what not - it just reinf= orces safe use of the language, the way this language is right now.
No = new semantics, no new rules!


--
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-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/6e78= f3c4-267d-40c4-bcde-a026e90c3838%40isocpp.org.

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hb2oDZ6VwFF= -3Ra0rN29bTgtEgwtifLo2w2uzBpkm--3A%40mail.gmail.com.
--001a113f836c9a27fb05630df390-- .