220 29430 <6b73bf50-4189-4d5d-a2c0-2debb085659e@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: TONGARI J Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing string literals to match `char...` packs in templates Date: Wed, 16 Nov 2016 23:10:22 -0800 (PST) Lines: 188 Approved: news@gmane.org Message-ID: <6b73bf50-4189-4d5d-a2c0-2debb085659e@isocpp.org> References: <9de07b5f-f870-4a02-882f-54f9fdd12ffd@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5380_1809884440.1479366622806" X-Trace: blaine.gmane.org 1479366625 20077 195.159.176.226 (17 Nov 2016 07:10:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 17 Nov 2016 07:10:25 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCC3NA775MLBBX5PWXAQKGQEOFSY44I@isocpp.org Thu Nov 17 08:10:21 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f200.google.com ([209.85.192.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7Gpw-0004MQ-VW for gclcip-std-proposals@m.gmane.org; Thu, 17 Nov 2016 08:10:21 +0100 Original-Received: by mail-pf0-f200.google.com with SMTP id j128sf93619077pfg.4 for ; Wed, 16 Nov 2016 23:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references: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=1fNC3yf0YyOECYFsRMQsdrtQCzDjL701+J+Y8G22Bjk=; b=Ga77vlsdUJiRdgv66DLxuw61UevnWByJmVwzSL1Bq5y7SJeu7b3X7AE8yR3zBlMLZT tVBCw4lOhzSk6cV1M42rt3+zdheFGlDxleNkEHyWpk/E4KKAlJOjmqsWD7bpeBI/W2GM QZeTP6d2FyM6n24nUUTVEcDynweQ0JVlrBhhG3PPLMy+6PLSNQXRNUrFdq2W+XF0i2S2 aVJQuPx2UJZFlNttZVHxF46EeMgka5mR3r9doTwJ9Z+WVT5sDASlcLLmn9KCb/s551Ua 9epLsulMAzO0eRDZfJyA7sthNkJqR52lXHyHo9K6S5yw0u/4ZAcebKMxUYAXtXJ8sZPF X5kA== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=1fNC3yf0YyOECYFsRMQsdrtQCzDjL701+J+Y8G22Bjk=; b=Sq/kzcKMRg1yrOKM6mrWtHFPti6xwYNsfFmzhf8FNlhlmojy7yi/WCT+zSiER6vl6S 4eifIUrnxOoNufDyfp1R2g9NbOHVA/HwNzoeWG+V3c+t2hriekGSQvImiwhEBjEvcjYK gTKh9iK2SBRPdR+Xsj6shKP72Pr0h94rSZk95ozySF+sUUX+xG8oy6Xt6ii9UD7FCPYV oyJsd9YXoakkGai0EsFvqOBg8QNrIqW4d8C4gRtHUbwuwNcwm9jkNwatZDL3FNXSzUdr /hGF0bOX0sTHg4+RQRKdDtqm9YRDAnAahlGXQNTSgYovLtdsiw1Pr6zrrDB1JM245Ncr 6lLg== 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=1fNC3yf0YyOECYFsRMQsdrtQCzDjL701+J+Y8G22Bjk=; b=Y2fsccF8QnYy4Z6YngBCjD4ThiSKg/bGj7TzDZnxPsdxtfCvFw50bu0VnbC3fwhi/2 4GEu/lYTaSnmXlXeLF1h5Ph7RIujc8SUJfr1Ub8ILAiy8/soV2GxmHl/rY+HWPyHfz23 vanKKfozEPLB0qPCNwGJ6Z+4iWMg/Imszg7nOhLRaOaVTkwuLmVFHbHfNzCgu2+7W1rD BsfPzsdhMXxHGAIUKUxp8Lm8wTgYHcjp1zQE2wpPsY0VTGLynNu38YLtXh07Ih/FOz1p /anh9oZ4K7cTMY1pqnzLYMWGtaxWZt1Dvpf8zETbq5LcehuQGiA7QDBkFky7pjZx30f2 7GWQ== X-Gm-Message-State: ABUngvfdQYynb8kvMIUMH0MGi5ka10ixgf1Xt31Hpe4giNeX7O/w4eQhkpaIHGNudNbhWg== X-Received: by 10.99.168.9 with SMTP id o9mr563372pgf.115.1479366624041; Wed, 16 Nov 2016 23:10:24 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.22.198 with SMTP id s6ls3579876ots.33.gmail; Wed, 16 Nov 2016 23:10:23 -0800 (PST) X-Received: by 10.157.11.248 with SMTP id 111mr104066oth.4.1479366623232; Wed, 16 Nov 2016 23:10:23 -0800 (PST) In-Reply-To: X-Original-Sender: tongari95@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:29430 Archived-At: ------=_Part_5380_1809884440.1479366622806 Content-Type: multipart/alternative; boundary="----=_Part_5381_930922786.1479366622806" ------=_Part_5381_930922786.1479366622806 Content-Type: text/plain; charset=UTF-8 On Thursday, November 17, 2016 at 1:28:26 PM UTC+8, Louis Dionne wrote: > > Let me just expand a bit on what Matt said. > > I think this is a brilliant idea, but I don't think it's going to work, > for the same reason > as my P0424R0 paper was not warmly received. The reason is that > implementers > don't want anything that encourages the use of large template parameter > lists, > because the representation of that inside the compiler is too inefficient. > They don't > want a single template parameter per character in the string, because the > structure > that represents a template parameter in the compiler is expensive. > Instead, they'd > rather have a single structure that represents all the characters. I'm not > sure why they > can't just represent a character pack in a more efficient manner, but > that's what I > was told when I presented in EWG. > > So on Saturday, we tried looking into passing arrays as template > arguments, but > that becomes messy because arrays are already supported, but they decay to > pointers so we'd need to support a new syntax. We then tried passing > std::array, > but doing this cleanly would require passing arbitrary literal types as > template > arguments, which is also non-trivial of a change. > > I have not started writing a paper yet, because I don't have any solution > in mind > at this time to be honest. However, this is one of the most valuable > problems to > be solved for metaprogramming, so I'll take anything that works. > What about automatically generating types for string-literals? Probably with a built-in literal operator 'lit' that does the compiler magic. The generated type of a string-literal is guaranteed to be the same across TUs. Such a type should provide some constexpr methods/typedefs to access its intrinsic (e.g. size(), operator[], char_type, etc). For example: constexpr auto str = "Hello"lit; static_assert(is_same::value); static_assert(is_same::value); static_assert(s[0] == 'H'); Has idea like this been discussed? -- 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/6b73bf50-4189-4d5d-a2c0-2debb085659e%40isocpp.org. ------=_Part_5381_930922786.1479366622806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, November 17, 2016 at 1:28:26 PM UTC+8, Louis = Dionne wrote:
=
Let me just expand a bit on what Matt said.

I= think this is a brilliant idea, but I don't think it's going to wo= rk, for the same reason
as my P0424R0 paper was not warmly receiv= ed. The reason is that implementers
don't want anything that = encourages the use of large template parameter lists,
because the= representation of that inside the compiler is too inefficient. They don= 9;t
want a single template parameter per character in the string,= because the structure
that represents a template parameter in th= e compiler is expensive. Instead, they'd
rather have a single= structure that represents all the characters. I'm not sure why they
can't just represent a character pack in a more efficient manne= r, but that's what I
was told when I presented in EWG.
<= div>
So on Saturday, we tried looking into passing arrays as = template arguments, but
that becomes messy because arrays are alr= eady supported, but they decay to
pointers so we'd need to su= pport a new syntax. We then tried passing std::array,
but doing t= his cleanly would require passing arbitrary literal types as template
=
arguments, which is also non-trivial of a change.

=
I have not started writing a paper yet, because I don't have any s= olution in mind
at this time to be honest. However, this is one o= f the most valuable problems to
be solved for metaprogramming, so= I'll take anything that works.

=
What about= automatically generating types for string-literals?
Probably with a built-in=C2= =A0literal operator '= lit' that does the compiler magic.

The generated type of a string-literal=C2= =A0is guaranteed to be the same across TUs.
Such a type should pr= ovide some constexpr methods/typedefs to access its intrinsic (e.g. size(),= operator[], char_type, etc).

For example:
constexpr auto str =3D = "Hello"lit= ;
static_assert(is_same<decltype(str), decltype("Hello"lit)>::value);
<= span style=3D"color: #008;" class=3D"styled-by-prettify">static_assert(is_same<decltype(str)::char_type, ch= ar>::value= );
static_assert(s[0] =3D=3D<= /span> 'H');
<= br>Has idea like this been discussed?

--
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/6b73bf50-4189-4d5d-a2c0-2debb085659e= %40isocpp.org.
------=_Part_5381_930922786.1479366622806-- ------=_Part_5380_1809884440.1479366622806-- .