220 28131 <1db9b26d-f93f-d73a-446b-890507e602d7@honermann.net> article Path: news.gmane.org!.POSTED!not-for-mail From: Tom Honermann Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Implicit function template arguments enabling syntax, an alternative to abbreviated templates Date: Wed, 7 Sep 2016 11:17:32 -0400 Lines: 171 Approved: news@gmane.org Message-ID: <1db9b26d-f93f-d73a-446b-890507e602d7@honermann.net> References: <627640bf-62bf-491e-bea9-f76eec0033ec@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5B682552D136A33F0B193177" X-Trace: blaine.gmane.org 1473261466 23684 195.159.176.226 (7 Sep 2016 15:17:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2016 15:17:46 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDBNXSHG6UDBBEG7YC7AKGQEOSPSMRY@isocpp.org Wed Sep 07 17:17:38 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f198.google.com ([209.85.192.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhebY-0004yi-TM for gclcip-std-proposals@m.gmane.org; Wed, 07 Sep 2016 17:17:37 +0200 Original-Received: by mail-pf0-f198.google.com with SMTP id g202sf45061621pfb.3 for ; Wed, 07 Sep 2016 08:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=g3BGmZYErBiYlWvqQi+QNcSCJqX8/zzOXMUUPPnT428=; b=Hjdnx+zqE4boNzK+hC7MTQ5xLkkjSfVXQxV3dFpQgJizWtBMCIz5sQzCUw8RdgSx5i jcSkchLfeTtVXoI7eBeX2J9jtQ4zHFg84UpL42kgQAtWYBzukVEaeNvEra1GjQTlbuAc Yq4ABpHm31Za4/E03MKj7uJOMUb0IY5y3KuIhpFyM+HlLPV83VtjrXt0cX6in9UuM7cl eJlo99WgbOzhsIUCApCktwNAHKso4lTgiWzfvA9h5yuh1Na+Ha7BPYZ8PYO0qzejodbq 0COECEHywcrgG2MJl1wkBTPF31xoAtdpYVk7IZT3hsfiKTZKEfRJk7sSybYavv4Znmi/ WPYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=g3BGmZYErBiYlWvqQi+QNcSCJqX8/zzOXMUUPPnT428=; b=lUiYEHf3HZtgO1u4aNDSxM3X/v8V0+e9/TffeZ1oudQnXQ7zhOJUjP3RQQDM/5b6pN 74E9Fkpa1cP1yC5cKR9EIGK3fT9IbQ7AaNOpboRWo2/agwtu4Y6MMTbxPbdGmBxE5olP y/6GC9mS8d9I8PgLfvJEQz+ZZRlMXhuPQHlN3cQNNNHhJ+NPbbr3HQsUyIQiIIQn9kyM SKCDPb8jg/UlUkTEjreUzvWTaT6sd5b+ST84QcfeaVlkl2PlaKQ0TUhfIjhD8GN3K6hQ 5MRvFlV9zKRbFncuM4V1fMDFbogXBQPUntot8WX0vx5+OLAsjiTHP1/8fLXZxSxEtHvP RzMw== X-Gm-Message-State: AE9vXwNJsBXvpcPpbJ9H/L0sIlGnzvYyyMn3jLgJbaTBd7qgXLpdoZl43T5STT2fZNt2lA== X-Received: by 10.66.150.4 with SMTP id ue4mr36377578pab.18.1473261457778; Wed, 07 Sep 2016 08:17:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.27.100 with SMTP id l91ls481859otl.14.gmail; Wed, 07 Sep 2016 08:17:36 -0700 (PDT) X-Received: by 10.202.193.136 with SMTP id r130mr36780659oif.32.1473261456256; Wed, 07 Sep 2016 08:17:36 -0700 (PDT) Original-Received: from smtp83.ord1c.emailsrvr.com (smtp83.ord1c.emailsrvr.com. [108.166.43.83]) by mx.google.com with ESMTPS id q58si1446076otq.38.2016.09.07.08.17.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Sep 2016 08:17:36 -0700 (PDT) Received-SPF: neutral (google.com: 108.166.43.83 is neither permitted nor denied by best guess record for domain of tom@honermann.net) client-ip=108.166.43.83; Original-Received: from smtp3.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id ACAF8A00AC for ; Wed, 7 Sep 2016 11:17:35 -0400 (EDT) X-Auth-ID: tom@honermann.net Original-Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: tom-AT-honermann.net) with ESMTPSA id 04ADDA01A1 for ; Wed, 7 Sep 2016 11:17:34 -0400 (EDT) X-Sender-Id: tom@honermann.net Original-Received: from [10.12.197.214] (us02-rap-1.synopsys.com [198.182.60.251]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:587 (trex/5.7.7); Wed, 07 Sep 2016 11:17:35 -0400 In-Reply-To: <627640bf-62bf-491e-bea9-f76eec0033ec@isocpp.org> X-Original-Sender: tom@honermann.net X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 108.166.43.83 is neither permitted nor denied by best guess record for domain of tom@honermann.net) smtp.mailfrom=tom@honermann.net 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:28131 Archived-At: This is a multi-part message in MIME format. --------------5B682552D136A33F0B193177 Content-Type: text/plain; charset=UTF-8; format=flowed On 9/7/2016 10:01 AM, Ivan G. wrote: > How about the following function template syntax? An ellipsis in the > end of template argument list would allow the function template to use > extended functionality as generic lambdas of C++14 and possibly Concepts. > > template <...> > void foo(auto x) > { > } > > template > void bar(T x, auto y = 42) > { > } > > foo(42); // OK > foo(42); // Error? > bar(42); // OK > bar(42); // OK > bar(42); // Error? > > I heard abbreviated templates from Concepts were criticized in related > way. This would make the difference between plain functions and > function templates more clear. Sorry if this has already been discussed. I favor the above syntax over the existing design in the Concepts TS. I have seen this syntax briefly discussed, but I'm not aware of a thorough analysis. I think it would be great if someone (hint hint) wrote a paper proposing it. I think the "Error?" cases should be errors since nothing in the declaration creates an obvious connection between the deduced parameter type and the corresponding invented template parameter. The rules in the Concepts TS are clear on how this would work, but the association is fragile. For anyone wanting to revisit prior discussions regarding the design in the Concepts TS, review this thread: - https://groups.google.com/a/isocpp.org/d/topic/std-proposals/PaKP8EIIlEU/discussion My primary concerns expressed in that thread are here: - https://groups.google.com/a/isocpp.org/d/msg/std-proposals/PaKP8EIIlEU/xxhkPZrdnwoJ Tom. -- 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/1db9b26d-f93f-d73a-446b-890507e602d7%40honermann.net. --------------5B682552D136A33F0B193177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9/7/2016 10:01 AM, Ivan G. wrote:
How about the following function template syntax? An ellipsis in the end of template argument list would allow the function template to use extended functionality as generic lambdas of C++14 and possibly Concepts.

template <...>
void foo(auto x)
{
}

template <typename T,...>
void bar(T x, auto y =3D 42)
{
}

foo(42); // OK
foo<int>(42); // Error?
bar(42); // OK
bar<int>(42); // OK
bar<int, int>(42); // Error?

I heard abbreviated templates from Concepts were criticized in related way. This would make the difference between plain functions and function templates more clear. Sorry if this has already been discussed.

I favor the above syntax over the existing design in the Concepts TS.=C2=A0 I have seen this syntax briefly discussed, but I'm not aware = of a thorough analysis.=C2=A0 I think it would be great if someone (hint hint) wrote a paper proposing it.

I think the "Error?" cases should be errors since nothing in the declaration creates an obvious connection between the deduced parameter type and the corresponding invented template parameter.=C2=A0 The rules in the Concepts TS are clear on how this would work, but the association is fragile.

For anyone wanting to revisit prior discussions regarding the design in the Concepts TS, review this thread:
- https://groups.google.= com/a/isocpp.org/d/topic/std-proposals/PaKP8EIIlEU/discussion

My primary concerns expressed in that thread are here:
- https://groups.google.= com/a/isocpp.org/d/msg/std-proposals/PaKP8EIIlEU/xxhkPZrdnwoJ

Tom.

--
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.goog= le.com/a/isocpp.org/d/msgid/std-proposals/1db9b26d-f93f-d73a-446b-890507e60= 2d7%40honermann.net.
--------------5B682552D136A33F0B193177-- .