220 9889 <24e85eaf-e67b-4a0b-acee-47d996d6f6ee@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matheus Izvekov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Explicitly-defaulted enumeration operators Date: Mon, 17 Mar 2014 21:42:13 -0700 (PDT) Lines: 95 Approved: news@gmane.org Message-ID: <24e85eaf-e67b-4a0b-acee-47d996d6f6ee@isocpp.org> References: <3B09C97E-7ADE-49ED-8C31-B5B41CD3DDE7@gmail.com> <781009e3-cd3c-4cb8-b034-b51a7c97c750@isocpp.org> <10450602-fee9-48c4-9fa2-d000e434f5fb@isocpp.org> <6F532E62-C10A-404A-8F0D-662B7EA3D202@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5788_26326251.1395117733424" X-Trace: ger.gmane.org 1395117727 13302 80.91.229.3 (18 Mar 2014 04:42:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Mar 2014 04:42:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCOKZ27XTMNRBJU5T6MQKGQE356SCJY@isocpp.org Tue Mar 18 05:42:16 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WPlqx-0003bn-Sy for gclcip-std-proposals@m.gmane.org; Tue, 18 Mar 2014 05:42:16 +0100 Original-Received: by mail-pd0-f199.google.com with SMTP id x10sf15664757pdj.10 for ; Mon, 17 Mar 2014 21:42:14 -0700 (PDT) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=VAu2WL3DvUxsxB2eYZYlBC9IKXmjX9Vsz7UTUbavuEo=; b=GoaLVJi94hf/M73FP68ccqf7EWGcEf3+aInIdGCHXIwU9WcciwbRIiva07n6Rit65+ OCpiBHMFxvyor9ETkN51hEknA78JxWQf3d4kOB1UtQeO+NdsUx+FFMo9Vab3twTFLzEG 9be4xeX03LLq68ucxh+vDx+IfZzW/nD5GXVVawjU3ckTFNB8yiYqDBMX+LijyuTKlMpY o96NXvVCE6BWCvxghwl9iqnGUz8mjXz9O1i8yshKiKJUmgY7zqtI34+EIzD88dJhDI1N t2sawUcA69dCHZerSlqha14rFiNh9fAvLgPeYemrgecGbsX9/9POSXHp/IHY27Q/SlHW zZEw== 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=VAu2WL3DvUxsxB2eYZYlBC9IKXmjX9Vsz7UTUbavuEo=; b=NrIbIXeu+u3wLsnnBQbWaHshu/7EGdWKvtmy930irL/8BqoRz1FXw8yjoIeIveWoB4 vIeaprUh6pnwZLuGOmAygTkDrMgaQV8Vu8xMADeuI1Pk6BTVC2ce5aHY1xg2Z3OEbi2o qzZ6a4bL7y0WQqeh5CMotFJ4o9EYm3+oZ2D+hsDYjn+zzkntks6/iKBt6fZG47zMY2TV cINDSie7dAyD7AgqgG95RyF1Dgp3jX/bOHxJziyzpyLg3IRjhrjxX1oq0InM9h/ihXeP 9y+TnKV5ixXoj3QkzKt8tzoFw4U6TbkMW+Tk+mwOMzWqU4VDxAkUeor3bAFZvxsVHjR2 SRlA== X-Gm-Message-State: ALoCoQmrJ7MQWDrdyFFot9bwGFTZ2PIUEx/IWOlDOyrGdsgnzZuIYDVF+ZMHKsEp5aDt8hoc7COy X-Received: by 10.66.144.228 with SMTP id sp4mr10817476pab.5.1395117734789; Mon, 17 Mar 2014 21:42:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.85 with SMTP id a79ls1898074qge.72.gmail; Mon, 17 Mar 2014 21:42:14 -0700 (PDT) X-Received: by 10.140.47.109 with SMTP id l100mr11999qga.12.1395117734067; Mon, 17 Mar 2014 21:42:14 -0700 (PDT) In-Reply-To: <6F532E62-C10A-404A-8F0D-662B7EA3D202@gmail.com> X-Original-Sender: mizvekov@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:9889 Archived-At: ------=_Part_5788_26326251.1395117733424 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, March 18, 2014 1:29:46 AM UTC-3, David Krauss wrote: > > > Oh, now I see. It=E2=80=99s a bit of a radical approach. > > The problem is that for =E2=80=9Ccustom scalar=E2=80=9D types we sometime= s want=20 > intrinsically named values (enumerators) for things like bitsets, but oth= er=20 > times we want floating-point underlying type, which is incompatible with= =20 > named values or often any specific values at all. > > Perhaps now with opaque enum declarations, the use cases can be reconcile= d=20 > by allowing floating-point enumerations with the caveat that no enumerato= rs=20 > are allowed. Or perhaps the lack of implicit operators (and comparability= =20 > to the underlying FP type) already provides sufficient safety and the=20 > language is ready for floating-point enumerations. > > Anyway, my instinct is that building on the existing enumeration framewor= k=20 > would be simpler than starting with typedefs. I should contact Walter,=20 > thanks again. > > Well, he doesn't say explicitly, but it seems Walter's approach would be=20 applicable to enum types just as well, or if not, could be easily extended= =20 to cover that. But I agree that enum's are currently too limited, being able to use any=20 literal type as underlying type of an enum would be uber cool :-) --=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_5788_26326251.1395117733424 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, March 18, 2014 1:29:46 AM UTC-3, David Krauss = wrote:

Oh, now I see. It=E2=80=99s a bit of a= radical approach.

The problem is that for =E2=80= =9Ccustom scalar=E2=80=9D types we sometimes want intrinsically named value= s (enumerators) for things like bitsets, but other times we want floating-p= oint underlying type, which is incompatible with named values or often any = specific values at all.

Perhaps now with opaque en= um declarations, the use cases can be reconciled by allowing floating-point= enumerations with the caveat that no enumerators are allowed. Or perhaps t= he lack of implicit operators (and comparability to the underlying FP type)= already provides sufficient safety and the language is ready for floating-= point enumerations.

Anyway, my instinct is that buildin= g on the existing enumeration framework would be simpler than starting with= typedefs. I should contact Walter, thanks again.


Well, he doesn't say explicitly, but it seems Walter= 's approach would be applicable to enum types just as well, or if not, coul= d be easily extended to cover that.

But I agree that enum's are curr= ently too limited, being able to use any literal type as underlying type of= an enum would be uber cool :-)

--

---
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_5788_26326251.1395117733424-- .