220 34708 <527c448b-b8dd-4877-b63f-b399c167da4d@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Mingxin Wang Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Extensions for Disambiguation Tags Date: Sun, 8 Oct 2017 19:08:01 -0700 (PDT) Lines: 123 Approved: news@gmane.org Message-ID: <527c448b-b8dd-4877-b63f-b399c167da4d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5111_544801364.1507514881268" X-Trace: blaine.gmane.org 1507514885 21509 195.159.176.226 (9 Oct 2017 02:08:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 9 Oct 2017 02:08:05 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNMBNHJWIGBBAVU5PHAKGQERJ5YF7Q@isocpp.org Mon Oct 09 04:08:01 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e1NU3-0004Fg-UR for gclcip-std-proposals@m.gmane.org; Mon, 09 Oct 2017 04:07:56 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id e46sf15435274uaa.6 for ; Sun, 08 Oct 2017 19:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=vOb2qk/NEEFIUomqVUjqn0G5SbOjhTPSZYf1LSXBc7s=; b=YkHbs18CC/1GKCIXkSRhjy5NUFdqsfp1UxsmZWL2KamtFfqS3pKlpbXVPhwU6zYFZL Dswtge0XF+PrNYHuyuam8m3ab0GgdBJMKyu8FtNDdgWPySQJUtVFVZmsLt1jf6eTnTiP PIJVRcAtEqfCl2kWsPQmtmoIYOPDMTbQRCAmxJZjEZVRugefQtJFr3x6dZ4auKcKpnLM TEmUKjE0JqPQiWsb4euv6ryrg2tiKHDqdoDYFGAJ7iwt+A8nb7rwr7gitCOWlmP5wuQr rtRjHRo3PYSxwKG5iRh1IMSNUHGzvFEv3Sd1VfXHSDZNe5OSg9XBE7JxenYutBcKze7+ X/qw== 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: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=vOb2qk/NEEFIUomqVUjqn0G5SbOjhTPSZYf1LSXBc7s=; b=Gu1uE0HCoKS7XmUO4cftCeK30ma+V6q6vrnG6TQoyOKaf1EBqeUcdf2mMarm0S8DVO bQdCGzViIXdIf3rzBfdLg8V4+Iq/u3QaJ5qUjv5mWn1YIF33Jx8hlC5Wm9YGj9HpNKIZ ZtuKtIMA+GSjpVdF1N6IFXvnjhLljOG9ogR+5UyM4csB3MBwRXVzZwm+7tlkiHiR+3qk KMupXR4f8MoYoF435oh+bLYqHi8ck7d0uuQ0v85/QRRnhOuXuGbN55rhgMIGUAp7uvN4 eLvswDcrf3x7A1rcYZTXiGt7Xz1ty5cCl/vs/YrvY0y+Xjdv5NCWQs7YhWkVNRUF+1r3 TA9w== X-Gm-Message-State: AMCzsaUp4OqHW4d+dJw/ocdmRy24ONzeFwkURJ/N/mlJoMtQQU6t6JTg kXzKbe5Dp9y2f9WybNqKiescUA== X-Google-Smtp-Source: AOwi7QAWB3Tp5pIMvNawJejLD15y4/VeOj0IQ8ZKPWI83l88ZtS79kz4Q+MbfrKH87FEu/IVAPz3EA== X-Received: by 10.176.20.239 with SMTP id f44mr1741392uae.84.1507514883140; Sun, 08 Oct 2017 19:08:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.60.206 with SMTP id j197ls873907vka.8.gmail; Sun, 08 Oct 2017 19:08:01 -0700 (PDT) X-Received: by 10.31.169.76 with SMTP id s73mr394761vke.14.1507514881854; Sun, 08 Oct 2017 19:08:01 -0700 (PDT) X-Original-Sender: wmx16835vv@163.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:34708 Archived-At: ------=_Part_5111_544801364.1507514881268 Content-Type: multipart/alternative; boundary="----=_Part_5112_1429278779.1507514881268" ------=_Part_5112_1429278779.1507514881268 Content-Type: text/plain; charset="UTF-8" I think the disambiguation tags defined in the standard are not enough to carry every sort of metadata required by function templates, and therefore I suggest the following two additional disambiguation tags: template struct in_place_arg_t { explicit in_place_arg_t() = default; }; template inline constexpr in_place_arg_t in_place_arg {}; template struct in_place_resource_t { explicit in_place_resource_t() = default; }; template inline constexpr in_place_resource_t in_place_resource {}; Users are allowed to pass constexpr values by `in_place_arg`, and pass static constexpr resources by `in_place_resource`. Additionally, I suggest that `in_place_index_t` should be an alias of `in_place_arg_t`: template using in_place_index_t = in_place_arg_t; Moreover, comparing to `in_place_arg_t`, I think `integral_constant` is inappropriately named, and there seem to be little necessity to define any member types or constants in it, because these metadata is already passed by templates. This design is also considered as a solution to another thread "Constexpr function parameters through special conversions " started by Nicol Bolas. The motivation of this design comes from the implementation of another unpublished proposal of mine about polymorphism (I am still working on it), and I found it useful when recursively calling constexpr functions in non-constexpr ones with custom input. I am looking forward to your comments and suggestions! Mingxin Wang -- 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/527c448b-b8dd-4877-b63f-b399c167da4d%40isocpp.org. ------=_Part_5112_1429278779.1507514881268 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the disambiguation tags defined in the standard ar= e not enough to carry every sort of metadata required by function templates= , and therefore I suggest the following two additional disambiguation tags:=

<= div class=3D"subprettyprint">
template <class T, T V>
st= ruct in_place_arg_t {
=C2=A0 explicit in= _place_arg_t() =3D default;
};
template <class T, T V>
inline constexpr in_place_arg_t<T, V> in_place_arg {}= ;

template <class T, const T& V>
struct in_place_resource_t {
=C2=A0 e= xplicit in_place_resource_t() =3D default;
};
template <class T, const T&= V>
inline constexpr in_place_resourc= e_t<T, V> in_place_resource {};

Users are allowed to pass constexpr values by `in_place_arg`, and pass s= tatic constexpr resources by `in_place_resource`.

= Additionally, I suggest that `in_place_index_t` should be an alias of `in_p= lace_arg_t`:

template <size_t I>
using in_p= lace_index_t =3D in_place_arg_t<size_t, I>;
<= br>
Moreover, comparing to `in_place_arg_t`, I think `integral_constant= ` is inappropriately named, and there seem to be little necessity to define= any member types or constants in it, because these metadata is already pas= sed by templates. This design is also considered as a solution to another t= hread "Constexpr function parameters through special c= onversions" started by Nicol Bolas.

The m= otivation of this design comes from the implementation of another unpublish= ed proposal of mine about polymorphism (I am still working on it), and I fo= und it useful when recursively calling constexpr functions in non-constexpr= ones with custom input.

I am looking forward to y= our comments and suggestions!

Mingxin Wang

--
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/527c448b-b8dd-4877-b63f-b399c167da4d= %40isocpp.org.
------=_Part_5112_1429278779.1507514881268-- ------=_Part_5111_544801364.1507514881268-- .