220 36433 <99dbedb0-ba68-4245-a809-a7e8d9f0c501@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: Sat, 30 Dec 2017 08:32:02 -0800 (PST) Lines: 142 Approved: news@gmane.org Message-ID: <99dbedb0-ba68-4245-a809-a7e8d9f0c501@isocpp.org> 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/mixed; boundary="----=_Part_30392_714895748.1514651522290" X-Trace: blaine.gmane.org 1514651406 22701 195.159.176.226 (30 Dec 2017 16:30:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Dec 2017 16:30:06 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBA77T3JAKGQEW3ZVS4Q@isocpp.org Sat Dec 30 17:30:02 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 1eVK1J-0005VA-MJ for gclcip-std-proposals@m.gmane.org; Sat, 30 Dec 2017 17:30:01 +0100 Original-Received: by mail-ua0-f198.google.com with SMTP id 40sf19862524uaf.11 for ; Sat, 30 Dec 2017 08:32:04 -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=jhwOd37vYaCftOoFuuhT/+OOpGglkW2kbeGiJ7mOZnk=; b=DlIgUtN5XUggo+hKarTXXLZUU731PHnqhQMzvOfIVhXRvYXdQqWc8l0vgkaWXOSGlH zsDr/LZSgwUpoAMHMijjitrfxXWwPFNzkLSZvxkA3uhkTiiGalzCsVsws6mlQJ4d9YFt z4I2b6ZhPXi8llSsQJhiPYAOfy5CgPenrpJCImmI0iFTfCBymZOtg2g/IjC67t4VtcvC GJNlZwnI1WWGv+BzoHp31tPWcg44bVLCKiN0QXsU0BDzj5n9glzmbranFL4Kx4q0JHAr CB12Y6hlVn7HEwXasuwZVoAh4zdYZ+VhB4IwdWOut3X12AWxRMmHmsR1txAfw7Z95Bq0 +m8A== 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=jhwOd37vYaCftOoFuuhT/+OOpGglkW2kbeGiJ7mOZnk=; b=UqP7Hd+8MmrEjOwoEcRISDomhG6RYuPjmk2zPecUDerFtXg0kOZSSWN77frbIJiuJg nI7yqBa6Pzh/4M/ovtElgI0eNu2Vvq0gEHXBVqvTk7zUHCxUIe6J2Sam1QDNhWJMiVRj Mg8ECYTfSmKJXUX0oseoZ1bh+VVqhq77AQ/Y35V7d0hoKBIRzSs5oA7CE0ByGk3/Skiq 1r20pFCkpLzPg48o7AFdVNVfcpwCjkF8aodyPORxP2npWHr7N4t3+WvoWwx1JDyhShzJ V0iUDIGaA3CzzSelGgyrCW12vptweD/erP8Zek6q8gE9QV+geXpH5kHfybA6NZJYhD+t KX+g== 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=jhwOd37vYaCftOoFuuhT/+OOpGglkW2kbeGiJ7mOZnk=; b=l/DkDXU7GZMJszfhkA0E8UQH9P8hdVgj0T19ZsEL+g1bqJkABeCeBn0woocOZhY5lz WvKm+F4woYBqbdvwOhHK5A9NO25iHDgfLW4QS6F7Ml4DINbqnR5zBwv49IxSuLpBChjl jtoG42vmfzKlB3K11geQ7FzUx80OtiVnQiNYivB8brJv74RGYmz4QiJ+aQK+NRaPD7UZ Ehg6YJpLuapZgB20Otj+VRVdrFeKVGVcFCyAvo/zzW1r1YfRrS4cFikWs/wv3cPwBvsI hk9nPjEtyuvEhfp7qLpNI66nIzgmvZr82N8Zmts8xg+uWh7VH8JNI70xHqY3djAkTTz+ EQDw== X-Gm-Message-State: AKGB3mILpTTTLu2DpTLVUyAMQy1XifRvndvJqgkVE9ykdCKUzXOjqQD/ u3+SaPglFW/hmcYe4wLjN9+P1Q== X-Google-Smtp-Source: ACJfBouSoZtOi6A9O8ns8NJZJXCkuXNWcdgjEWnii3H4HBb3E6WABEC6SbP0cgmjqWSX9eXFWN5blg== X-Received: by 10.31.244.198 with SMTP id s189mr17387810vkh.92.1514651524231; Sat, 30 Dec 2017 08:32:04 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.149.6 with SMTP id x6ls283564vkd.20.gmail; Sat, 30 Dec 2017 08:32:02 -0800 (PST) X-Received: by 10.31.2.144 with SMTP id 138mr3510457vkc.5.1514651522859; Sat, 30 Dec 2017 08:32:02 -0800 (PST) In-Reply-To: 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:36433 Archived-At: ------=_Part_30392_714895748.1514651522290 Content-Type: multipart/alternative; boundary="----=_Part_30393_1751205955.1514651522290" ------=_Part_30393_1751205955.1514651522290 Content-Type: text/plain; charset="UTF-8" On Wednesday, December 27, 2017 at 5:49:39 PM UTC-5, Corentin wrote: > > I'd like to add reflection to the discussion. > > In the context of reflection/metaclasses, there needs to be a way to > filter entities. Attributes would be a great fit for that. > > Some people have suggested that we need a new "decorator" feature for that > use case. However, such feature would be very similar to attributes but > would require a new syntax. > The attribute syntax also offers a lot of great useful features ( > namespaces, parameters ) that are currently underused, to say the least. > > Of course, if people start generating code based on the presence/value of > some attribute, that confers semantic meaning to the attribute that can > therefor not be ignored > And, that's okay. > That's a really good point. If we can reflect over attributes, then the ability of attributes to be ignored goes away entirely. Or at least, is based on what code someone uses. Even P0840's idea of saying that "a program that works with the use of the attribute shall still behave as a program without that attribute" fails, since reflection and code generation based on that will change. So it seems that this makes the current direction of attributes even less tenable. So, I was considering proposing the following guidelines: > > > - Compiler vendor attributes should be disregardable by the compiler. > - Whether a standard attributes can be disregarded should be evaluated > on a per-attribute basis ( for future attributes ) > - Attributes unknown to the compiler should be exposed through a > reflection API ( I have yet to think about how such api would look like ). > > If attributes are exposed to reflection, then *all* attributes should be exposed. There's no reason I shouldn't be able to ask if a function is `noreturn` or whatever. > > - Whether standard attributes should be exposed through the reflection > api should be decided on a per attributes basis. > - Contracts should not be exposed through the reflection API. > - All non-standard attributes ( that is, attributes added for > reflection purposes and those offered by vendors) should have a namespace > qualifier. That should be the case already. > > > -- 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/99dbedb0-ba68-4245-a809-a7e8d9f0c501%40isocpp.org. ------=_Part_30393_1751205955.1514651522290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wednesday, December 27, 2017 at 5:49:39 PM UTC-5, Coren= tin wrote:
I&#= 39;d like to add reflection to the discussion.=C2=A0

In the context of reflection/metaclass= es, there needs to be a way to filter entities. Attributes would be a great= fit for that.

Some people have suggested that we need a new &q= uot;decorator" feature for that use case. However, such feature would = be very similar to attributes but would require a new syntax.
<= div>The attribute syntax also offers a lot of great= useful features ( namespaces, parameters ) that are currently underused, t= o say the least.

=
Of course, if people start generating code based on the presence/value= of some attribute, that confers semantic meaning to the attribute that can= therefor not be ignored
And, = that's okay.

Th= at's a really good point. If we can reflect over attributes, then the a= bility of attributes to be ignored goes away entirely. Or at least, is base= d on what code someone uses. Even P0840's idea of saying that "a p= rogram that works with the use of the attribute shall still behave as a pro= gram without that attribute" fails, since reflection and code generati= on based on that will change.

So it seems that thi= s makes the current direction of attributes even less tenable.
=
=C2=A0So, I was considering proposing the= following guidelines:

=
  • Compiler vendor attributes should be disregardable by th= e compiler.=C2=A0
  • Whether a standard attributes can be disregarded = should be evaluated on a per-attribute basis ( for future attributes )
    • =
  • Attributes unknown to the compiler should be exposed through a reflecti= on API ( I have yet to think about how such api would look like ).
If attributes are exposed to ref= lection, then all attributes should be exposed. There's no reaso= n I shouldn't be able to ask if a function is `noreturn` or whatever.
  • Whether standard attributes should be exposed through the ref= lection api should be decided on a per attributes basis.
  • Contracts = should not be exposed through the reflection API.
  • All non-standard = attributes ( that is, attributes added for reflection purposes and those of= fered by vendors) should have a namespace qualifier. That should be the cas= e already.

--
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/99dbedb0-ba68-4245-a809-a7e8d9f0c501= %40isocpp.org.
------=_Part_30393_1751205955.1514651522290-- ------=_Part_30392_714895748.1514651522290-- .