220 10465 <4284fd8e-4e72-47d2-81b3-dd36b439d789@isocpp.org> article Path: news.gmane.org!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Add compiler time attributes like c# Date: Thu, 1 May 2014 05:03:18 -0700 (PDT) Lines: 206 Approved: news@gmane.org Message-ID: <4284fd8e-4e72-47d2-81b3-dd36b439d789@isocpp.org> References: <85900e94-bdc6-45eb-87ec-d3fd9e43d4cd@isocpp.org> <105e6e46-2830-4ac3-b2a9-17f402b35466@isocpp.org> <0560616f-101c-4428-99a2-fb80f22b1959@isocpp.org> <19B05C1A-65AA-466E-B9E6-DC5B8D5776D4@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5011_32858850.1398945798559" X-Trace: ger.gmane.org 1398945809 9821 80.91.229.3 (1 May 2014 12:03:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 May 2014 12:03:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCM3TRNUXUDBBB7QRCNQKGQE5EL3FSA@isocpp.org Thu May 01 14:03:22 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wfphx-00086F-NW for gclcip-std-proposals@m.gmane.org; Thu, 01 May 2014 14:03:22 +0200 Original-Received: by mail-ie0-f199.google.com with SMTP id rl12sf16249439iec.6 for ; Thu, 01 May 2014 05:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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 :content-type; bh=BtrQ9FJUsH0hQng8CiO/puqMyyG7fpWis7v5l602c5k=; b=04QT91zNI+fjJM4iOmWTJwQo1oxJq0RxeXxdQVZdWjsPuGHqJs+ZVOb0HiowiCbvDG RmOW7hFEJkIRpyoZDJQNo16xWy71GZlsBU6nuJjmEeNxC/oPxPzG4EpZ8lmSj16qg7Is GX78D/+E40LTYqpZbpq9NY6C0wCPMqsJj2ZcWp5ZRAVaA3LG8GYAwVB2wFw63VLTA8d6 ItfySFaXm3jbNLJ/MBwzorAFDV377vJJprc/9u1cYS4lldDWjxJdJbfm58fxjrB/RN0Q MN143ETQw2Zba01fnB/PvhNwOJaHS88ekvboUPEYiO/6UxX/r1xM5gVvXU9okCvyhOF8 NmNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=BtrQ9FJUsH0hQng8CiO/puqMyyG7fpWis7v5l602c5k=; b=bApoMezMk/KbhSDoY2TDLx6dcY8lUdjKJ1oB47rq4UpNgO4My1yW55Hx0o3ZCByk0g A5HxK3pPysQDY1Zp/X/0L9i+ru3Ih1sXJSSQdQkw1SEkrDyLU6HVimU/DZ/uz/Y5CVn0 rkO6ywZndjnzR75j+BkHz827FqtVbJqgbjXfgRhNJjRB3ImzRmg5U5nnMSDqPIx58Z+p XDL6XqQRZ/AY/7lVqEyveDHgB1LWUHP0HNFPaUCkGw5yBJzT6JNO3neC50yI7GhzJEMa 9MGwlo/DWhHl1/XIwAUukczgT/Oet+akNVToyIwxQ+xCQd4hlp/HlDEiQFEirRTvSYbB 9Xkw== X-Gm-Message-State: ALoCoQng7IKGzS6/8QpVZLq13/g/1XhRCSHozJOpQTT2VpzEIYpNYH0Y4/CjBF8IoulhpbgQ9NKN X-Received: by 10.42.223.10 with SMTP id ii10mr4719022icb.21.1398945800140; Thu, 01 May 2014 05:03:20 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.43.231 with SMTP id z7ls569399obl.20.gmail; Thu, 01 May 2014 05:03:19 -0700 (PDT) X-Received: by 10.182.22.138 with SMTP id d10mr66489obf.7.1398945799096; Thu, 01 May 2014 05:03:19 -0700 (PDT) In-Reply-To: <19B05C1A-65AA-466E-B9E6-DC5B8D5776D4@gmail.com> X-Original-Sender: gmisocpp@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:10465 Archived-At: ------=_Part_5011_32858850.1398945798559 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi On Thursday, May 1, 2014 2:46:15 PM UTC+12, David Krauss wrote: > > > On 2014=E2=80=9305=E2=80=9301, at 4:37 AM, gmis...@gmail.com wrote: > > Hi > > On Thursday, May 1, 2014 7:15:50 AM UTC+12, Peter Koch Larsen wrote: >> >> If you are not using the argument, I fail to see why you would want to= =20 >> look at it in the debugger.=20 >> >> /Peter=20 >> > > You're not using it currently, it doesn't mean you don't intend to use i= t=20 > later, you still want to verify that it has the right value should there= =20 > come a time when you want to use it, right? > > > The debugger is likely to reuse the storage for something else, due to th= e=20 > variable having no lifetime, so it wouldn=E2=80=99t be able to show the v= alue for=20 > very long. Anyway, there=E2=80=99s no reason to suppress warnings in unfi= nished=20 > code. If you intend to use something in the near future, you wouldn=E2=80= =99t mark=20 > it [[unused]] because the warning serves as a useful reminder. > I don't know what you mean by "very long", the debugger I use always seems= =20 to show me the value of a parameter if I've named it adequately enough. The problems appear when I remove the name of it, which is exactly why I=20 don't find that a good solution. The warning as a useful reminder is reasonable enough opinion, but it isn't= =20 something every person shares or every compiler agrees on anyway. Plenty of= =20 companies like to see release builds warning free, for example, rightly or= =20 wrongly. Which is the whole problem with the current solution set. There isn't any= =20 standard way to gain control over these issues. I think we have to discuss things in the context of what do we want to=20 achieve. This discussion just tells me that we might need more than one=20 attribute rather than no control. I also don't find removing the parameter name from the definition a great= =20 solution to stating a parameter is "unused", even if the name is in the=20 header. If as a developer, I'm looking at the definition, I don't want to= =20 have to go to the header to remind myself what the parameter is. Nor do I want a whole lot of uncertainty about what the compiler might do= =20 with an unused parameter. Can it go as far as removing it completely and=20 changing an interface for example. So we might need more than one attribute to control that. Not one. i.e.=20 [[not_used, warning or no_warning]], [[never_ever_will_be_used, no_warning]= ] whatever. > You'd also like to make sure any documentation tools that use these names= =20 > have a name to work with, etc. etc. etc. > > > Such documentation is based on interface declarations, not implementation= .. > > Documentation tools can use such attributes too so that it can see a=20 parameter is currently unused or never used or whatever, a doc tool could= =20 be aware of that without some code analysis to discover the fact. There is definitely room for improvements here. I just think it's not quite= =20 so easy to work which is probably why it hasn't been done. But we also=20 never had the opportunity to abuse attributes to "help" things here before! That's why the [[warn_on_unused_return]] type one was the one I chose=20 first, because it seems easiest to specify. But It'd be nice to nail down= =20 some [[unused_arg]] type attributes that would work. Thanks =20 --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_5011_32858850.1398945798559 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

On Thursday, May 1, 2014 2:46:15 PM UTC+12, Davi= d Krauss wrote:

On 2014=E2=80=9305=E2=80=9301, at 4:37 AM, gmis...@gmail.com wrote:

Hi

On Thursday, May 1, 2014 7:15= :50 AM UTC+12, Peter Koch Larsen wrote:
If you = are not using the argument, I fail to see why you would want to
look at it in the debugger.

/Peter

You're not using it currently, it does= n't mean you don't  intend to use it later, you still want to verify t= hat it has the right value should there come a time when you want to use it= , right?

The debugger is likely= to reuse the storage for something else, due to the variable having no lif= etime, so it wouldn=E2=80=99t be able to show the value for very long. Anyw= ay, there=E2=80=99s no reason to suppress warnings in unfinished code. If y= ou intend to use something in the near future, you wouldn=E2=80=99t mark it= [[unused]] because the warning serves as a useful reminder.

I don't know what you mean by "ver= y long", the debugger I use always seems to show me the value of a paramete= r if I've named it adequately enough.
The problems appear when I = remove the name of it, which is exactly why I don't find that a good soluti= on.

The warning as a useful reminder is reasonable= enough opinion, but it isn't something every person shares or every c= ompiler agrees on anyway. Plenty of companies like to see release builds wa= rning free, for example, rightly or wrongly.

Which= is the whole problem with the current solution set. There isn't any standa= rd way to gain control over these issues.
I think we have to disc= uss things in the context of what do we want to achieve. This discussion ju= st tells me that we might need more than one attribute rather than no contr= ol.

I also don't find removing the parameter name = from the definition a great solution to stating a parameter is "unused", ev= en if the name is in the header. If as a developer, I'm looking at the= definition, I don't want to have to go to the header to remind myself=  what the parameter is.

Nor do I want a = whole lot of uncertainty about what the compiler might do with an unused pa= rameter. Can it go as far as removing it completely and changing an interfa= ce for example.

So we might need more than one att= ribute to control that. Not one. i.e. [[not_used, warning or no_warning]], = [[never_ever_will_be_used, no_warning]]
whatever.

<= /div>

You'd also like t= o make sure any documentation tools that use these names have a n= ame to work with, etc. etc. etc.

Suc= h documentation is based on interface declarations, not implementation.


Documentation tools= can use such attributes too so that it can see a parameter is current= ly unused or never used or whatever, a doc tool could be aware of that with= out some code analysis to discover the fact.

There= is definitely room for improvements here. I just think it's not quite so e= asy to work which is probably why it hasn't been done. But we also nev= er had the opportunity to abuse attributes to "help" things here before!

That's why the [[warn_on_unused_return]] type o= ne was the one I chose first, because it seems easiest to specify. But It'd= be nice to nail down some  [[unused_arg]] type attributes that would = work.

Thanks
 

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_5011_32858850.1398945798559-- .