220 16790 <6ffb46f5-e2ef-4ebe-b304-2e10a4fd6cbd@isocpp.org> article Path: news.gmane.org!not-for-mail From: Scott Prager Newsgroups: gmane.comp.lang.c++.isocpp.general,gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: [c++std-core-27199] Re: [std-proposals] Re: Re: An implementation of enhanced auto deduction and abbreviated template syntax using Clang Date: Thu, 5 Mar 2015 17:22:10 -0800 (PST) Lines: 295 Approved: news@gmane.org Message-ID: <6ffb46f5-e2ef-4ebe-b304-2e10a4fd6cbd@isocpp.org> References: <7c7d06ea-1e25-4720-9486-ec068b514ea6@isocpp.org> <322c42f4-8a77-4d25-8874-029666dc29d9@isocpp.org> Reply-To: std-discussion@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_107_606478886.1425604930611" X-Trace: ger.gmane.org 1425604933 18799 80.91.229.3 (6 Mar 2015 01:22:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 6 Mar 2015 01:22:13 +0000 (UTC) Cc: std-proposals@isocpp.org, faisalv@gmail.com To: std-discussion@isocpp.org Original-X-From: std-discussion+bncBCU6PTE6UUGBBQ4C4STQKGQEIVFYCRQ@isocpp.org Fri Mar 06 02:22:13 2015 Return-path: Envelope-to: gclcig-std-discussion@m.gmane.org Original-Received: from mail-qg0-f72.google.com ([209.85.192.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YTgxw-0001bG-6j for gclcig-std-discussion@m.gmane.org; Fri, 06 Mar 2015 02:22:12 +0100 Original-Received: by qgdq107 with SMTP id q107sf32117299qgd.3 for ; Thu, 05 Mar 2015 17:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=qoMDTjLqYXdqv80zTB8Zk1SRcNvk8n9n7hJd/dedIdU=; b=mbF22lVbvJjCX7DLNr2ReOQpZD0xG4syrm4w2FBdXWV0yY01j9RH34u6woZO3v8mUN vf/xCgUqpoMvEnUuULb4u+1QXcS0slm4R+npQra3FBai+/j7lEoCQDRhkYldqsDyO+K6 RsrfN2qemSzPuOe1RvfDvKqddd5vBk1IjjjW9DkraVZG3RxqzFL0XdwpeyW7i6QHNGL7 elGh9Ql6wn4H2PXPTaVJRMYxxiz6aWHL0ZHNd/jLHIEy8SIaRu2n40AwfJbU+aFhU0OV Hw7dQEJCpcQOoF1/VsHqVlrI+JlXWg230qh4PP1CQGVjCcTtWyrzebt1YA3M/0fsjPdw H8rQ== 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:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=qoMDTjLqYXdqv80zTB8Zk1SRcNvk8n9n7hJd/dedIdU=; b=P0oQMC+elhXmfOXn0arKXHmshYhOD1sjP9PVU6mGnWndzfgh1fo+kpOPS+Rtm7erIK 0JHxy/0LmGhxYbQ0GwQfnk6/2SRYaJcAh7L4KKWiPoWcsV+rSCRwQWNhFdedJ+eqxYPc /g/lKRlTZIKL9ZcMR2Zx7wioWgLcp7cgIb1EoS570VssrwQr2AbontLL1aSD1+9Q0s3+ dllcU3ltHxSgsE9DULAUfHv4yQ/nAQfaJovvYKpHPDjtUEpY3aLEgrwPBrbCLBoSCaV4 4/guWlvT2sbUcLwpmMiB3rahrfdOyHPva3+WmPkKhyGQCJw5cEIPONP0RtFCCNPN6ziI G7NQ== X-Gm-Message-State: ALoCoQkJFZJPZML/HU4lzpS5Tt++55T3x1X/7JQFBvxMaWGBLzhlSbLiWY3O4IIs+3S/Eaqre1uV X-Received: by 10.236.42.228 with SMTP id j64mr12587927yhb.36.1425604931330; Thu, 05 Mar 2015 17:22:11 -0800 (PST) X-BeenThere: std-discussion@isocpp.org Original-Received: by 10.140.104.241 with SMTP id a104ls105259qgf.11.gmail; Thu, 05 Mar 2015 17:22:10 -0800 (PST) X-Received: by 10.140.36.134 with SMTP id p6mr221552qgp.26.1425604930858; Thu, 05 Mar 2015 17:22:10 -0800 (PST) In-Reply-To: X-Original-Sender: SplinterOfChaos@gmail.com Precedence: list Mailing-list: list std-discussion@isocpp.org; contact std-discussion+owners@isocpp.org List-ID: X-Google-Group-Id: 495566654649 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.general:4996 gmane.comp.lang.c++.isocpp.proposals:16790 Archived-At: ------=_Part_107_606478886.1425604930611 Content-Type: multipart/alternative; boundary="----=_Part_108_1133248340.1425604930611" ------=_Part_108_1133248340.1425604930611 Content-Type: text/plain; charset=UTF-8 I can see where a lot of discomfort might come, here... *(1) *Just plain auto seems imprecise and it makes template functions look like non-template functions. *(2) *Named template parameters seem to provide comparatively more information. For *(1)*, this seems like a special case. When you consider inlining, changing functions that take reference parameters of basic types to pass by value, and other such optimizations our compilers perform, functions have never really been the concrete entities we like to think of them as. I don't see a need to distinguish between template and non-template functions from a user point-of-view, except when using *extern "C"*. *(2)*: As mentioned, one can always fall back on normal template syntax, but also, I don't know about anyone else, but I tend to name my types verbosely, and my variables tersely. So I'll write... template void for_each(Sequence& seq, UnaryFunction f) { for(auto&& x : seq) f(x); } ....but with auto as the parameter type, I would reverse this trend: void for_each(auto& sequence, auto unary_op) { for(auto&& x : sequence) unary_op(x); } ....and I think that reads better. Another reason I think we should embrace this: It brings template code within reach of absolute beginners, both to C++ and programming in general. Trying to teach an initiate what this means... template auto f(Function fn, Value v) { return fn(v); } requires teaching the meaning on "*typename*" (because the user may not have needed typedefs or type aliases at this point), *template<...>*, how " *Function*" and "*Value*" do not denote real types, etc., etc.. But explaining this... auto f(auto fn, auto val) { return fn(val); } ....well, they probably already are familiar with *auto*, using *auto* as a parameter is intuitive, and those familiar with dynamic languages will feel right at home, while benefiting from static typing. On Thursday, March 5, 2015 at 6:52:40 PM UTC-5, Ville Voutilainen wrote: > > On 6 March 2015 at 01:43, Matthew Fioravante > wrote: > >> void frob(auto t) > >> { > >> // if I want to use 'T' here, I need to do a decltype(t) to get at > it > >> } > > You may need remove pointer, ref, and/or cv qualifiers if you use auto*, > > auto&& (perfect forwarding), const auto&, etc.. using type_traits. If > the > > signature changes, you'll have to remember to fix the traits you used. > > Yes. Not that the "signature changes" is all that much different from an > old-skool template. > > > If your implementation needs to express type T, it might be better to > use > > the old template syntax. > > Perhaps so. That may be a fairly big "if". > -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org. To post to this group, send email to std-discussion@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion/. ------=_Part_108_1133248340.1425604930611 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I can see where a lot of discomfort might come, here.= ... 

(1) Just plain auto seems imprecis= e and it makes template functions look like
non-template function= s.

(2) Named template parameters seem to pr= ovide comparatively more information.

For (1), this seems like a special case. When you consider inlining, changing
functions that take reference parameters of basic types to pass by = value, and
other such optimizations our compilers perform, functi= ons have never really
been the concrete entities we like to think= of them as. I don't see a need to
distinguish between template a= nd non-template functions from a user
point-of-view, except when = using extern "C".

(2): As mentioned,= one can always fall back on normal template syntax, but
also, I = don't know about anyone else, but I tend to name my types verbosely,
<= div>and my variables tersely. So I'll write...

template<class Seq= uence, class UnaryFunction>
void for_each(Sequence& seq, UnaryFunction f) { for(auto&a= mp;& x= :<= span style=3D"color: #000;" class=3D"styled-by-prettify"> seq) f(x); }=


...but with au= to as the parameter type, I would reverse this trend:

<= div>
void for_each(auto& sequence, auto unary_op) { for(auto&= & x : sequence) unary_op(x); }

...and I think that reads= better.

Another reason I think we should embrace = this: It brings template code within
reach of absolute beginners,= both to C++ and programming in general. Trying to
teach an initi= ate what this means...

templ= ate<typename Function, typename Value>
auto f<= /span>(Function fn, Value v) {<= /span> return fn(v); }

requires teaching t= he meaning on "typename" (because the user may not have
ne= eded typedefs or type aliases at this point), template<...>, h= ow "Function"
and "Value" do not denote real types,= etc., etc.. But explaining this...

=
auto f(= auto fn, auto val) { return fn(val); }

...= well, they probably already are familiar with auto, using auto as a
parameter is intuitive, and those familiar with dynamic la= nguages will feel
right at home, while benefiting from static typ= ing.

On Thursday, March 5, 2015 at 6:52:40 PM UTC-5, Ville Vou= tilainen wrote:
On 6 March 2015= at 01:43, Matthew Fioravante <fmatth...@gmail.com> wrote:
>> void frob(auto t)
>> {
>>     // if I want to use 'T' here, I need to do a dec= ltype(t) to get at it
>> }
> You may need remove pointer, ref, and/or cv qualifiers if you use = auto*,
> auto&& (perfect forwarding), const auto&, etc.. using = type_traits. If the
> signature changes, you'll have to remember to fix the traits you u= sed.

Yes. Not that the "signature changes" is all that much different from a= n
old-skool template.

> If your implementation needs to express type T, it might be better= to use
> the old template syntax.

Perhaps so. That may be a fairly big "if".

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-discus= sion+unsubscribe@isocpp.org.
To post to this group, send email to std-discussion@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion= /.
------=_Part_108_1133248340.1425604930611-- ------=_Part_107_606478886.1425604930611-- .