220 29480 <294698be-341d-4131-bfef-613076db9398@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing string literals to match `char...` packs in templates Date: Fri, 18 Nov 2016 13:31:50 -0800 (PST) Lines: 181 Approved: news@gmane.org Message-ID: <294698be-341d-4131-bfef-613076db9398@isocpp.org> References: <9de07b5f-f870-4a02-882f-54f9fdd12ffd@isocpp.org> <35fe3945-71cf-4958-8f92-59df0ef98fae@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6725_724601254.1479504711049" X-Trace: blaine.gmane.org 1479504717 29875 195.159.176.226 (18 Nov 2016 21:31:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 18 Nov 2016 21:31:57 +0000 (UTC) Cc: inkwizytoryankes@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIMPZV5YECRUBA67H56I@isocpp.org Fri Nov 18 22:31:51 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f199.google.com ([209.85.213.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c7qlB-0006CS-63 for gclcip-std-proposals@m.gmane.org; Fri, 18 Nov 2016 22:31:49 +0100 Original-Received: by mail-yb0-f199.google.com with SMTP id d128sf331570204ybh.6 for ; Fri, 18 Nov 2016 13:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=bYBT59l5SqFjKcgpwXP6IcCtv2YaIjx+Ct1U6vDtnT8=; b=cEsVtZ9VdwmEeO+RN33iLdzUhUOnfRm0lqIJ6L/rBxDS6CvXB1sHxkcuwbvghFjADm bHih8DvXUg3l9+T6ueFnGMEmxuhQ0mp4EMzs0sJf9C7isxk/VkC5S+ebp0YsvT/UzQVD x3OrVMa2qvsIEpehYg0Eo5RokXXFYl+6/+zeYRRDL07As0/FL/qedVDdXmWbllPvd4yV E3S9OivGep40gJJ46tfl+S7TrXhSlFm8BU62dXjfgUkGPGKQweP5d4v0evCd+erNX9ub 3irutsOUv8Bv3AY4qEfEfsbdYLF6RYCPjoLGUCHARCqsR9gSY03wpm0vPp4HLE0BDEsC ib+w== 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: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=bYBT59l5SqFjKcgpwXP6IcCtv2YaIjx+Ct1U6vDtnT8=; b=roG3pv24onGfTXv+58Y8bOCI60HXeKhF2mKTh878TVz1Am3xF6iz4VLfd3Pj1fUN6H zIheU+tNNhBE5kSQ610kysD1PgMniEC4BQx/mzjZWRtNTlSl+eqxgXyQL4SrZbLf0ml/ 5L4UohmUBCzLVBNwd0WhFgvMShajECBRdmAj3OlFdh/pxLJVKOA6xyF6Ys4xVUjH+isJ 6qInyPBrfuBY+LovgjAkw3I0Ww7vA0KeQc0oP0RkfYDcrvyFEKXjoNJi4lPr7fus90+R xEnB0TE3twHe1t/nenSE726h1zETyP520MnLGObN4bpZFUQOiZ597Vnf4HBBwcG08ywA nYIw== 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: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=bYBT59l5SqFjKcgpwXP6IcCtv2YaIjx+Ct1U6vDtnT8=; b=ME9eZZnz2mRWcw2qfSq8KxgcHd3qHGQqafDOre1xGHExSSVEMJYghJ/ZBAQjaRly6r dhdM2f780jC64nYXga0sS9U2zdMg7bpKDeeZFplk/i+8wtbTqjq9zjEsgCIES1RZdd94 lzuNSVQ+ioyAs2F70/mrlfmYUuv/ut6339GGh3bJ8M7bBydDV257mEzMM34SC8iuhkNe W7DaUEFgvnSOXpbKnJRvsV2oTqhCONELeQAX6NsV1shVgdtC+PbApikvO4CRN3eO9Ktg 6Fy30ZPXB4E9tYTE3UcHmswTGLWJSnhJT+I+Pmg34JzSUh/3Xhevs0Le5wWkq/s0gE2M iyUA== X-Gm-Message-State: AKaTC0088fJUBVBtiTEcbUxAJ0C8TL/iZ7wJw+tTb4nqgSFifHISE2lCPwt0GmHpf1RCgQ== X-Received: by 10.129.4.130 with SMTP id 124mr551524ywe.161.1479504712510; Fri, 18 Nov 2016 13:31:52 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.43.24 with SMTP id o24ls1036345otb.41.gmail; Fri, 18 Nov 2016 13:31:51 -0800 (PST) X-Received: by 10.157.20.197 with SMTP id r5mr258612otr.9.1479504711461; Fri, 18 Nov 2016 13:31:51 -0800 (PST) In-Reply-To: <35fe3945-71cf-4958-8f92-59df0ef98fae@isocpp.org> X-Original-Sender: arthur.j.odwyer@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:29480 Archived-At: ------=_Part_6725_724601254.1479504711049 Content-Type: multipart/alternative; boundary="----=_Part_6726_1502113927.1479504711049" ------=_Part_6726_1502113927.1479504711049 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, November 18, 2016 at 12:47:32 PM UTC-8, inkwizyt...@gmail.com=20 wrote: > > On Thursday, November 17, 2016 at 6:28:26 AM UTC+1, 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,= =20 >> for the same reason >> as my P0424R0 paper was not warmly received. The reason is that=20 >> implementers >> don't want anything that encourages the use of large template parameter= =20 >> lists, >> because the representation of that inside the compiler is too=20 >> inefficient. They don't >> want a single template parameter per character in the string, because th= e=20 >> structure >> that represents a template parameter in the compiler is expensive.=20 >> Instead, they'd >> rather have a single structure that represents all the characters. I'm= =20 >> not sure why they >> can't just represent a character pack in a more efficient manner, but=20 >> that's what I >> was told when I presented in EWG. >> > > Fact that storing string in template parameters list is ineffective did= =20 > not stop GCC and Clang from implementing this: > https://godbolt.org/g/VjJzJi > https://godbolt.org/g/1DVftM > Thanks to that we can test how far we need push compilers to break when w= e=20 > use this UDL. > My uninformed opinion matches inkwizytor's. Louis, I think you'll have to= =20 be more specific when you claim that "implementors" find P0424R0=20 objectionable. Given that two of the let's-say-four major vendors have=20 already managed to implement P0424R0, who could the holdouts be?=20 Microsoft? EDG? Or GCC and/or Clang being like "We'll implement this,=20 but we'll grump about it"? The situation seems analogous to std::make_integer_sequence<>, which I know= =20 is near and dear to your heart: we've got implementations already in the=20 wild, and it's super useful for metaprogramming, but naive implementations= =20 are (claimed to be) slow. So, why not apply the same solution, which was to= =20 improve the compiler's internal mechanisms without compromising on the=20 source-level API? [Admittedly I'm oversimplifying; the most obvious reason not to "improve"= =20 the compiler mechanisms (e.g. by creating a special efficient=20 representation for template-argument-lists all of whose elements are=20 'char') is that it would add code and complexity (and cognitive overhead,= =20 and test load, and bugs) to the compiler.] Another idea to improve the shippability of P0424R0 would be to specify a= =20 separate implementation-defined limit on the number of characters in a UDL= =20 of this form; e.g., if some vendor wants to make it a hard error to use=20 string UDLs longer than 64 characters, I think that would be 100% fine with= =20 today's working programmers, and the limit could easily be increased in=20 C++3x if there were a consensus among the vendors. my $.02, =E2=80=93Arthur --=20 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 e= mail 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/294698be-341d-4131-bfef-613076db9398%40isocpp.or= g. ------=_Part_6726_1502113927.1479504711049 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, November 18, 2016 at 12:47:32 PM UTC-8, inkwizy= t...@gmail.com wrote:
On Thursday, November 17, 2016 at 6:28:26 AM UTC+1, Louis Dionne w= rote:
Let me j= ust expand a bit on what Matt said.

I think this i= s a brilliant idea, but I don't think it's going to work, for the s= ame reason
as my P0424R0 paper was not warmly received. The reaso= n is that implementers
don't want anything that encourages th= e use of large template parameter lists,
because the representati= on 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 th= at represents all the characters. I'm not sure why they
can&#= 39;t just represent a character pack in a more efficient manner, but that&#= 39;s what I
was told when I presented in EWG.

Fact that storing string in template parameters list is ineff= ective did not stop GCC and Clang from implementing this:
https://= godbolt.org/g/VjJzJi
https://godbolt.org/g/1DVftM
Thanks = to that we can test how far we need push compilers to break when we use thi= s UDL.

My uninformed opinio= n matches inkwizytor's. =C2=A0Louis, I think you'll have to be more= specific when you claim that "implementors" find P0424R0 objecti= onable. =C2=A0Given that two of the let's-say-four major vendors have a= lready managed to implement P0424R0, who could the holdouts be? =C2=A0Micro= soft? =C2=A0EDG? =C2=A0Or GCC and/or Clang being like "We'll imple= ment this, but we'll grump about it"?

The= situation seems analogous to std::make_integer_sequence<>, which I k= now is near and dear to your heart: we've got implementations already i= n the wild, and it's super useful for metaprogramming, but naive implem= entations are (claimed to be) slow. So, why not apply the same solution, wh= ich was to improve the compiler's internal mechanisms without compromis= ing on the source-level API?

[Admittedly I'm o= versimplifying; the most obvious reason not to "improve" the comp= iler mechanisms (e.g. by creating a special efficient representation for te= mplate-argument-lists all of whose elements are 'char') is that it = would add code and complexity (and cognitive overhead, and test load, and b= ugs) to the compiler.]

Another idea to improve the= shippability of P0424R0 would be to specify a separate implementation-defi= ned limit on the number of characters in a UDL of this form; e.g., if some = vendor wants to make it a hard error to use string UDLs longer than 64 char= acters, I think that would be 100% fine with today's working programmer= s, and the limit could easily be increased in C++3x if there were a consens= us among the vendors.

my $.02,
=E2=80=93= Arthur

--
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/294698be-341d-4131-bfef-613076db9398= %40isocpp.org.
------=_Part_6726_1502113927.1479504711049-- ------=_Part_6725_724601254.1479504711049-- .