220 36405 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: The current attribute/keyword dividing line is unsustainable. Date: Wed, 27 Dec 2017 22:40:00 +0000 Lines: 120 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="001a113adaa463e7e105615a1405" X-Trace: blaine.gmane.org 1514414285 10237 195.159.176.226 (27 Dec 2017 22:38:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Dec 2017 22:38:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBQOCSDJAKGQEZ7VBZ2Y@isocpp.org Wed Dec 27 23:38:01 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f199.google.com ([74.125.82.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eUKKl-0002DQ-G8 for gclcip-std-proposals@m.gmane.org; Wed, 27 Dec 2017 23:37:59 +0100 Original-Received: by mail-ot0-f199.google.com with SMTP id n39sf9185978otd.20 for ; Wed, 27 Dec 2017 14:40:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1514414402; cv=pass; d=google.com; s=arc-20160816; b=Rbo8DVd9KFclOVPDmT7epE2SPUInv7Pj6vshflDYD7Km4fqh3JlKTR1SnJLBK8Ez3M s0x/UwTsY1uLmvF9wYQ3TeeJDg7FgHmQsX1MsjvKOQEbZNmdtWqcDA6AucGeaiHBnsp9 vdmyK3L33pF9t/uHAwadHRWSW26YDcwy0yrGmDDd8cBfJ6+biJ9S+Fu/t6r/D641whQ4 YwhPjVzgMpJZM0rslxEfD1bWx63p0+yymP4pTkKYOENsH+894KvCN9gOWWdwYyRMSgND R8I7FDJVt7aZtR1cRub7J/xPKix4t+od5/+2DPcOghBe/ujmg5hxDAlc7arMeBe8CdER TkYQ== 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=lYyqkm2/3hJ6WCueQGYX/U26BYTaRDi40fpL7HKXCOA=; b=V6nsvia/k4xsN7s6UPH493c9GxdqnOFyN1Z7TWEHg3OeiZ4PFaDc4ZdoRLeidQ0CZH Glh/aPLuq8zg8BkZYwziWSFoIXKm1cU/A6U5BjI9BAIEN0DXLaBPyLe61Tl1EeTfkpf3 3eoDi/JYpHa+aU4Xt0yRSC+FzbHeC6hbTGZvSWjnN8RbfQp2bn/wFl8iDGffJHFfEMBT bxEbbq3KYn63UiM1+GGgCsEYwyAlMY2OL/HmJNppYDEM/OSqGzVEUuhWh2j24KQNqrtD HHj/VjA9eh672q1Gxg5LKWfyK/kcXe5G4crv12FzK+EGQ6O3Gk4qd0VAJaiFa9cb8f7q z2BA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FQkil3Cx; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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=lYyqkm2/3hJ6WCueQGYX/U26BYTaRDi40fpL7HKXCOA=; b=BZ4GpYaYLYyHk+whZA5ZGX5wlbuUD9axozXbFVDt9q0p3UfUDFw/AJHTiHnQ4ZwSxL iXkgD26KSYHlxr3NhaMiX81mS4IGHRPrEU/t6aY3d8V+qKCyQ+Cg58n9LeG5fnuSRR9H HEz7fb8VReO+OPPTc0cvGgq0k0YITo1egXJovDwOj2SrDFOsPaAjrmSwA82RLpsneoy6 bFGwuPd82mEGdTf3rcw8yoDpHlSiTxf2dBY+230GtCmRTCsqEdfN+O1WBim2cwHyNPXS mzEdKN3Mt4jJX0KacUexw4z9J7W2Ab82dQkA0Kh9OK6v/0/UiYKYox58kYyampgwBX8B RguA== 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=lYyqkm2/3hJ6WCueQGYX/U26BYTaRDi40fpL7HKXCOA=; b=LBFKiM5MQfDCaU3RyHx55wlnQYsSNVCnzYu8GELKSz4QZ8n2+V/aDNjqP4DlThiVHx KepjYRvlP5/XYBkQvnkY6d8frRnjSwRaLAAhZzXMy/Sq1UO6LQMzqCdiLj5HTZgUrY5A zD/mN82TBCt0kFvu6RrQzvYkPwF6CmouYHrGAzHIp+z6TdbxQMd7TbeGZqaxNiXoZIur gp9QGktTnhaZWI2uAtcb8LTb8W8wEkzonHyMR29/34DxYQcFO38QG2oTO35ih4YkdjLi ms51mc2zObAoXyWIEBDt46N26bes5noWH8BSCKd3txvDcUCDqjQwzTU8kLf7X8ffFKbG grDQ== X-Gm-Message-State: AKGB3mLcvx4YtTxYk4ksSAMia3lmUsll96oq5s7Z5r9YXzzh1018NqBq CoF+Jd2L6y5mlK+Dbi3zs7rvSg== X-Google-Smtp-Source: ACJfBovF7CClEJraX2EYNi8jLLnkhI1DKDqzpMrn0u6Yfv/iOZhuFstwmD79zK8KL6cWNDgYu4Bb/Q== X-Received: by 10.157.38.248 with SMTP id i53mr15691555otd.85.1514414402041; Wed, 27 Dec 2017 14:40:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.91.133 with SMTP id p127ls3532274oib.2.gmail; Wed, 27 Dec 2017 14:40:01 -0800 (PST) X-Received: by 10.157.11.75 with SMTP id p11mr2644421otd.43.1514414401062; Wed, 27 Dec 2017 14:40:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1514414401; cv=none; d=google.com; s=arc-20160816; b=YzFJOmis55d1mjZXAhygu6Dyw72nAAGF9TLYVY1fsraRJSSCi6BGlAMSrzmZuFunoZ j4oqPtDSDfwKwu/NNamqto1lZigtAxfHxUdjHqa4mC9hjWcJ4WbD6440r3x+iueVJZu9 1kH5MsDr7TK5g7SlNypzz28j8vJnJQf2cwmWKq3iqSn+JwtPTSud+BCqVRKEPe+zkmyE wa9xzyeBLzUO9E4PETcuOdbaIa0/w/cQ+YrnQRg1eQZPd/BYiSGao3B6IFSfWug2dZH8 n7AZvMAd+32qCVRNsygUC1QRltolotgZ+ObzgEAf2x2dITHyFZdvc2vzuT+ixPW45Dux MnpA== 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=UMhEZS+1w6fq8J9EPtVvbFZiqC0mRjuNn1PGoqnutB4=; b=H8J+ZeU/FxP24XM0GTMJ0K3EEITm9IEVGXr11MyJbjwQrXnh066NXBhUBWVJ5RyTUx fjBSC+I7GNsyOH/is1h0647YW7FnusMwkl5ez8wvIzGwF5JiZg47SqKoZTOOR4JMM7xY 280Pn8Rj3YA1GPpe+U8cuGToYcZmCqJ94vtCbjuCtuPF8xuSZL7pMtt0JPazcBmHScFo 5gm8zEoaMehdfdcSoj/uguTexa0hx1fYaDUkhj+PceK0PjL1WPF48XKsijM+6Lzt0Mte zP/4KSgfdETrCvWKLEfl2ni33jGOu3jdjKOYLvjVRF69KDuPPU+igSP2vkZVmxuerBEE 4rNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FQkil3Cx; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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 u138sor11387267oia.150.2017.12.27.14.40.01 for (Google Transport Security); Wed, 27 Dec 2017 14:40:01 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.202.213.76 with SMTP id m73mr21557280oig.79.1514414400594; Wed, 27 Dec 2017 14:40:00 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Wed, 27 Dec 2017 14:40:00 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Wed, 27 Dec 2017 14:40:00 -0800 (PST) In-Reply-To: <3c34aa3e-bf47-4d4f-be71-522c7cc0a9bf@isocpp.org> X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FQkil3Cx; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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:36405 Archived-At: --001a113adaa463e7e105615a1405 Content-Type: text/plain; charset="UTF-8" On 27 Dec 2017 21:37, "Nicol Bolas" wrote: 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. For *a* fallthrough syntax. I wouldn't use "[[fallthrough]]" to continue to the next case whilst using "break" to exit the switch. It's far too inconsistent, and is not something anyone would cime up with that from a "blank slate" POV. I'd just want "fallthrough". Or repurpose "continue" (though that'd play hell with legacy code) as in Perl. But either way, I'd move from attribute to keyword. 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. But that isn't what an attribute is for. I guess what you're saying is that we should reevaluate what attributes are for. The problem as I see it isn't that we are heading towards attributes which affect the language, it's that we are heading towards something that isn't an attribute. In terms of backwards compatibility, this seems backwards to me. We want to enforce [[fallthrough]] so that legacy code no longer works on new compilers but new code works on old compilers? Why not just add a fallthrough keyword that fails on old compilers but keep legacy code working on new compilers? Surely that's the more conventional approach? Especially if we are heading towards changing as radical as changing something so fundamental as a switch. I'm not in support of making the fallthrough explicit. I agree that if I were to take C++ and be able to make changes to the fundamentals, I'd change a lot (my first would be introducing an optional argument to break and continue in nested loops to identify which loop to break/continue, as in PHP). However, I'd be hesitant to change the behaviour of switch statements from the rest of the C-based languages. It's a behaviour shared by the C family (to my knowledge), and I have to admit that sharing such fundamentals is useful, especially when you're often flickering between different projects with different languages. -- 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/CAC%2B0CCPJcZ3XBjUbgvDh%2BcGX2zw1-d8EcJrP8zwZZdXmTBdfCg%40mail.gmail.com. --001a113adaa463e7e105615a1405 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 27 Dec 2017 21:37, "Nicol Bolas" <jmckesson@gmail.com> wrote:
If the answer is "no", then the next question is how we get fro= m where we are (default fallthrough) to a place where we can reasonably cha= nge the language to behave the way we would prefer. And the only way to tak= e that step is for the fallthrough syntax to be a real part of the language= , rather than something that is conceptually ignorable.

For a= fallthrough syntax. I wouldn't use "[[fallthrough]]" to cont= inue to the next case whilst using "break" to exit the switch. It= 's far too inconsistent, and is not something anyone would cime up with= that from a "blank slate" POV. I'd just want "fallthrou= gh". Or repurpose "continue" (though that'd play hell wi= th legacy code) as in Perl. But either way, I'd move from attribute to = keyword.
=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
But if that's a step that= C++ ever wants to take, we will have to canonize [[fallthrou= gh]]; we would have to make it real syntax.
<= /div>

But that isn't what = an attribute is for. I guess what you're saying is that we should reeva= luate what attributes are for. The problem as I see it isn't that we ar= e heading towards attributes which affect the language, it's that we ar= e heading towards something that isn't an attribute.

In terms of backwards compatibility, this = seems backwards to me. We want to enforce [[fallthrough]] so that legacy co= de no longer works on new compilers but new code works on old compilers? Wh= y not just add a fallthrough keyword that fails on old compilers but keep l= egacy code working on new compilers? Surely that's the more conventiona= l approach? Especially if we are heading towards changing as radical as cha= nging something so fundamental as a switch.

I'm not in support of making the fallthrough explic= it. I agree that if I were to take C++ and be able to make changes to the f= undamentals, I'd change a lot (my first would be introducing an optiona= l argument to break and continue in nested loops to identify which loop to = break/continue, as in PHP). However, I'd be hesitant to change the beha= viour of switch statements from the rest of the C-based languages. It's= a behaviour shared by the C family (to my knowledge), and I have to admit = that sharing such fundamentals is useful, especially when you're often = flickering between different projects with different languages.

--
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/CAC%2B0CCPJcZ= 3XBjUbgvDh%2BcGX2zw1-d8EcJrP8zwZZdXmTBdfCg%40mail.gmail.com.
--001a113adaa463e7e105615a1405-- .