220 36632 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: Mon, 15 Jan 2018 10:41:44 +0100 Lines: 393 Approved: news@gmane.org Message-ID: References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <4270ffec-ccc7-4abd-836d-213db296be84@isocpp.org> <08cecc11-e902-4542-a827-53dc45a125d5@isocpp.org> <4e25f92e-bd17-42e4-9a33-68916ae380d6@isocpp.org> <9ec7a895-af7b-43d3-b47a-b7c95ed8660b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113fbfc61f37650562cd6cc4" X-Trace: blaine.gmane.org 1516009197 5273 195.159.176.226 (15 Jan 2018 09:39:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2018 09:39:57 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRBWXO6HJAKGQETOOS45I@isocpp.org Mon Jan 15 10:39:53 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f69.google.com ([209.85.214.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eb1F1-0000Vy-7Q for gclcip-std-proposals@m.gmane.org; Mon, 15 Jan 2018 10:39:43 +0100 Original-Received: by mail-it0-f69.google.com with SMTP id b11sf155951itj.0 for ; Mon, 15 Jan 2018 01:41:47 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1516009307; cv=pass; d=google.com; s=arc-20160816; b=ez6U8JSZ+kc4bVmOf7JGc8GWcIegEEpIBahRzjYk84NmR5kI3EInYp5Bh/te1JYtUZ AzRuJnH8UEtkz45C92zFagjYNe1Z2xQSIhLjIQjnUtASToj6oIRNaNQRd21h1xRUjXVf zbwPjqujgKQPrdMgdoW1cxQjXWHA4VhXXTTs079heje427p7Zhn9MvOlfWBytLjEEfLl eg+twK5fg+tTH1n4aur8g8vCRKIcMbE1Tb/MCvXpoXEFdV01sHF4cxmMmVEIsUHw7qsZ 12hazS3FMmRHKVHcIPLINmhv2I/yhG3Hq5dmEomI+wviSoNVi89WiPu6pFCfOlx8RckH qPJw== 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=IUExJYoi2lL3p8rSCMy2d971FTfrWnpA7QaASV7wss8=; b=cIvp2xsdEVBcSC2LvR39x6FSarQWujZdJNB23EhwBuuWbhYDWcluQ+CoxTanyVVXsb KnaxPBiiI6eSBY5X4FLYE6rxYJItcr2n6uxDyMlvpSaW85MRo1kMm2UOeVxBYGIGgs4s rW1ApV5NtLiNG0HJjzHDYA8jkGOj2NrnzPiAjN0uMvjRKBPfOjeWEA1Zuybrtes+/ss0 YgPYOGlqeCAmTCfOr41EVuxQb7LzhrLb1b4grSzVSLGuF3vZRT7M0RQ0n4wPN4vsl8v+ 9qNIjKGpnHNIn79qu9/8OdfglbVqHvWA84G/7w2KgGco0IaVnX4xmYAMtoI3phFRwKL2 CCfA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZZ4QMylk; 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=IUExJYoi2lL3p8rSCMy2d971FTfrWnpA7QaASV7wss8=; b=uGjmH9qFrafszbp39P7iZqsAYyL65uwtCVECyJKwFHO3oulCrBCPFQ6GZWHRJ3zbvK SW4T73pNNVbKlXjG6veE85lMjrByGH4bHvKM1AtJpSzxHegA7qaK04dVgTlgp/Eyosyi ferOAEZxDKmhx4qcc+ffJM+jb3V1+bO4Hb3DJKeuxz/sgqEwW9I0XAlUWaA1t3e/zIsP FFsyvGAmKICFYMZ9EWGDoddSKVRpj0QTnB5jsJ5963Y7U/ctBMwVzxw1lH/wYWe1ym9a mN9A0i1k+hJ6I0AgW/DHjBQ6e+31F2oJf+wTPePhRZe3VHE6AGNK7+IvkQsURegnJidl 8/ww== 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=IUExJYoi2lL3p8rSCMy2d971FTfrWnpA7QaASV7wss8=; b=UL/Yj1V1MRolUuP+9xT4T45vYNInLbrfi0+QAFTIcVhWgc0mrXKEB726TjfxMWPOAc +CuOETaapBZ1tlPABD8b3xd5YbgiRv7+dM8SOwn1+Cx9sChxnCs3D61wLO72iB+0MXUz CR3u+yGcfV5KEjpbk4JTpzuv8rp3HZIfFlw63hnwiCUJs4hA4CX81Tl9RLnJTloQjdNH xp6Qt3wLBV15j5xjG+W79vQHwxLSf3g/rDZ31xnPR8wN5QrHs2t1sF/zuqNdzPA7Wxa1 9IvpPrynvlpSXSG5Hd0S7nT/t+fHrsUIIbn/xQJ/xS+cqs33fzpxD4Fzuz5sR9xpH4jk mtcg== X-Gm-Message-State: AKwxytd71ceA/FfWpoGjO8/6vU3UyaaKp+kmDinr1KCKD/yjHuUH/WcO PiquuQV3hhV2EcS4dFriNqSNjQ== X-Google-Smtp-Source: ACJfBovhsMg6cpAWEFzgDf1URzisc4zyscDMSADFtgF9DJh9Yl39bQV88Q9Db0ubmySbSEeu6nIOlw== X-Received: by 10.36.182.74 with SMTP id d10mr9616104itj.54.1516009306974; Mon, 15 Jan 2018 01:41:46 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.11.32 with SMTP id v32ls34772ioi.17.gmail; Mon, 15 Jan 2018 01:41:45 -0800 (PST) X-Received: by 10.36.145.208 with SMTP id i199mr13264304ite.81.1516009305767; Mon, 15 Jan 2018 01:41:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516009305; cv=none; d=google.com; s=arc-20160816; b=YlKUahhoVvrLZs6A/CwyjNn3Rms6YhXC49oUsnVDi1oDfQfu7PDNaQgIiPlfFhRbpj 9VNT6Pu87dcTqZIv5iK0TpzUv7EWh85RhluCLqiC2WbAeTcUw7xK1QhzsbmA3Wm6Yn+m ES0Mp2ovnYN4pWU7/ZVWGhKB9THiqlts6JLOKfmFpALBOhN3H3hwHZtw2WfIEH8m73H2 HckN0DvR06wgfDQxFkWxaLwOzgGall2lmn4WOlXp3i6cUalkagV21c71em9ut5ijv4/X NXU4c2F+I0aggdGVnklwUfMcrr0XaeMARSUZF5x8E3oAyHm7rkIVP8czO+6UVtjlgRP+ MyZQ== 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=GMQXoAXVMWV+vxz+v7cnSEEEgpUnq54C31EZcA3HO1g=; b=eB4H9sY6cuyfKpmov5cWPMbPlQgkrY2u7zcvIyH1bv3r1rRyR5AkkYVi3HkvMKmuub E/oPLcHMkZhafpmwwKMi+0WQ1cJOiwIbwugYSU5thQpC6tWWWWO0D5xtdUtOCr1h6+0r 9EdRXg4qyqRHbXyAP8yM22ooNkMqw94NqlrovnX3J5/zX9o+zUm0UIvzz42mKWHKPm/x kQnQKxBmdIS509SaV/s8Wy8Q1fGE6QKZR1V85ItNE2K3fBEhHUvL4tMdIcbc1z0sNNgz LSFhEkHVAjvPoUiaE12iUGKYRadN4qFIWi7Be09RD7XCgjxoqEWRkfcpOF3wnJB5Uf3q Ynrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZZ4QMylk; 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 n204sor14337392ion.229.2018.01.15.01.41.45 for (Google Transport Security); Mon, 15 Jan 2018 01:41:45 -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.107.135.208 with SMTP id r77mr13234693ioi.248.1516009305354; Mon, 15 Jan 2018 01:41:45 -0800 (PST) Original-Received: by 10.2.126.75 with HTTP; Mon, 15 Jan 2018 01:41:44 -0800 (PST) In-Reply-To: <9ec7a895-af7b-43d3-b47a-b7c95ed8660b@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=ZZ4QMylk; 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:36632 Archived-At: --001a113fbfc61f37650562cd6cc4 Content-Type: text/plain; charset="UTF-8" > The point is, not want *can't* be done (the cases which will not be possible), but what *can* be done. Covering the trivial cases alone is not only better then nothing, but will actually amount to 95% of the cases needed to be covered in the first place. Absolutely, unequivocally, this ^^ It is a travesty and a failure of the language specification that UB is allowed into programs accidentally when it is perfectly possible to detect it at compile time. It makes a mockery of any claim of "compile-time safety" which we constantly strive for with template constructs such as variant. On 15 January 2018 at 10:27, wrote: > > > On Monday, January 15, 2018 at 1:54:32 AM UTC+2, Nicol Bolas wrote: >> >> >> >> On Sunday, January 14, 2018 at 3:44:10 PM UTC-5, mihailn...@gmail.com >> wrote: >>> >>> >>> >>> On Sunday, January 14, 2018 at 9:05:44 PM UTC+2, Nicol Bolas wrote: >>>> >>>> On Sunday, January 14, 2018 at 11:34:42 AM UTC-5, mihailn...@gmail.com >>>> wrote: >>>>> >>>>> On Sunday, January 14, 2018 at 6:03:45 PM UTC+2, Nicol Bolas wrote: >>>>>> >>>>>> ... >>>>>> ... >>>>>> >>>>> >>>> And it's that "difference" that I'm saying shouldn't happen. If you >>>> want a static analyzer to find bugs, that's great. But the standard should >>>> not require it, nor should the standard be getting in the way of that >>>> process. >>>> >>> >>>> The standard should be about the actual language. >>>> >>> >>> Yeah, but things like attributes are not about the language. And that is >>> OK. If there is an attribute which will help you enforce correct code, why >>> not have it? >>> >> >> If attributes aren't "about the language", then why are they defined* by >> the language*? And how do you explain P0840? >> >> ... >>>> >>>> You're thinking about it backwards. If people frequently keep writing >>>> code like that, then on some level, they want to write it that way. It's >>>> natural for them to. So you can either slap them in the face and make them >>>> stop, or you can just* make it legal* and make it do what they expect. >>>> >>>> Yes, making it legal properly is infinitely harder than just slapping >>>> an attribute on it and calling it a day. But why should C++ keep taking the >>>> easy path to "fixing" its problems? >>>> >>> >>> I don't find the possibility of adding lifetime extensions realistic. I >>> don't mind it, but I really, really doubt it will ever be added. Is there >>> any work on in that direction? Have ever been any work on that? >>> >> >> Yes there has . But apparently, EWG didn't >> consider the cost of consistent use of such annotations to be worth the >> fixing of this problem >> >> . >> >> Not that it is without problems - we break our own rules adding that. >>> Yea, const ref already breaks it, but still. Even semantically is not very >>> accurate - a view is 'slave' to the viewed, should not control it. >>> Also, what will happen with heap allocated views? Will they fail to >>> compile and be illegal? >>> >>> But as I said, I will not fight against lifetime extensions, I just >>> don't see them coming. Ever. >>> >> Where with said attribute we can *considerably* improve the quality of >>> the user code, making the foot gun very loud. >>> >> >> Except where it doesn't, of course: >> >> auto ptr = make_shared(A{}); >> >> > You are not fair in your example. I was very specific - the attr will be > ignored for heap allocated views (which are not that widely used, if at > all). In any case an attribute can be ignored - it is just a hint - it is > whole different story if its an language extension. > > However, even for heap allocated views it will be *possible* to give a > warning if view is used after A is destroyed, where it is practically > impossible to extend the lifetime of A! > > > >> After a discussion about the "extend me" proposal idea, I investigated >> the issues with an annotation-based approach. I concluded that the only way >> to make it work would be to add the equivalent of a* third* reference >> type (whether you spell it with `&&&` or some keyword or attribute >> associated with a reference parameter, the effect is to have a thing which >> behaves much like a third kind of reference). Which means you'd have to >> make forwarding references work with such a tool... somehow. >> >> Your attribute-based annotation falls into the same trap: once you leave >> the immediate scope of the code creating the prvalue, it stops being a >> prvalue. So unless the immediate scope knows that the parameter is going to >> be used like this, it can't be annotated properly. >> > > You have to give me an example, I am not sure I understand the issue. > > My logic is very, very simple - as long as we have automatic variables > (aka predictable destruction) the compiler knows *everything* needed to > track improper use, given our specification of improper use. > Temporaries, prvalues these have semantic value to us, but in the end - it > is the compiler just rearranging the calls the dtors. All is visible to him > - he created it. > > If we, in this predictable for the compiler world, want a variable marked > so we are informed it is used before another variable from this same > predictable world, I am pretty sure the compiler can do this for us. > > The point is, not want *can't* be done (the cases which will not be > possible), but what *can* be done. Covering the trivial cases alone is > not only better then nothing, but will actually amount to 95% of the cases > needed to be covered in the first place. > > > >> >> Ultimately, I've come to believe that the only reasonable solution is >> something like `extend_me`: something which explicitly extends the lifetime >> of a temporary, which is the responsibility of the writer of the prvalue >> expression to properly use. >> >> Actually I will not be surprised if implementations start doing that by >>> themselves (warning in cases thy can verify). The question is, why the >>> initiative should always come from them? >>> >> >> Because the interaction between two rules of the standard makes this >> legal code behave in a way that is unexpected but clearly explicitly >> specified. >> > > Does not change the fact the standard not mandating warnings, it is the > implementation which must take the initiative - warning for assignment in > if statement, warning for no return, for fallthrough, for empty statements, > etc etc. These save lifes for pros and juniors alike. > > Ironically all the standard did is a way to turn these warnings off if > they do not match the intend. However, how about the standard turning > warnings on (in cases impl. agree are implementable). > Granted [[deprecated]] is such an example but, that is way too little, > compared to what it is possible. > > > Sure it is better to make this code illegal, but what if it is not > possible or too hard? As the saying (in my language) goes - [*It is] > better [to have a]sparrow in the hand, then an eagle in the sky.* > > -- > 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/9ec7a895-af7b-43d3- > b47a-b7c95ed8660b%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/CALvx3hZZjgkjaOsXFReLmtoYib5Nzmndw9dxbCsSw2ztvTEz5Q%40mail.gmail.com. --001a113fbfc61f37650562cd6cc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0The point is, n= ot want=C2=A0can't=C2=A0be done (the cases which will not be possible),= but what=C2=A0can=C2=A0be done. Covering the trivial cases alone is not onl= y better then nothing, but will actually amount to 95% of the cases needed = to be covered in the first place.

Absolutely, unequivocally, this ^^=

It is a travesty and a failure of the language spe= cification that UB is allowed into programs accidentally when it is perfect= ly possible to detect it at compile time.

It = makes a mockery of any claim of "compile-time safety" which we co= nstantly strive for with template constructs such as variant.
<= div>


On 15 January 2018 at 10:27, <mihailnajdenov@gmail.com><= /span> wrote:


On Monday, January 15, 2018 at 1:54:32 AM UTC+2, Nicol Bolas= wrote:


On = Sunday, January 14, 2018 at 3:44:10 PM UTC-5, mihailn...@gmail.com w= rote:


On Su= nday, January 14, 2018 at 9:05:44 PM UTC+2, Nicol Bolas wrote:
On Sunday, January 14, 2018 at = 11:34:42 AM UTC-5, mihailn...@gmail.com wrote:
On Sunday, January 14, 2018 at 6:03:45 P= M UTC+2, Nicol Bolas wrote:
...
...
=

And it's that "difference" that I'm s= aying shouldn't happen. If you want a static analyzer to find bugs, tha= t's great. But the standard should not require it, nor should the stand= ard be getting in the way of that process.

The st= andard should be about the actual language.
Yeah, but things like attributes are not about the language. A= nd that is OK. If there is an attribute which will help you enforce correct= code, why not have it?=C2=A0

I= f attributes aren't "about the language", then why are they d= efined by the language? And how do you explain P0840?

=
...

<= div>You're thinking about it backwards. If people frequently keep writi= ng code like that, then on some level, they want to write it that way. It&#= 39;s natural for them to. So you can either slap them in the face and make = them stop, or you can just make it legal and make it do what they ex= pect.

Yes, making it legal properly is infinitely = harder than just slapping an attribute on it and calling it a day. But why = should C++ keep taking the easy path to "fixing" its problems?

I don't find the possibility = of adding lifetime extensions realistic.=C2=A0 I don't mind it, but I r= eally, really doubt it will ever be added. Is there any work on in that dir= ection? Have ever been any work on that?

<= /div>

Not that it is without problems - we break our own rules adding tha= t. Yea, const ref already breaks it, but still. Even semantically is not ve= ry accurate - a view is 'slave' to the viewed, should not control i= t.
Also, what will happen with heap allocated views? Will they fa= il to compile and be illegal?=C2=A0

But as I said,= I will not fight against lifetime extensions, I just don't see them co= ming. Ever.
Where with said attrib= ute we can considerably improve the quality of the user code, making= the foot gun very loud.
=C2=A0
Exce= pt where it doesn't, of course:

auto ptr =3D make_shared<A_view>(A{});


You are not fair in your example. I was very sp= ecific - the attr will be ignored for heap allocated views (which are not t= hat widely used, if at all). In any case an attribute can be ignored - it i= s just a hint - it is whole different story if its an language extension.

However, even for heap allocated views it will be <= i>possible to give a warning if view is used after A is destroyed, wher= e it is practically impossible to extend the lifetime of A!
=C2=A0
=C2=A0
After a discussion about the "extend me&qu= ot; proposal idea, I investigated the issues with an annotation-based appro= ach. I concluded that the only way to make it work would be to add the equi= valent of a third reference type (whether you spell it with `&&a= mp;&` or some keyword or attribute associated with a reference paramete= r, the effect is to have a thing which behaves much like a third kind of re= ference). Which means you'd have to make forwarding references work wit= h such a tool... somehow.

Your attribute-based ann= otation falls into the same trap: once you leave the immediate scope of the= code creating the prvalue, it stops being a prvalue. So unless the immedia= te scope knows that the parameter is going to be used like this, it can'= ;t be annotated properly.

You have to give me an example, I am not sure I understand the issue.

My logic is very, very simple - as long as we have a= utomatic variables (aka predictable destruction) the compiler knows ever= ything needed to track improper use, given our specification of imprope= r use.
Temporaries, prvalues these have semantic value to us, but= in the end - it is the compiler just rearranging the calls the dtors. All = is visible to him - he created it.

If we, in this= predictable for the compiler world, want a variable marked so we are infor= med it is used before another variable from this same predictable world, I = am pretty sure the compiler can do this for us.

Th= e point is, not want can't be done (the cases which will not be = possible), but what can be done. Covering the trivial cases alone is= not only better then nothing, but will actually amount to 95% of the cases= needed to be covered in the first place.

=C2=A0

Ultimately, I've come to believe that the only r= easonable solution is something like `extend_me`: something which explicitl= y extends the lifetime of a temporary, which is the responsibility of the w= riter of the prvalue expression to properly use.

Actually I will not= be surprised if implementations start doing that by themselves (warning in cases thy can verify). The question is, why the initiative sh= ould always come from them?

Bec= ause the interaction between two rules of the standard makes this legal cod= e behave in a way that is unexpected but clearly explicitly specified.

Does not change the fact the= standard not mandating warnings, it is the implementation which must take = the initiative - warning for assignment in if statement, warning for no ret= urn, for fallthrough, for empty statements, etc etc. These save lifes for p= ros and juniors alike.=C2=A0

Ironically all the st= andard did is a way to turn these warnings off if they do not match the int= end. However, how about the standard turning warnings on (in cases impl. ag= ree are implementable).
Granted [[deprecated]] is such an exampl= e but, that is way too little, compared to what it is possible.
<= br>

Sure it is better to make this code illegal, b= ut what if it is not possible or too hard? As the saying (in my language) g= oes - [It is] better [to have a]sparrow in the hand, then an eagle in the s= ky.

--
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/9ec7= a895-af7b-43d3-b47a-b7c95ed8660b%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/CALvx3hZZjgkjaOsX= FReLmtoYib5Nzmndw9dxbCsSw2ztvTEz5Q%40mail.gmail.com.
--001a113fbfc61f37650562cd6cc4-- .