220 10765 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: More syntactic sugar for auto Date: Thu, 22 May 2014 15:05:44 -0400 Lines: 178 Approved: news@gmane.org Message-ID: References: <65883e55-e93a-4720-94eb-355cf65126e5@isocpp.org> <8ade6aeb-a949-42f9-8cc6-1f0bf3aec72e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3cdeec46b4e04fa01cc5d X-Trace: ger.gmane.org 1400785552 24133 80.91.229.3 (22 May 2014 19:05:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 May 2014 19:05:52 +0000 (UTC) Cc: mw_triad@users.sourceforge.net To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDIIVO6GQULBBCEV7GNQKGQEM35LGTQ@isocpp.org Thu May 22 21:05:46 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f70.google.com ([209.85.215.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WnYJF-00048d-JN for gclcip-std-proposals@m.gmane.org; Thu, 22 May 2014 21:05:45 +0200 Original-Received: by mail-la0-f70.google.com with SMTP id el20sf2192735lab.9 for ; Thu, 22 May 2014 12:05:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=AKTO/vMZvcvygJsYb1xSQ0hTjKKyg3GUfpRFNH/uqlk=; b=HmPH1eLuIX79m/3I7OXXQqYZSCaNDYFYfWDw1SKVhabNm1dnNeaZQuXPiYnbYhhuVq +QDjpRpfTaVMI9ZIbtlBlWNO9DBc2lsVhUtJ8xQNq43kCTHLhYHQlQrotrLtkqTiBYGE ckWd952h3Qt1cJyBfoP5mZvEaVqii8DAOLkDO7vrmMevjj9Rh4w01dJ0NZyjd16Hf2qI 3EtJCysh8MPL2sVgV5l/KWSbQP1Xt4xmLWpnW29WZeXP+9fN2Mihi3OaSTzAHF2aRVdC OH+dHuqDc+qOi7wLiJZwzWnIODHujdS/EA37/7lQ66vkLhIE+TT4CdIUycDoKaqRf5oK OmDg== X-Gm-Message-State: ALoCoQkOkS8IanWUE5YCxWRPlLS1TUx+ex6iVObo6WBQHBsz0sBCQ8usNQF8QuAGFZN7g4GO2rDe X-Received: by 10.14.198.200 with SMTP id v48mr74488een.5.1400785545320; Thu, 22 May 2014 12:05:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.247 with SMTP id b110ls1340996qge.16.gmail; Thu, 22 May 2014 12:05:44 -0700 (PDT) X-Received: by 10.224.20.72 with SMTP id e8mr17134463qab.86.1400785544397; Thu, 22 May 2014 12:05:44 -0700 (PDT) Original-Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [2607:f8b0:400d:c01::232]) by mx.google.com with ESMTPS id n7si938927qas.81.2014.05.22.12.05.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 12:05:44 -0700 (PDT) Received-SPF: pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:400d:c01::232 as permitted sender) client-ip=2607:f8b0:400d:c01::232; Original-Received: by mail-qc0-f178.google.com with SMTP id l6so6383500qcy.23 for ; Thu, 22 May 2014 12:05:44 -0700 (PDT) X-Received: by 10.224.2.193 with SMTP id 1mr17571111qak.100.1400785544176; Thu, 22 May 2014 12:05:44 -0700 (PDT) Original-Sender: dribeas@gmail.com Original-Received: by 10.140.42.182 with HTTP; Thu, 22 May 2014 12:05:44 -0700 (PDT) In-Reply-To: <8ade6aeb-a949-42f9-8cc6-1f0bf3aec72e@isocpp.org> X-Original-Sender: dibeas@ieee.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:400d:c01::232 as permitted sender) smtp.mail=dribeas@gmail.com; dkim=pass header.i=@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:10765 Archived-At: --001a11c3cdeec46b4e04fa01cc5d Content-Type: text/plain; charset=UTF-8 I am not sure I buy into the rationale. From a pedagogical perspective, hiding the 'const' is not helping the beginners into a should use "const" everywhere situation, but rather buy into dark magic: use cauto if that fails to compile use auto. Reasoning about might be surprising for beginners, consider for example this perfectly valid code: [](cauto x) { ++x; }(1); // [](const auto x) { ++x; }(1) Note that the issue here is that you don't really want 'const auto', but 'const auto&' to be the default. Not pushing the reference into cauto allows for the above, pushing the reference into it would hide an important bit of information from the interface that would look like a value when it is a reference. If to be able to reason about what the code does the programmer needs to mentally expand 'cauto' into 'const auto' then there is no advantage other than less typing, and a possible loss of clarity. All that being said, I am still stuck in C++03, so take this at face value :) David On Thu, May 22, 2014 at 2:53 PM, wrote: > >>That's a bug (or deficiency, at least) in the IDE > No, no, IDE just rightfully goes to definition of the macro and not > deduced type :) But that is not the point. > > What I want is > 1) to find out if there is a common need in this particular shortcut or > some more general instrument allowing to achieve the same syntax (because I > personally find it convenient and very widely applicable). > 2) to get an answer to the question "Is such a shortcut can be introduced > with a context sensitive identifier?" > > P.S. My posts got constantly deleted for some reason (including my answer > to David Krauss). > > On Thursday, May 22, 2014 9:44:30 PM UTC+4, Matthew Woehlke wrote: > >> On 2014-05-22 05:49, vadim.pet...@gmail.com wrote: >> > #define const auto cauto >> > It is bad, and not only because of an abstract "macros are bad in >> general", >> > but because of practical interaction with tools. For example, in Visual >> > Studio you can "Go To Definition" of the deduced type with keyword >> auto, >> > but not with macro cauto. >> >> That's a bug (or deficiency, at least) in the IDE. Somehow I don't see >> adding a feature to the standard for this reason as being a good thing. >> (Never mind that the IDE would still need to be taught how to parse it, >> so you haven't really gained anything.) >> >> -- >> Matthew >> >> -- > > --- > 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. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. --001a11c3cdeec46b4e04fa01cc5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not sure I buy into the rationale. From a pedagogical= perspective, hiding the 'const' is not helping the beginners into = a should use "const" everywhere situation, but rather buy into da= rk magic: use cauto if that fails to compile use auto. Reasoning about migh= t be surprising for beginners, consider for example this perfectly valid co= de:

[](cauto x) { ++x; }(1); =C2=A0 // [](const auto x) { ++x; }(1)

= Note that the issue here is that you don't really want 'const auto&= #39;, but 'const auto&' to be the default. Not pushing the refe= rence into cauto allows for the above, pushing the reference into it would = hide an important bit of information from the interface that would look lik= e a value when it is a reference.

If to be able to reason about what the code does the programmer needs t= o mentally expand 'cauto' into 'const auto' then there is n= o advantage other than less typing, and a possible loss of clarity.

All that being said, I am still stuck in C++03, so take this at face va= lue :)

=C2=A0 =C2=A0 David


<= div class=3D"gmail_quote">On Thu, May 22, 2014 at 2:53 PM, <va= dim.petrochenkov@gmail.com> wrote:
>&g= t;That's a bug (or deficiency, at least) in the IDE
No, no, ID= E just rightfully goes to definition of the macro and not deduced type :) B= ut that is not the point.

What I want is
1) to find out if there is a c= ommon need in this particular shortcut or some more general instrument allo= wing to achieve the same syntax (because I personally find it convenient an= d very widely applicable).
2) to get an answer to the question "Is such a shortcut can be in= troduced with a context sensitive identifier?"

P.S. My posts=C2=A0got constantly deleted for some reason (including my a= nswer to David Krauss).

On Thursday, May 22, 2014 9:44:30 PM UTC+4, Matthew Woehlke wrote= :
On 2014-05-= 22 05:49, vadim.pet...@gmail.com wrote:
> #define const auto cauto
> It is bad, and not only because of an abstract "macros are ba= d in general",=20
> but because of practical interaction with tools. For example, in V= isual=20
> Studio you can "Go To Definition" of the deduced type wi= th keyword auto,=20
> but not with macro cauto.

That's a bug (or deficiency, at least) in the IDE. Somehow I don= 9;t see
adding a feature to the standard for this reason as being a good thing.
(Never mind that the IDE would still need to be taught how to parse it,
so you haven't really gained anything.)

--=20
Matthew

--

---
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-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/gro= up/std-proposals/.

--

---
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>.
--001a11c3cdeec46b4e04fa01cc5d-- .