220 5318 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing any integral type as an argument for user defined literal operators Date: Sun, 7 Jul 2013 00:02:04 +0300 Lines: 97 Approved: news@gmane.org Message-ID: References: <80016e3a-2dc8-4887-b59b-a8aff20439e0@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c2c0eca340bc04e0de1fd0 X-Trace: ger.gmane.org 1373144527 19315 80.91.229.3 (6 Jul 2013 21:02:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jul 2013 21:02:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRBTML4KHAKGQEVVQPB7A@isocpp.org Sat Jul 06 23:02:08 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ve0-f198.google.com ([209.85.128.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UvZcN-0001Ko-Fb for gclcip-std-proposals@m.gmane.org; Sat, 06 Jul 2013 23:02:07 +0200 Original-Received: by mail-ve0-f198.google.com with SMTP id jz10sf4267631veb.1 for ; Sat, 06 Jul 2013 14:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:mime-version:in-reply-to:references:date:message-id :subject:from:to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-google-group-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=2wt2EB92i9xam4CLOqRmSqxIoEKfcA6SNB3NjB4Lnp4=; b=BbAu/LYoojAfaUX8BKRq60DNmGtwP2alJxbNYxru9R1Rabqksc+USWJ3I1HWpum3Gr MpDpLVA8lHjDKMPFIbyJLM4j/ug7LOCj39KTaAav3cJEx0LqiK/ReBigToR4KTeXRvMs iaR1uVBYAlaP0ljx9R5P/4XiAkLcxTkGiI0aQt9ghxXpGpJoscd23440sPzi6DMeASz4 qOruL1iIwADZc+lP/8iHIvEulaDCf5E+P60isqdETvkxLsBCT7AVHamdSsh3+187cHCZ 3LIcy8iV85wZYQiWDD1OZ64PQVzhmlZSlYSUjqt4cYS1/mqgpPxItE7XWcqtONKM9bxH erXg== X-Received: by 10.224.37.3 with SMTP id v3mr10916500qad.2.1373144526490; Sat, 06 Jul 2013 14:02:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.36.40 with SMTP id n8ls1477017qej.79.gmail; Sat, 06 Jul 2013 14:02:05 -0700 (PDT) X-Received: by 10.49.35.233 with SMTP id l9mr9863438qej.23.1373144525116; Sat, 06 Jul 2013 14:02:05 -0700 (PDT) Original-Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [2607:f8b0:400d:c02::235]) by mx.google.com with ESMTPS id f6si3933863qai.49.2013.07.06.14.02.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 14:02:05 -0700 (PDT) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c02::235 as permitted sender) client-ip=2607:f8b0:400d:c02::235; Original-Received: by mail-qe0-f53.google.com with SMTP id 1so1715352qee.12 for ; Sat, 06 Jul 2013 14:02:05 -0700 (PDT) X-Received: by 10.224.171.132 with SMTP id h4mr5106854qaz.98.1373144524995; Sat, 06 Jul 2013 14:02:04 -0700 (PDT) Original-Received: by 10.224.52.71 with HTTP; Sat, 6 Jul 2013 14:02:04 -0700 (PDT) In-Reply-To: <80016e3a-2dc8-4887-b59b-a8aff20439e0@isocpp.org> X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c02::235 as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@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:5318 Archived-At: --001a11c2c0eca340bc04e0de1fd0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6 July 2013 23:26, Micha=C5=82 Dominiak wrote: > Today I came across a very silly issue: you cannot do `uint64_t > operator""_foo(uint64_t)`, because `uint64_t` is a typedef for `unsigned > long`, not `unsigned long long` on both Clang and GCC on Linux (despite t= he > fact that `sizeof(unsigned long) =3D=3D sizeof(unsigned long long)`). You= have > to type the long type name, just because the typedef isn't for the exact > type required by the standard. I hope we all agree this is a silly > situation. > > So, I'd like to propose allowing `operator""`s to take arguments of any > integral types. > It's not supposed to take any integral types. The operator takes an unsigned type because any negation happens outside it. Since we already have such a restriction for the type a literal operator accepts, it's not a far stretch to have a further limitation. I wouldn't mind it accepting any unsigned integral type, but I don't see it a big deal that you have to have a certain signature for a literal operator. Not allowing multiple kinds of integral types as literal operator parameters also avoid having to deal with overload resolution for the literal operators, and not allowing narrow types avoids having to deal with narrowing conversions. --=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/. --001a11c2c0eca340bc04e0de1fd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 6 July 2013 23:26, Micha=C5=82 Dominiak <griwes@griwes.info> wrote:
Today I came across a very silly issue: you = cannot do `uint64_t operator""_foo(uint64_t)`, because `uint64_t`= is a typedef for `unsigned long`, not `unsigned long long` on both Clang a= nd GCC on Linux (despite the fact that `sizeof(unsigned long) =3D=3D sizeof= (unsigned long long)`). You have to type the long type name, just because t= he typedef isn't for the exact type required by the standard. I hope we= all agree this is a silly situation.

So, I'd like to propose allowing `operator""`s= to take arguments of any integral types.

=
It's not supposed to take any integral types. The operator takes a= n unsigned type because any negation
happens outside it. Since we already have such a restriction for= the type a literal operator accepts, it's
not a far stretch to have= a further limitation. I wouldn't mind it accepting any unsigned integr= al type,
but I don't see it a big deal that you have to have a certain signature= for a literal operator.

Not allowing multiple kinds of i= ntegral types as literal operator parameters also avoid having
to deal with overload resolution for the literal operators, and not al= lowing narrow types avoids
having to deal with narrowing conversions.

--
 
---
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-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-proposals/<= /a>.
 
 
--001a11c2c0eca340bc04e0de1fd0-- .