220 14212 <3dc9956d-e7ba-45af-9563-16a21eb621e9@isocpp.org> article Path: news.gmane.org!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: User defined literal for size_t Date: Fri, 24 Oct 2014 00:22:52 -0700 (PDT) Lines: 227 Approved: news@gmane.org Message-ID: <3dc9956d-e7ba-45af-9563-16a21eb621e9@isocpp.org> References: <92f06dea-7599-4641-8448-f2c0904d520a@isocpp.org> <2d4aa4bc-cbd2-42ca-916c-84447e780502@isocpp.org> <5d16eb2e-916c-473c-bd15-969be8355037@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1178_194910878.1414135372192" X-Trace: ger.gmane.org 1414247573 6240 80.91.229.3 (25 Oct 2014 14:32:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Oct 2014 14:32:53 +0000 (UTC) Cc: rhalbersma@gmail.com, rhalbersma@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDKLT4PURQHRBDPJV2RAKGQE7MBSJNQ@isocpp.org Sat Oct 25 16:32:47 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f71.google.com ([209.85.216.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xi2Od-0007Vl-Hc for gclcip-std-proposals@m.gmane.org; Sat, 25 Oct 2014 16:32:47 +0200 Original-Received: by mail-qa0-f71.google.com with SMTP id v10sf7648829qac.2 for ; Sat, 25 Oct 2014 07:32:46 -0700 (PDT) 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=Iptpw3z+TG2lx7hMED9Fz/QrC3Euri2qBy0zuu9ofeI=; b=cy36Phg7cmIy3WuYhW/7F15/CwF3QIt6agbSmoOniRvBY2G0UuIFqzYbYFa/x0guhM /zqmyj873GDrKSenaVAxtZSrWPTJTj+Ot+8L8/a5ymigOnqQVaevWib/3/n/aKE3kZ+4 uoiWmed/WLvUP1qLOgrP/6/IlfVkUCNMyTZo6ebJaJLrNQPYWV2CtKkIVuW3ZSGUkNAf IZtJYKzYNkeVAzxoCvItgH0nE02HV0qIqLWzQlAGOiuED5kRqGdwSHDlDfpmSnP0FxwN 4NCPHe4fQ5RoVWGi3BW8xjCdOZt/k+UzrZI8j60jETWCzJ/YJbpk8uzfd2w7MTnNWtDZ TfaA== X-Gm-Message-State: ALoCoQmue17W0QjPudfhAq3aYZ2nPttkQ7pwi/8jzqsk9qZSz0G77aElLmy0LTY9RpdsRKD6DWEm X-Received: by 10.236.66.102 with SMTP id g66mr12286208yhd.3.1414247566436; Sat, 25 Oct 2014 07:32:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.46.231 with SMTP id u100ls1090667iou.72.gmail; Sat, 25 Oct 2014 07:32:45 -0700 (PDT) X-Received: by 10.70.63.106 with SMTP id f10mr1321231pds.1.1414247565716; Sat, 25 Oct 2014 07:32:45 -0700 (PDT) Original-Received: by 10.50.227.172 with SMTP id sb12msigc; Fri, 24 Oct 2014 00:22:53 -0700 (PDT) X-Received: by 10.50.78.135 with SMTP id b7mr22846igx.14.1414135373032; Fri, 24 Oct 2014 00:22:53 -0700 (PDT) In-Reply-To: X-Original-Sender: myriachan@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:14212 Archived-At: ------=_Part_1178_194910878.1414135372192 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, October 23, 2014 1:04:35 AM UTC-7, rhalb...@gmail.com wrote: > > On Tuesday, October 21, 2014 11:36:18 PM UTC+2, Daniel Kr=C3=BCgler wrote= : >> >> 2014-10-21 22:30 GMT+02:00 Myriachan :=20 >> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1266=20 >> =20 >> >> My recommendation for the proposal is to refer to this CWG issue as well= ..=20 >> >> - Daniel=20 >> > > I spotted two more issues (1620 and 1735). Attached an updated draft=20 > proposal.=20 > Perhaps a proposal could fix the 1620, 1723 and 1735 issues? Here are some= =20 things I think user-defined literals need: 1. An operator "" function may take a single parameter of=20 non-enumeration non-bool integral type, or floating-point type(*). =20 (Don't permit cv-qualification; it's pointless.) Having more than one f= or=20 a given suffix is ill-formed. =20 2. Signed types are allowed, but programmers ought to be aware that=20 negative "literals" are actually a unary minus operator applied to a=20 literal, and thus negative values never actually get passed to operator= =20 "" functions taking a signed type as a parameter. =20 3. Use of a numeric literal with an operator "" function taking numeric= =20 type such that that literal overflows the numeric type is ill-formed. =20 4. Integral and floating-point literals passed to operator "" functions= =20 of the two signatures: =20 *T* operator "" *X*(const *[volatile]* char *) template <*some nonzero or variable number of chars*> *T* operator "" *X= * () =20 for type T and *ud-suffix* X would take a string of arbitrary length of= =20 the general grammar of a numeric literal, but possibly exceeding the=20 maximum length of a literal of any standard or extended-precision type,= =20 optionally up to an implementation-defined limit. This=20 implementation-defined limit would be at least sufficient to express any= =20 nonnegative value of integral type T, or the same length as supported=20 for ordinary floating-point literals of floating-point type T. =20 5. operator "" for string literals may have a new template form roughly= =20 corresponding to that available with numeric literals: =20 template T operator "" X() =20 where C is one of char, char16_t, char32_t or wchar_t, T is arbitrary,= =20 and X is the *ud-suffix*. The characters of the concatenated=20 ([lex.ext]/6) string literal would become non-type template parameters o= f=20 type C to this function. (This I believe is already a paper. This one= =20 is actually considered undesirable for some reason...?) =20 6. Make multi-character character constants legal for user-defined=20 literals; such literals would work like string literals, except that a) = a=20 character literal of exactly one character can call the old style (both= =20 existing would be ill-formed) b) an unused "int" parameter is added to = the=20 function parameters to distinguish character literals from string=20 literals. Concatenation of character literals would be supported, but o= nly=20 for user-defined literals. Same for empty character literals. =20 Concatenation of character literals for built-in multi-character charact= er=20 literals would be conditionally supported; an implementation supporting= =20 multi-character character literals would have to support concatenation f= or=20 built-in characters. =20 Does what I wrote seem reasonable? Melissa --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_1178_194910878.1414135372192 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thursday, October 23, 2014 1:04:35 AM UTC-7, rhalb...@g= mail.com wrote:
On Tuesday, October 21, 2014 11:36:18 PM UTC+2, Daniel Kr=C3=BCgler wrote= :
2014-10-21 22:30 GMT+02:00 Myriach= an <myri...@gmail.com>:
http://www.open-std.org= /jtc1/sc22/wg21/docs/cwg_active.html#1266

My recommendation for the proposal is to refer to this CWG issue as wel= l.

- Daniel

I spotted two more issues (1620 and 17= 35). Attached an updated draft proposal. 


Perhaps a proposal could fix the 1620, 1723 and 1735 issues? = Here are some things I think user-defined literals need:

  1. An= operator "" fun= ction may take a single parameter of non-enumeration non-bool integral type, or floating-po= int type(*).  (Don't permit cv-qualification; it's pointless.)  H= aving more than one for a given suffix is ill-formed.

  2. Signe= d types are allowed, but programmers ought to be aware that negative "liter= als" are actually a unary minus operator applied to a literal, and thus neg= ative values never actually get passed to operator "" functions taking a signed type as a p= arameter.

  3. Use of a numeric literal with an operator "" func= tion taking numeric type such that that literal overflows the numeric type = is ill-formed.

  4. Integral and floating-point literals passed = to operator "" functions of the two signatures:

    T operator "" X(const [volatile] char *)
    template <= some nonzero or variable number of chars> T operator "" X()

    for type T and ud-suffix = X would take a string of arbitrary length of the general gr= ammar of a numeric literal, but possibly exceeding the maximum length of a literal of any standard or extended-precision type, optionally up to= an implementation-defined limit.  This implementation-defined limit w= ould be at least sufficient to express any nonnegative value of integral ty= pe T, or the sam= e length as supported for ordinary floating-point literals of floating-poin= t type T.
  5. operator "" for string literals may have a new template form roughly correspondin= g to that available with numeric literals:

    template <class C, zero or more, or= variable number, non-type template parameters of type C>
    T operator "" X()

    where C is one of char, char16_t, char32_t or wchar_t, T is arbitrary, and X is the ud-suf= fix.  The characters of the concatenated ([lex.ext]/6) string lite= ral would become non-type template parameters of type C to this function.  (This I bel= ieve is already a paper.  This one is actually considered undesirable = for some reason...?)

  6. Make multi-character character constan= ts legal for user-defined literals; such literals would work like string li= terals, except that a) a character literal of exactly one character can cal= l the old style (both existing would be ill-formed)  b) an unused "int= " parameter is added to the function parameters to distinguish character li= terals from string literals.  Concatenation of character literals woul= d be supported, but only for user-defined literals.  Same for empty ch= aracter literals.  Concatenation of character literals for built-in mu= lti-character character literals would be conditionally supported; an imple= mentation supporting multi-character character literals would have to suppo= rt concatenation for built-in characters.



Does what= I wrote seem reasonable?

Melissa

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1178_194910878.1414135372192-- .