220 9884 <3B09C97E-7ADE-49ED-8C31-B5B41CD3DDE7@gmail.com> article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Explicitly-defaulted enumeration operators Date: Tue, 18 Mar 2014 10:17:24 +0800 Lines: 132 Approved: news@gmane.org Message-ID: <3B09C97E-7ADE-49ED-8C31-B5B41CD3DDE7@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_25E58547-68A2-418D-BABE-F537E999F11B" X-Trace: ger.gmane.org 1395109050 32087 80.91.229.3 (18 Mar 2014 02:17:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Mar 2014 02:17:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBP6ZT2MQKGQEXI4HJ2Q@isocpp.org Tue Mar 18 03:17:39 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pb0-f71.google.com ([209.85.160.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WPjb0-00033P-5F for gclcip-std-proposals@m.gmane.org; Tue, 18 Mar 2014 03:17:38 +0100 Original-Received: by mail-pb0-f71.google.com with SMTP id up15sf16290986pbc.10 for ; Mon, 17 Mar 2014 19:17:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=gMqmOCNgSggy5JTyJayCSFHlwte5m7mkoDKEhCevjtY=; b=iodoYKAijLbMu3s83EQVuOOsicB5tmxfaR5qIxA0bR9Lg7j16y+FP/6rzNPjjNaiaM LRepD7a3KsRvYgDM9YzC7O4TG2y9Bt/02HyMd2ldZ+gzAjDBZ7gBYsf76V6g9QFnJDAM eEma2WAPAFhxDKe/8K8OaLvcQyGMXPxfCnHJgjxqD+n7nLv9X3YSC2KObQ0e5wqhBXUq F/BM4t6fzUyMOjnYu/2OYutWbQ8G2ZWjj1aZrkKkearK0pyShK+8kwoBPvfWIANpCWOH AW3GZ9fbeL3n8LY+AtN1gBtt4aagVd59NxSKNPIpgvcSOeE7kSGg87fb14UQvrrJbVnY 9TIg== X-Gm-Message-State: ALoCoQlsntRw3Ve9G3v3ciOE40cvnRStU/wRmGvkDu5qyq8B2xamJhMQCCbvNuqloRtSu9m9fLHV X-Received: by 10.66.197.167 with SMTP id iv7mr10748792pac.12.1395109057065; Mon, 17 Mar 2014 19:17:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.25.70 with SMTP id a6ls1445892igg.42.canary; Mon, 17 Mar 2014 19:17:35 -0700 (PDT) X-Received: by 10.68.197.36 with SMTP id ir4mr28982073pbc.46.1395109055706; Mon, 17 Mar 2014 19:17:35 -0700 (PDT) Original-Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [2607:f8b0:400e:c02::236]) by mx.google.com with ESMTPS id iu9si11241124pac.453.2014.03.17.19.17.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 19:17:35 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c02::236 as permitted sender) client-ip=2607:f8b0:400e:c02::236; Original-Received: by mail-pd0-f182.google.com with SMTP id y10so6440171pdj.27 for ; Mon, 17 Mar 2014 19:17:35 -0700 (PDT) X-Received: by 10.66.228.37 with SMTP id sf5mr29300527pac.19.1395109055442; Mon, 17 Mar 2014 19:17:35 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.49]) by mx.google.com with ESMTPSA id sx8sm79849920pab.5.2014.03.17.19.17.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 19:17:34 -0700 (PDT) X-Mailer: Apple Mail (2.1874) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c02::236 as permitted sender) smtp.mail=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:9884 Archived-At: --Apple-Mail=_25E58547-68A2-418D-BABE-F537E999F11B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 A generic unary operator+ for a scoped enumeration looks something like thi= s: template< typename e > constexpr auto operator + ( e v ) noexcept (( typename std::enable_if< enum_traits< e >::enum_trait_numeric::value >::type (), true )) { return + static_cast< typename std::underlying_type< e >::type >( v )= ; } This is a fair amount of boilerplate. Consistency with integral promotion v= iz the built-in operator, and noexcept, are easy to miss.=20 It would promote ease of use and correctness to allow explicitly-defaulted = definitions of the operators E operator @ ( E, E ) // @ may be +, -, *, /, %, |, &, ^ E & operator @=3D ( E &, E ) // @ may be +, -, *, /, %, |, &, ^ E operator @ ( E, int ) // @ may be <<, >> E & operator @=3D ( E &, int ) // @ may be <<, >> E operator @ ( E ) // @ may be -, ~ T operator + ( E ) bool operator ! ( E ) where E is an enumeration type and T is the result of integral promotions o= n its underlying type. The implicit definition should cast the operands to = the underlying type, perform the operation, and cast back to the operand ty= pe if necessary. These operators cover enumerations behaving as bitsets or integers, which s= eem to be on firm ground as acceptable use cases. There is no provision for= adding a (non-enumerator) numeric displacement value to an enumerator that= is not number-like. operator+, which I used as an example, may be idiomatically used as the "pr= omotion operator" and I've suggested different type-semantics from the othe= r unary arithmetic operators, which could be contentious. Has there already been a proposal along these lines? An alternative approach would be to add generic operator overloads and trai= ts to the library (like the above utility), but this wouldn't work for the = same reason std::relops doesn't: there's no way to ADL-associate a user-def= ined type with a function in std::. --=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/. --Apple-Mail=_25E58547-68A2-418D-BABE-F537E999F11B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 A generic unary <= font face=3D"Courier">operator+ for a scoped enumeration looks somet= hing like this:

template<= typename e >
constexpr auto ope= rator + ( e v )
    noexc= ept (( typename std::enable_if<
=                      = ;    enum_traits< e >::enum_trait_numeric::value
            &nb= sp;   >::type (), true ))
&= nbsp;   { return + static_cast< typename std::underlying_type< e= >::type >( v ); }

This is a fa= ir amount of boilerplate. Consistency with integral promotion viz the built= -in operator, and noexcept, are easy to miss.=  

It would promote ease of use and correctnes= s to allow explicitly-defaulted definitions of the operators

=
    E operator @ ( E, E ) // @ = may be +, -, *, /, %, |, &, ^
    E & operator @=3D ( E &, E ) // @ may be +, -, *,= /, %, |, &, ^
 = ;   E operator @ ( E, int ) // @ may be <<, >>
    E & operator @=3D= ( E &, int ) // @ may be <<, >>
    E operator @ ( E ) //= @ may be -, ~
    T operator + ( E )
    bool operator ! ( E = )

<= /div>
where E is an enumeration type and T is the result of integral pr= omotions on its underlying type. The implicit definition should cast the op= erands to the underlying type, perform the operation, and cast back to the = operand type if necessary.

These operators cover e= numerations behaving as bitsets or integers, which seem to be on firm groun= d as acceptable use cases. There is no provision for adding a (non-enumerat= or) numeric displacement value to an enumerator that is not number-like.

operator+, which I use= d as an example, may be idiomatically used as the “promotion operator= ” and I’ve suggested different type-semantics from the other un= ary arithmetic operators, which could be contentious.

<= div>Has there already been a proposal along these lines?

An alternative approach would be to add generic operator overloads a= nd traits to the library (like the above utility), but this wouldn’t = work for the same reason std::relops doesn&rs= quo;t: there’s no way to ADL-associate a user-defined type with a fun= ction in std::.

--

---
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>.
--Apple-Mail=_25E58547-68A2-418D-BABE-F537E999F11B-- .