220 36440 <826fe303-b6b8-4a78-a9a8-2134a2001b8e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: bastienpenava@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: The current attribute/keyword dividing line is unsustainable. Date: Sat, 30 Dec 2017 22:11:07 -0800 (PST) Lines: 215 Approved: news@gmane.org Message-ID: <826fe303-b6b8-4a78-a9a8-2134a2001b8e@isocpp.org> References: <86919454-9af9-4b08-b7b3-fd262b46cdd5@isocpp.org> <40edf1b5-5c72-4682-902e-1c0cea581e37@isocpp.org> <3c34aa3e-bf47-4d4f-be71-522c7cc0a9bf@isocpp.org> <99dbedb0-ba68-4245-a809-a7e8d9f0c501@isocpp.org> <1e0e91af-0794-4e8c-b18a-d8a895d3787f@isocpp.org> <5cf989da-fb68-4c93-8a72-7542f9e437ee@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_31704_1276353088.1514700667928" X-Trace: blaine.gmane.org 1514700555 5508 195.159.176.226 (31 Dec 2017 06:09:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Dec 2017 06:09:15 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCG3XHNI6IDRB7H6UHJAKGQEJC5CDTI@isocpp.org Sun Dec 31 07:09:11 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eVWnz-0000qC-CF for gclcip-std-proposals@m.gmane.org; Sun, 31 Dec 2017 07:09:07 +0100 Original-Received: by mail-ua0-f198.google.com with SMTP id d7sf23384117uad.22 for ; Sat, 30 Dec 2017 22:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=59uA/jhlx5GWfgpb0Hm+Cdtjspb15gxoHJPgBWhbupY=; b=rnUrOerrf9a3DqzxVnrMCuxTIgEwxdnmwoj9osZDHMdjko/MlFpWhN5CPBnf1qIoAb 7pWhQ3vmVnziWOBFkUSGZUYyQ5+RtvhcJhQKr007tGksTE029rCMrEh0inbMjGfeysdv +dajrmZ9+EHmH44G9rPc0nL/Nja+dKC3IvYKbx2UcCpNKfuKcPKC3IK4gGJdYj7oUZAR kjLvttUE37ya/0lo9seUHx3GdUMDcOltSWcBhDurARbZBfM87L0C/e3K77SjVCWqADg/ TqQbsMQHPhpvoN+xOuv8O3bN8Vrmt3FRAA9hmcuJFPTOnuW/X8+d428ziH2MnZOL/Wqv 9wYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=59uA/jhlx5GWfgpb0Hm+Cdtjspb15gxoHJPgBWhbupY=; b=oQ5mcnM7YGzCPa9s/mSAZGOzHaRHj9dTcvIsNPnIirzOzvHLCldXina0n0JEyPo4h5 t5tsADM3MQ7PkwVFHLgbWygLdmLsRsP9ShqmqGikEwhTNFdb7XOYTypHrvnuqaIk29bY tbZilxZE8e1qbExusKVkdQ0ATP1+3F+Jbc134u4df3iJl9EfNsxP+UyarBpjPiLOo9JM ac7UzrVVUHQm7RteEMBsp2qs/jkdSJOp2SHF295kY85G/u/ZwyaHhOWCBBnOzds6K0yh hr9rher1O9Zgne0Zm9JJ+hvPAFDZyzNC/88xBjD1ULyMrTdGUhLekRApKoo5hV3PTod3 VD5g== 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: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=59uA/jhlx5GWfgpb0Hm+Cdtjspb15gxoHJPgBWhbupY=; b=f1VW0bq+ebm7qQ1lAemjRu78Obs33yGYyjHG2zju+zZYIqtTtCZKeLpGRgMj4lKAsP 20G0la0Cepy+2iJYKnMEqDgyG66AbWcuWOQiuThbrGIbp9uz04sp4jibXpnG2QMqraO0 SQZgW6slMtejTMYeVeLx9+Z+iqeC+XggUBFhkPwfaJ4OEFBgQu0jnMG+fJtbVW5Lmo1n Tr/AAhI4MqgLrsb3qhuKHQJ0VmNpxSPE3nd/Ctg4PuNsga6BivaEouL8zLgDcpIrEloY V9lD4bw/lAa/AS10BtB4qEk08BGLJUBOW5dp7Itd1unQ/WBIKJW2/qiXheqMfWmg5bSe LJzw== X-Gm-Message-State: AKGB3mKElEbQoa6DCZMgkETUpog89x7dMTZWFtIFRzeotdNN2jegWQhO V1W6O7+TPs3ZX0azIArpzFUh6w== X-Google-Smtp-Source: ACJfBovLqhi/NTdywgP1uIlxqSgScYSZ995eAycPOP/GVAjuxKWzFAswDoszDmbE4RgabS2cB+AQIw== X-Received: by 10.31.59.5 with SMTP id i5mr9729280vka.81.1514700670135; Sat, 30 Dec 2017 22:11:10 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.171.19 with SMTP id u19ls5820580vke.9.gmail; Sat, 30 Dec 2017 22:11:08 -0800 (PST) X-Received: by 10.31.164.84 with SMTP id n81mr552917vke.14.1514700668493; Sat, 30 Dec 2017 22:11:08 -0800 (PST) In-Reply-To: X-Original-Sender: BastienPenava@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:36440 Archived-At: ------=_Part_31704_1276353088.1514700667928 Content-Type: multipart/alternative; boundary="----=_Part_31705_2025923147.1514700667929" ------=_Part_31705_2025923147.1514700667929 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, December 31, 2017 at 1:38:02 AM UTC+1, Arthur O'Dwyer wrote: > > On Sat, Dec 30, 2017 at 4:05 PM, >=20 > wrote: > >> On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski=20 >> wrote: >>> >>> >>> IMHO "ignored" in sens that they have no meaning for compiler not that= =20 >>> they do not exists. Gathering attributes and write them to some meta st= ruct=20 >>> is not something that is hard to do and work with any attribute even if= =20 >>> compiler have no clue what it mean. I think this fit attributes nicely. >>> >> >> No actually, a compiler that would parse-skip c++ attributes would be=20 >> legal. >> > > Legal, sure, but obviously non-conforming. There are plenty of ways that= =20 > [[attributes]] can render a translation unit "ill-formed, yes diagnostic= =20 > required." A compiler that doesn't check for ill-formed constructs doesn'= t=20 > conform to the ISO standard... except perhaps in the trivial sense that= =20 > [intro.compliance] has no teeth. I'm pretty sure a conforming=20 > implementation could just output "?" in addition to its machine code and= =20 > thus satisfy [intro.compliance]. > > Besides, I think Marcin was probably talking from the point of view of=20 > actual programming. A "legal" compiler could just as well replace the nam= e=20 > of every variable with the output of an MD5 hash, or place an extra=20 > kilobyte of padding between each pair of struct fields, but that doesn't= =20 > mean that a hypothetical C++2x reflection facility shouldn't expose thing= s=20 > like variable names and struct layouts. Because the programmer might=20 > actually *want to use* reflection over the names of their variables, or= =20 > which attributes have been applied to a function, or struct layout, or=20 > whatever. > > =E2=80=93Arthur > Yes it would and I use legal to express "minimum required to be compliant". By parse-skip I meant that the declaration's internal representation is=20 allowed not to contain/save non-recognized attributes. A compiler that would not-recognize "noreturn" for instance would still be= =20 compliant as the current standard defined attributes are allowed to be=20 ignored (their ill-form use as well). A compiler that would hash into MD5 the variables name would clash=20 explicitly with the reflection proposals. My point was that completely ignoring unrecognized attributes (which is=20 compliant) can change the result of a computation with reflection: struct A { [[my_undefined_attribute]] int i; }; for (auto x : reflexpr(A).member_variables()) { if (x.has_attribute("my_undefined_attribute")) behaviour_a(); else behaviour_b(); } --=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/826fe303-b6b8-4a78-a9a8-2134a2001b8e%40isocpp.or= g. ------=_Part_31705_2025923147.1514700667929 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sunday, December 31, 2017 at 1:38:02 AM UTC+1, = Arthur O'Dwyer wrote:
On Sat, Dec 30, 2017 at 4:05 PM, <bastie...@gm= ail.com> wrote:
On Saturday, December 30, 2017 = at 7:06:19 PM UTC+1, Marcin Jaczewski wrote:

IMHO "ignored" in s= ens that they have no meaning for compiler not that they do not exists. Gat= hering attributes and write them to some meta struct is not something that = is hard to do and work with any attribute even if compiler have no clue wha= t it mean. I think this fit attributes nicely.

No actually, a compiler that would parse-skip c++ at= tributes would be legal.

Legal,= sure, but obviously non-conforming. There are plenty of ways that [[attrib= utes]] can render a translation unit "ill-formed, yes diagnostic requi= red." A compiler that doesn't check for ill-formed constructs does= n't conform to the ISO standard... except perhaps in the trivial sense = that [intro.compliance] has no teeth. I'm pretty sure a conforming impl= ementation could just output "?" in addition to its machine code = and thus satisfy [intro.compliance].

Besides, I th= ink Marcin was probably talking from the point of view of actual programmin= g. A "legal" compiler could just as well replace the name of ever= y variable with the output of an MD5 hash, or place an extra kilobyte of pa= dding between each pair of struct fields, but that doesn't mean that a = hypothetical C++2x reflection facility shouldn't expose things like var= iable names and struct layouts. Because the programmer might actually wa= nt to use reflection over the names of their variables, or which attrib= utes have been applied to a function, or struct layout, or whatever.
<= div>
=E2=80=93Arthur
Yes it would and I use legal to express "minimum required to be compl= iant".
By parse-skip I meant that the declaration's inte= rnal representation is allowed not to contain/save non-recognized attribute= s.
A compiler that would not-recognize "noreturn" f= or instance would still be compliant as the current standard defined attrib= utes are allowed to be ignored (their ill-form use as well).
A co= mpiler that would hash into MD5 the variables name would clash explicitly w= ith the reflection proposals.

My point was that co= mpletely ignoring unrecognized attributes (which is compliant) can change t= he result of a computation with reflection:

struct A
{
=C2=A0 =C2=A0[[my_undefined_attribute]] int i;
};
=
for (auto x : reflexpr(A).me= mber_variables()){<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 =C2=A0 = if<= span style=3D"color: #000;" class=3D"styled-by-prettify"> (x.has_attribute("my_undefined_attribute"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour_a();
=C2=A0 =C2=A0else<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 =C2=A0 = =C2=A0 =C2=A0behaviour_b();
}

--
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/826fe303-b6b8-4a78-a9a8-2134a2001b8e= %40isocpp.org.
------=_Part_31705_2025923147.1514700667929-- ------=_Part_31704_1276353088.1514700667928-- .