220 36408 article Path: news.gmane.org!.POSTED!not-for-mail From: Patrice Roy Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: The current attribute/keyword dividing line is unsustainable. Date: Wed, 27 Dec 2017 18:47:28 -0500 Lines: 272 Approved: news@gmane.org Message-ID: References: <86919454-9af9-4b08-b7b3-fd262b46cdd5@isocpp.org> <40edf1b5-5c72-4682-902e-1c0cea581e37@isocpp.org> <3c34aa3e-bf47-4d4f-be71-522c7cc0a9bf@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f4030435ae78b71ad505615b0547" X-Trace: blaine.gmane.org 1514418333 29501 195.159.176.226 (27 Dec 2017 23:45:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Dec 2017 23:45:33 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDSZXMHWZIKBBEXCSDJAKGQE4LHBE5Q@isocpp.org Thu Dec 28 00:45:28 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f200.google.com ([209.85.213.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eULO4-0007NU-Ba for gclcip-std-proposals@m.gmane.org; Thu, 28 Dec 2017 00:45:28 +0100 Original-Received: by mail-yb0-f200.google.com with SMTP id i77sf12871443ybg.15 for ; Wed, 27 Dec 2017 15:47:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1514418451; cv=pass; d=google.com; s=arc-20160816; b=ypgilEW7rButUACwo4oQA0XUT0pxcNiPayqCBU/z4R6V9cURVShN2XVeZ40CiYVYd7 Y94K5SILrSpDI4tmwVq9Z6IUWAvBqTMnbtlSq2ftY97cwSDom6HcX8onn4WAlyeYq+rm KQg46h6srmFePs95NwQeNVfYaOWcBBCH+HHGJojeoW2R3+tbmz5kDHMIq7eiZgbTC2t6 cwJaZKKmE+9I18N2q0i8ZGxOlb/HkJS6DvH83dFKanwIRAzMNq0Oq5LYM31mpWn3Rch9 QY2ciE6ESWbYL5qlvSAGJPdkhuxWIOvqOhVXh1FPCeM95Yolzc9AVssrpe7r4qan5L9t 1bcA== 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=0EhVPrPLfWfAM3j4QWmkWJgJ0JhAnkntbtkslUIuVGs=; b=akzuFvRcpD9cZv9ONGskq02p4HzRnX8xcavIbFQ2vrbMcbiJlXp787XuJvh8PhupG1 y7+ABvwg4cOOxn0cek7cwd9hCGTdu76oD3ow/SjW9VFUsxtyi42WG1uTMuBWy6E/YQKD aEEq2ZiawGkm6jnHWVugJCgDSjGhHOYwFuHWjVOkol9/jwFSOlf5it7J2OpF8J4Drg2h uA9A7bKHUEaL68dj2XRdqE3WuIuL8CPN0IayE/KnAyXDICB5LXQxIZf/h+7+2q9r+zgH ankEnjojXnQUjO8li6ksuWO5qAM2NadNNkzqCJCLZiDg7PeFDGXStqzbSVnwwnFkhwn7 NLAA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Jefhim4q; spf=pass (google.com: domain of patricer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=patricer@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=0EhVPrPLfWfAM3j4QWmkWJgJ0JhAnkntbtkslUIuVGs=; b=M9s0ZInk8VbIUAdDBcF6E9F0yLmn+QZNrgxso01OQJMRPBIT+knxXuRHGHAu0Oayea gn2wJbcj7MLr7nDMer/yKdEboQccfiHg+H2aemg65jmP0OijPHdgOTzATJFvBiI9IiYP 9bKfxEJ+fZkePHnEaE9Y0hSNHyThWe8A10nVqTLBgrPt/TvoF4kHdlW2hVe3iFZVX/ii 3cn9+40B+ByZhDM+V+1RNnPktbxyiCTUgUP1TcMbXsaqGwmYamRUOkzrjR3txWqznSo9 GvK5/TfwKLGEw1YKKUskdk72yqKdl3hA6QKoTjAxw6CSH0ty+WGbEtQ6aChTaWoj8v28 ilpQ== 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=0EhVPrPLfWfAM3j4QWmkWJgJ0JhAnkntbtkslUIuVGs=; b=SyvxRX0KszqwMTOgGVwjCFd5xZmQScNWTyvubvLI3CGAKhmuF3NCGj4vOyPR2YghlP SvfzC1fdHFTC60iTqwxTlyRs7C0LtF5UK7iJhnguh9ju4tWdhhWEH5nSZnJR0wMMioME tbeUAMfvkiAUQ71gcfi+CcFzyEw9a8zdmWMQY1r4tJqfE8/F3t0YdUzq2nh1eLz9OAn/ DaZ9yyrfpwsW+ljXPrFm2upHrgRtbO4aebwmHbj83UmQXggyLGo3CbH6I/+R2iJA6UX3 NfOy5/t+fJ98UFgTc4d9EVmZq8slHY2Io9XQWgUfRD3zazzSm3jCTjejSrDT/SBZPFe6 XRDQ== X-Gm-Message-State: AKGB3mLw9UWJ8VkmVuQLuePB2VVtmzUrqTj03QmtG67E13cQ1tu7bGxE CY3ZpLkSprrqg+5A142Knhf6iA== X-Google-Smtp-Source: ACJfBovW7qK1FeyNLA5B4/GH6mpLl9VRUgEoiSHnnQ7sobybF/cQvXr8Hyjd8CpAiAWbcPtpsrF6BQ== X-Received: by 10.129.102.6 with SMTP id a6mr9147574ywc.32.1514418450942; Wed, 27 Dec 2017 15:47:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.129.120.212 with SMTP id t203ls574230ywc.17.gmail; Wed, 27 Dec 2017 15:47:29 -0800 (PST) X-Received: by 10.37.50.131 with SMTP id y125mr12602005yby.467.1514418449816; Wed, 27 Dec 2017 15:47:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1514418449; cv=none; d=google.com; s=arc-20160816; b=s4X7Hxd4etvx3i+nmF2Cp1gRm9wCLQkBfju+6Ilz/oOg7mGTyWZplL45Z6Y0x7P8s3 KFRbr0je+qEwtN1iVGzG/WyfE2SieckZa33MPuG9DyOfZ0DXH9Lu+/NapLEglPQJLOBY hU4nqT7I+zDd36O5BdQiAE8s7ETVsBKNcRiJqCsQiaVPQNUiYCkL4dQKyPUg5d4N//kq qd81h8Q6+IjN5mEVeQibvNbZkHluwwSq0AUkgHRVOLE43OSqRqiLpw89MtNZt5eLr/eL AnzYl2aNrzPhDNxuilNQAxBY2yIdkSf1WsioQX5TIFheZP/SVoEJqX3CzxbplIfuYKwi wlHw== 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=UYaXm+gG9vTTrD0E4lbyqVRG/6LfF7j6o73g70MrySM=; b=i4VJNpezP73ODvx9lpsRJjNV2XzuMdBNr4aMSGbZPfNTnn7p23l8DwqycWP1YuqyqG 4u5QnUMfYBLevjKQe4PU9SVt1YK83B/IVZ0dpNQsULQEd4d4hI4SbVOqlDVx0x/m9pAt 6fu7euuPN10gGSHexDJXUBIuvJKuzmauLpnG1pZ0tcmwO+i0vUIhymVCPyGEt8OlAWWV sVtPAAVaOqtlA0EzJiEyZm5BvQ/XkD0l7DctNwm7u4P7nY/ltn1b6oacFX3ZLiA5R4Ja RcoJJgrXpb7TVu5wS3OHg/1KX0aKUB+w55PZSdokzT6UZ1FoC8UJDCCgUjvFfb5jzFJn hnrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Jefhim4q; spf=pass (google.com: domain of patricer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=patricer@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 z8sor8323823ybi.33.2017.12.27.15.47.29 for (Google Transport Security); Wed, 27 Dec 2017 15:47:29 -0800 (PST) Received-SPF: pass (google.com: domain of patricer@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.37.45.85 with SMTP id s21mr8032224ybe.513.1514418449355; Wed, 27 Dec 2017 15:47:29 -0800 (PST) Original-Received: by 10.37.47.133 with HTTP; Wed, 27 Dec 2017 15:47:28 -0800 (PST) In-Reply-To: <3c34aa3e-bf47-4d4f-be71-522c7cc0a9bf@isocpp.org> X-Original-Sender: patricer@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Jefhim4q; spf=pass (google.com: domain of patricer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=patricer@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:36408 Archived-At: --f4030435ae78b71ad505615b0547 Content-Type: text/plain; charset="UTF-8" Hi Nicol. I'll let others discuss a potential new language. I don't agree with you on surface issues, but the core interests me, so I'll repeat my encouragement for a paper that studies it. I think it has value. Thanks again! 2017-12-27 16:37 GMT-05:00 Nicol Bolas : > On Wednesday, December 27, 2017 at 3:35:47 PM UTC-5, Patrice Roy wrote: >> >> I don't think the stated opinion to the effect that [[fallthrough]] >> should become mandatory is shared by everyone (to some, me included, the >> potential removal of warnings is sufficient in itself), >> > > Put it this way; if you had a complete blank slate language, and for some > reason you decided this language desperately needed `switch/case`, and you > decided that fallthrough behavior was a useful feature for it... would you > make fall through the default, rather than having some actual syntax for it? > > If the answer is "no", then the next question is how we get from where we > are (default fallthrough) to a place where we can reasonably change the > language to behave the way we would prefer. And the only way to take that > step is for the fallthrough syntax to be a real part of the language, > rather than something that is conceptually ignorable. > > Now, maybe that's a step you don't want C++ to take; maybe you're fine > with the current state of having to turn on specific warnings/errors to get > that behavior for your codebase. > > But if that's a step that C++ *ever* wants to take, we will* have to* > canonize [[fallthrough]]; we would have to make it real syntax. And it > seems silly to limit ourselves into never being able to take such a step, > simply because we made an arbitrary decision about how to express the > "fallthrough" behavior, not because of the actual *feasibility* of the > change (ie: checking out how much code will be broken and so forth). > > and I don't share your reading of [[noreturn]] (there's nothing in >> [dcl.attr.noreturn] that suggests this would be meant to make >> non-[[noreturn]]-non-returning functions ill-formed). >> > > This is something of a spin-off of the "Why is C++ still allowing UB when > a return statement is forgotten?" thread. But the basic idea is similar to > the above. With `unreachable`, we have a way to tell the compiler, "Yes, I > really mean for this code path to never, ever be taken". > > Once that tool exists and is widely in use, it then becomes at least > feasible for compilers to give errors if static code paths don't return. > But the thing is, calling a `[[noreturn]]` function ought to be > conceptually identical to invoking `unreachable`; control flow* cannot* > return from that function, so that codepath cannot proceed forward. And > therefore, a code path that invokes a [[noreturn]] function ought to have > similar effects as `unreachable`: it's a code path that won't continue > forward. > > Therefore, if we should ever decide to make static non-returning paths > error, we would have to canonize `[[noreturn]]`. We would have to add a > rule saying that code paths which don't return, throw, invoke `unreachable`,* > or* call a [[noreturn]] function are the ones that cause errors. > > That no longer treats `[[noreturn]]` as ignorable syntax. > > However, the core point you are trying to make with attributes is >> interesting; would you care making a paper out of it? I might make >> interesting food for thought, should it be fleshed out with examples (in >> addition to no_unique_address]]) where the "ignorable" characteristic of >> attributes seems not to be respected. >> >> Thanks! >> >> 2017-12-27 14:44 GMT-05:00 : >> >>> Yet inline is a keyword and can be ignored and barely have "language >>> semantic meaning". Granted, that ship has sailed long ago. >>> >>> >>> In any case, you are right - [[no_unique_address]], on and off, creates >>> two different programs, granted both well-formed, but different never the >>> less. >>> >>> All other attributes so far fall into only two categories - >>> communication with the user (more errors and warnings) and turning off >>> synchronizations. >>> In neither case the program is observably (as in static checks, not >>> performance) different. >>> >>> I don't know how to feel about it. Never ever though about attributes as >>> ignorable. Ever. >>> Especially before standardization when people went to great lengths to >>> add an attribute for every compiler and every platform precisely because >>> their program depended on it. >>> Sometimes vitally (like in "it will crash in minutes otherwise"). >>> >>> >>> -- >>> 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-proposal...@isocpp.org. >>> To post to this group, send email to std-pr...@isocpp.org. >>> To view this discussion on the web visit https://groups.google.com/a/is >>> ocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e- >>> 1c0cea581e37%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/3c34aa3e-bf47-4d4f- > be71-522c7cc0a9bf%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/CAKiZDp01ysJhDsfKp0Wi2SAS7DAs_%3DFFe3mdeO%2BNu1rg0kc8rA%40mail.gmail.com. --f4030435ae78b71ad505615b0547 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nicol.

I'll let others discu= ss a potential new language. I don't agree with you on surface issues, = but the core interests me, so I'll repeat my encouragement for a paper = that studies it. I think it has value.

Thanks again!
=

2017-12-27 16:37 = GMT-05:00 Nicol Bolas <jmckesson@gmail.com>:
On Wednesday, Decemb= er 27, 2017 at 3:35:47 PM UTC-5, Patrice Roy wrote:
I don't think the stated opinion = to the effect that [[fallthrough]] should become mandatory is shared by eve= ryone (to some, me included, the potential removal of warnings is sufficien= t in itself),

Put it thi= s way; if you had a complete blank slate language, and for some reason you = decided this language desperately needed `switch/case`, and you decided tha= t fallthrough behavior was a useful feature for it... would you make fall t= hrough the default, rather than having some actual syntax for it?

If the answer is "no", then the next question is = how we get from where we are (default fallthrough) to a place where we can = reasonably change the language to behave the way we would prefer. And the o= nly way to take that step is for the fallthrough syntax to be a real part o= f the language, rather than something that is conceptually ignorable.
=

Now, maybe that's a step you don't want C++ to = take; maybe you're fine with the current state of having to turn on spe= cific warnings/errors to get that behavior for your codebase.
But if that's a step that C++ ever wants to take, we= will have to canonize [[fallthrough]]; we would have to make it rea= l syntax. And it seems silly to limit ourselves into never being able to ta= ke such a step, simply because we made an arbitrary decision about how to e= xpress the "fallthrough" behavior, not because of the actual f= easibility of the change (ie: checking out how much code will be broken= and so forth).

and I don't share your r= eading of [[noreturn]] (there's nothing in [dcl.attr.noreturn] that sug= gests this would be meant to make non-[[noreturn]]-non-returning functions = ill-formed).

This is som= ething of a spin-off of the "Why is C++ still allowing UB=C2=A0when a = return statement is forgotten?" thread. But the basic idea is similar = to the above. With `unreachable`, we have a way to tell the compiler, "= ;Yes, I really mean for this code path to never, ever be taken".
=

Once that tool exists and is widely in use, it then bec= omes at least feasible for compilers to give errors if static code paths do= n't return. But the thing is, calling a `[[noreturn]]` function ought t= o be conceptually identical to invoking `unreachable`; control flow cann= ot return from that function, so that codepath cannot proceed forward. = And therefore, a code path that invokes a [[noreturn]] function ought to ha= ve similar effects as `unreachable`: it's a code path that won't co= ntinue forward.

Therefore, if we should ever decid= e to make static non-returning paths error, we would have to canonize `[[no= return]]`. We would have to add a rule saying that code paths which don'= ;t return, throw, invoke `unreachable`, or call a [[noreturn]] funct= ion are the ones that cause errors.

That no longer= treats `[[noreturn]]` as ignorable syntax.

= However, the core point you are trying to make with attributes is interesti= ng; would you care making a paper out of it? I might make interesting food = for thought, should it be fleshed out with examples (in addition to no_uniq= ue_address]]) where the "ignorable" characteristic of attributes = seems not to be respected.

Thanks!

2017-12-27 14:44 GMT-05:00 <mihailn...@gmail.com>:
<= div>Yet inline is a keyword and can be ignored and barely have "langua= ge semantic meaning". Granted, that ship has sailed long ago.=C2=A0


In any case, you are right -=C2=A0[[n= o_unique_address]], on and off, creates two different programs, granted bot= h well-formed, but different never the less.

All o= ther attributes so far fall into only two categories - communication with t= he user (more errors and warnings) and turning off synchronizations.
=
In neither case the program is observably (as in static checks, not pe= rformance) different.=C2=A0

I don't know how t= o feel about it. Never ever though about attributes as ignorable. Ever.
Especially before standardization when people went to great lengths= to add an attribute for every compiler and every platform precisely becaus= e their program depended on it.
Sometimes vitally (like in "= it will crash in minutes otherwise").=C2=A0

<= br>

--
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-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.o= rg.
 To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-pr= oposals/40edf1b5-5c72-4682-902e-1c0cea581e37%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-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/3c34= aa3e-bf47-4d4f-be71-522c7cc0a9bf%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 https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp01ysJh= DsfKp0Wi2SAS7DAs_%3DFFe3mdeO%2BNu1rg0kc8rA%40mail.gmail.com.
--f4030435ae78b71ad505615b0547-- .