220 36446 <9389c26c-b1a4-4790-8181-1e1c386a8ff8@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: The current attribute/keyword dividing line is unsustainable. Date: Sun, 31 Dec 2017 08:21:18 -0800 (PST) Lines: 252 Approved: news@gmane.org Message-ID: <9389c26c-b1a4-4790-8181-1e1c386a8ff8@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> <826fe303-b6b8-4a78-a9a8-2134a2001b8e@isocpp.org> <9175685e-4a44-4e1f-afc9-f8271aa63deb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_32946_1515073130.1514737278872" X-Trace: blaine.gmane.org 1514737166 13710 195.159.176.226 (31 Dec 2017 16:19:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 31 Dec 2017 16:19:26 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB744UTJAKGQEQ7HNCPA@isocpp.org Sun Dec 31 17:19:22 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 1eVgKU-00036m-BX for gclcip-std-proposals@m.gmane.org; Sun, 31 Dec 2017 17:19:18 +0100 Original-Received: by mail-ua0-f198.google.com with SMTP id 111sf17235893uaq.13 for ; Sun, 31 Dec 2017 08:21:21 -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=XlXxLw2QCDJMJk/SWsbkkn37Pme0VFIsvvfCLbod2Eo=; b=prxmsuoGZ1qK4JsB+WmoOtoVV8Vrgr0SGq8PyArxI38fzPMWfnu9wgLYCSjU4pXRro /y6iVBA29My177Ahzenre1uqTzMKfB4n3kctfNrWz5ekxC2jxscprRsUQ7ebPw2huizX 4VIMhGC+yPzkl9LWZlPYQvYte3p2ncp8zfu8Eb0c3Gfpm/1R+zjZmDL1sinesTeXHPdd 4QIhADWZRs+qTWGhJf+bH8h4jHcaaijVQ0vCZ5C8hz5WlrAjIO8ypYBJOrDEzQrLkyap Iv2C2lYseiOhqZbtLYb+ux8kSVDhBBUx8Q8L81v5GiHiAgZ4ZdkqWCvIpyUzMNRwPy+C l6Aw== 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=XlXxLw2QCDJMJk/SWsbkkn37Pme0VFIsvvfCLbod2Eo=; b=Djr6evI+kfJ6Z/L9IB5JB3O3d9To9uA6PwOFJBjSuScvhenlZaiZLPXF91RdOE4D73 IJxhPfs6MNO3jQo2OtMNjqIFH+9BwFmQ+785DCJvXyynre8EMtH4s2IQyKKmYTQ5dNbV FTUYxiLIdUbnfGv4sALzfpYrroWJT3hOCgf/c5CsSO6kZwy7e0xCyEatk+GhJFtPZr/0 52bGoEYbeul4tCv8ET7UgZiMEDKpkXiE+ktRChPl2MT1TuqFV4l3FpAvAtDsFsWDHg/l FNHUb24HwM/6Fuxp+n9T+0gdeAeJ3h1AQ1tM2LC1DHu/z3WTqKcCusr2pR7uOOQ5vMLq 0xbQ== 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=XlXxLw2QCDJMJk/SWsbkkn37Pme0VFIsvvfCLbod2Eo=; b=RAl8zU3MVOA4s1HdTEITPh+3KF6/wMm7Z4YsVLGoQH1HS4mUXTeaHYsK0XlKZW7IcK ihXVFvnTisDMIruN2mOoItI/eXWAjYAhDGklms2Aezy52rpJmu1IihY5Olkhie/uin7L c23a+i4A8OkFbAS3jQtttrngW89KLJic3kvwIlflE5Yd5jO0hXhuR0+NwpM7sNKQeVg3 bgcf9BGcMNKAOUZFpc/PHHtVKU900p+F2qGnZ44xOoFT5RKH7lghyU1DjQ0Gb+RZZK8L 2ekBilS3pK4n0hH0MXhMSUu2qOnjc8I7sYGDtS0lPtO1Qtavo4o2/44jMFXPvx5ZKmK/ aEOQ== X-Gm-Message-State: AKGB3mJiRuGVz2sI+v9n8KTFcWpuTf2YH2+o30cDgh4j0ML+Qu45UQqc yPeR4sTEhFFUTGkqvedGGXWM0Q== X-Google-Smtp-Source: ACJfBosQ4BnssY6ovWHRgKBbwJCWTnlB3ypnwAkQHpHA0xrPv0+v3O7imAetHgGwur5vx0THQd3cQA== X-Received: by 10.31.1.214 with SMTP id 205mr18398091vkb.13.1514737281182; Sun, 31 Dec 2017 08:21:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.70.1 with SMTP id t1ls3213114vka.15.gmail; Sun, 31 Dec 2017 08:21:19 -0800 (PST) X-Received: by 10.31.171.73 with SMTP id u70mr3810842vke.10.1514737279408; Sun, 31 Dec 2017 08:21:19 -0800 (PST) In-Reply-To: <9175685e-4a44-4e1f-afc9-f8271aa63deb@isocpp.org> X-Original-Sender: jmckesson@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:36446 Archived-At: ------=_Part_32946_1515073130.1514737278872 Content-Type: multipart/alternative; boundary="----=_Part_32947_1998488120.1514737278873" ------=_Part_32947_1998488120.1514737278873 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, December 31, 2017 at 10:58:58 AM UTC-5, Marcin Jaczewski wrote: > > On Sunday, December 31, 2017 at 7:11:08 AM UTC+1, bastie...@gmail.com=20 > wrote: >> >> 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, 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 tha= t=20 >>>>> they do not exists. Gathering attributes and write them to some meta = struct=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 nicel= y. >>>>> >>>> >>>> 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 tha= t=20 >>> [[attributes]] can render a translation unit "ill-formed, yes diagnosti= c=20 >>> required." A compiler that doesn't check for ill-formed constructs does= n'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 an= d=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 n= ame=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 thi= ngs=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=20 >> 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= =20 >> be compliant as the current standard defined attributes are allowed to b= e=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 > Again:=20 > > IMHO "ignored" in sens that they have no meaning for compiler not that= =20 > they do not exists > This is not statement about how it now behave but how it should behave. > When reflection hits then we can require for complying implementation tha= t=20 > it store ALL attributes for reflection purposes and nothing more. > They will be still "ignored" because will not affect any thing else in=20 > compiler. > Can you not see that, for the programmer, this is a distinction without a= =20 distinction? If something affects the standard-defined behavior of the=20 program, the programmer doesn't care if it's the compiler doing it or some= =20 particular code that's causing that behavior. And therefore, for the=20 programmer, an attribute and a keyword are equally significant. Who cares if the "compiler" is allowed to "ignore" it, when the compiler is= *=20 required* to pass that information along to other code which will not=20 ignore it? That's not ignoring it; that's not everything works as it did=20 before. --=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/9389c26c-b1a4-4790-8181-1e1c386a8ff8%40isocpp.or= g. ------=_Part_32947_1998488120.1514737278873 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, December 31, 2017 at 10:58:58 AM UTC-5, Marcin = Jaczewski wrote:
On Sunday, December 31, 2017 at 7:11:08 AM UTC+1, bastie...@gmail.com= wrote:
On Sund= ay, December 31, 2017 at 1:38:02 AM UTC+1, Arthur O'Dwyer wrote:
On Sat, Dec 30, 2017 at 4= :05 PM, <bastie...@gmail.com&= gt; wrote:
On Saturday, December 30, 2017 at 7:06:19 P= M UTC+1, Marcin Jaczewski wrote:

IMHO "ignored" in sens that the= y have no meaning for compiler not that they do not exists. Gathering attri= butes and write them to some meta struct is not something that is hard to d= o and work with any attribute even if compiler have no clue what it mean. I= think this fit attributes nicely.

<= /span>
No actually, a compiler that would parse-skip c++ attributes wou= ld be legal.

Legal, sure, but o= bviously non-conforming. There are plenty of ways that [[attributes]] can r= ender a translation unit "ill-formed, yes diagnostic required." A= compiler that doesn't check for ill-formed constructs doesn't conf= orm to the ISO standard... except perhaps in the trivial sense that [intro.= compliance] has no teeth. I'm pretty sure a conforming implementation c= ould just output "?" in addition to its machine code and thus sat= isfy [intro.compliance].

Besides, I think Marcin w= as probably talking from the point of view of actual programming. A "l= egal" compiler could just as well replace the name of every variable w= ith the output of an MD5 hash, or place an extra kilobyte of padding betwee= n each pair of struct fields, but that doesn't mean that a hypothetical= C++2x reflection facility shouldn't expose things like variable names = and struct layouts. Because the programmer might actually want to use reflection over the names of their variables, or which attributes have be= en applied to a function, or struct layout, or whatever.

=E2=80=93Arthur
Yes it woul= d and I use legal to express "minimum required to be compliant".<= /div>
By parse-skip I meant that the declaration's internal represe= ntation is allowed not to contain/save non-recognized attributes.
=
A compiler that would not-recognize "noreturn" for instance = would still be compliant as the current standard defined attributes are all= owed to be ignored (their ill-form use as well).
A compiler that = would hash into MD5 the variables name would clash explicitly with the refl= ection proposals.

My point was that completely ign= oring unrecognized attributes (which is compliant) can change the result of= a computation with reflection:

struct A
{
=C2=A0 =C2=A0[[my_undefined_attribute= ]] int i;
<= span style=3D"color:#660">};

for <= span style=3D"color:#660">(auto x : reflexpr(A).member_variables())
= {
=C2=A0 =C2=A0 if (x.has_attribute("my_undefined_attrib= ute"))
=C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour_a();
=C2=A0 =C2=A0else
=C2=A0 =C2=A0 = =C2=A0 =C2=A0behaviour_b();
}
=C2=A0
Again:
&g= t; IMHO "ignored" in sens that they have no meaning for compiler = not that they do not exists
This is not statement about how it n= ow behave but how it should behave.
When reflection hits then we = can require for complying implementation that it store ALL attributes for r= eflection purposes and nothing more.
They will be still "ign= ored" because will not affect any thing else in compiler.

Can you not see that, for the programme= r, this is a distinction without a distinction? If something affects the st= andard-defined behavior of the program, the programmer doesn't care if = it's the compiler doing it or some particular code that's causing t= hat behavior. And therefore, for the programmer, an attribute and a keyword= are equally significant.

Who cares if the "c= ompiler" is allowed to "ignore" it, when the compiler is = required to pass that information along to other code which will not ig= nore it? That's not ignoring it; that's not everything works as it = did before.

--
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/9389c26c-b1a4-4790-8181-1e1c386a8ff8= %40isocpp.org.
------=_Part_32947_1998488120.1514737278873-- ------=_Part_32946_1515073130.1514737278872-- .