220 40224 <7a52afd9-2e2a-4a9c-a7e5-0302fc6cfca2@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: sebastian.bjurman1@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Make (strongly typed) enums castable to char const * const Date: Wed, 26 Sep 2018 03:41:28 -0700 (PDT) Lines: 184 Approved: news@gmane.org Message-ID: <7a52afd9-2e2a-4a9c-a7e5-0302fc6cfca2@isocpp.org> References: <1472132849.17129.9.camel@bsdforen.de> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2695_932849456.1537958488632" X-Trace: blaine.gmane.org 1537958364 12402 195.159.176.226 (26 Sep 2018 10:39:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2018 10:39:24 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBD6275VQ6ALBBWOEVXOQKGQE62EBK4A@isocpp.org Wed Sep 26 12:39:20 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f200.google.com ([209.85.219.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g57E0-00039i-4y for gclcip-std-proposals@m.gmane.org; Wed, 26 Sep 2018 12:39:20 +0200 Original-Received: by mail-yb1-f200.google.com with SMTP id e195-v6sf9713797yba.0 for ; Wed, 26 Sep 2018 03:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; 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; bh=4WSQqeAkUhy2kzkUPgEfeWC61YcxfZ/5LtS6fIEXjjo=; b=PQzLd84vDwcku0KUxnviThsp+CmN+Ntc0VHSD1sh858z0Xqz6WnbG6wqHWr+Xs/TuB k+rbB9dvc8b18WDKmlxAcvB21LogYCj6kW3xYyf6SoPyeFw/urPwZvKNYufU+KUIGUR9 BNQrzmD/k3VYOlCfU3y1l/OJdVY4Td9zZkFw8gtwpxaGpMfSrklgZkEnUa0QgU5G6lSY uoMEwZPNhWLqhuSiQ9v3sH6eBLMQfPYqCO3kbuCCbiQsFOk4VNbeZMqS138pYr6pQov1 x+HjKaZIV3IlZNl+aCC3jEEWJnrx3MnTF4A+MMzBxl3UnMSKQpton0aL91N6nLTE6xbv n8sA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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; bh=4WSQqeAkUhy2kzkUPgEfeWC61YcxfZ/5LtS6fIEXjjo=; b=o0Ldv8PsIGOF0q9bEeV4GWLhfl7exIuffv2KxUnIRu+PEuObAdLtah8QV9S7P2VGsc qZBU3vw9WUe2mCBL0IVxq+gpMU0FQeP8M4UZr3kJrrru29mureCiFsG4GltjoKVKKFiw wVejRVYGUy4O8r29xcYONaxIAsezW0mOvskAxZ87YsTCiLk3Off/+NBY5bQuSpUyXdCR TwYWMb5Gy/oSBw7/VLWBCt9z98V1j0/kp8ntHGA/z/EiQeIO5XWU1otgRZOC9X6Znhrr JiaAyW+lw68cSsgYTOP1r2m5UZ6EszsBZmR41VXtUmzA4ZFdwbYbIO85nPRKOZfy8++f bQUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=4WSQqeAkUhy2kzkUPgEfeWC61YcxfZ/5LtS6fIEXjjo=; b=XPCFf81AHhZDHURYNH+4rxkmrQUNRGfTcoans/mgeS1wYk81g8jXXzFoDgNpeIMyno m0NNYa/CEsg6KvTbDLmtJeqdWYFNV26UCGCXrLzeyocjnYXx5nK99qCLNerEJff0VFEG RjEEb6Fg1oBMk/7jreELAr4mR9WIMppneAcpeRo03iOzFhfPKVraU4U6zCi65dP9g5Pv 4Pe1uwE8h8G7yWQqzJkrLdNjPRO5Vonr48K00zVpYc3NZD4R3/B+lyoKaCxrG/ReOsDy qWpr6+JM45ZkUzx10f/T3wwTGJllrzVpZ+9rJI/2NNK6W8zWyESGNHCSdsJpt7kOphov ciJg== X-Gm-Message-State: ABuFfohlV7/kQudmaEL4bujvDowx/vZvyrul09u8xeSdbQOPIX2dwskZ PcXq/LjGpQaVcHvlJMH04wJzBw== X-Google-Smtp-Source: ACcGV60CIBboJkhL31fTFIi4i8msRYpIvi5z+pl19g1/uUhgh7rV2l8zhqehwWsBV1sVDlFJgygcnA== X-Received: by 2002:a81:dc04:: with SMTP id h4-v6mr287217ywj.12.1537958490613; Wed, 26 Sep 2018 03:41:30 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:4f0c:: with SMTP id d12-v6ls184863ywb.36.gmail; Wed, 26 Sep 2018 03:41:29 -0700 (PDT) X-Received: by 2002:a0d:d9c4:: with SMTP id b187-v6mr59069ywe.0.1537958489462; Wed, 26 Sep 2018 03:41:29 -0700 (PDT) In-Reply-To: <1472132849.17129.9.camel@bsdforen.de> X-Original-Sender: sebastian.bjurman1@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:40224 Archived-At: ------=_Part_2695_932849456.1537958488632 Content-Type: multipart/alternative; boundary="----=_Part_2696_1282017642.1537958488632" ------=_Part_2696_1282017642.1537958488632 Content-Type: text/plain; charset="UTF-8" While the reflection proposal is very nice and generic, has anyone so far brought up the idea of building something like this on top of the "= default" style syntax, e.g. "constexpr std::string to_string(MyEnum) = default;" or a similar style for operator<<, or perhaps even building it upon using attributes "[[printable]]", or even automatically and silently generating enum-to-string functions (as constexpr to_string(MyEnum)" implicitly if ever used in the code, similar to existing default c-tor generation (or always for multiple compile units, with elimination by linker stage optimization if unused)? Out of these options, I prefer the last one - automatic generation if used. I know that the C++ standards committee policy is usually to prefer generic solutions over specific solutions, but couldn't building "enum to string" on top of reflection be considered an exaggeration of that rule? It seems to me that the generic approaches listed above may have to build on recursive templates or otherwise potentially slow-to-compile operations, so certainly one argument in favor of more specific language support would be potentially faster compile times for generating what is really a very common pattern in most large C++ code bases. Moreover, I'm not usre there's any good reason to force the user to implement enum-to-string functionality manually. It's certainly less convenient for the user to do it manually (which the reflection based approach would require), and it's also certainly possible for a compiler to determine whether a call to enum-to-string is ever made in the code base and in that way know whether such a method would need to be generated. If for some reason certain users would desire compiler warnings for unnecessarily generated to_string methods or a way to more easily detect whether a method is implicitly generated, perhaps automatic generation could be expressed by an attribute: [[printable]]. In order to be more generic than only applying to enums, this idea could be supported also for structs/classes, where the default option could be to print all members in a similar to how they are printed in GDB, i.e. delimited by suitable delimiters and with some form of hierarchy in cases where a member is of struct type. Den torsdag 25 augusti 2016 kl. 15:47:34 UTC+2 skrev Kamikaze Dominic Fandrey: > > I searched this list for similar suggestions, but of course I may > have overlooked something. > > I frequently use the following pattern: > > enum class FooBar { KEKS, DOSE }; > char const * const FooBarStr[]{"KEKS", "DOSE"}; > > I use the strings to in error messages, verbose output, etc. > > FooBarStr[static_cast(FooBar::KEKS)] // "KEKS" > > This has some disadvantages, e.g. enums with explicitly stated values > may have gaps, negative values and may be defined out of order. > Also, changing the enum also means changing the strings manually. > > What I'd like to see: > > static_cast(FooBar::KEKS) // "KEKS" > > I think this would be simple to add to an existing compiler and it's > very unlikely to clash with existing code, because you have to jump > through some hoops to cast a strongly typed enum to a pointer type. > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > > > -- 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 email 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/7a52afd9-2e2a-4a9c-a7e5-0302fc6cfca2%40isocpp.org. ------=_Part_2696_1282017642.1537958488632 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While the reflection proposal is very nice and generic, ha= s anyone so far brought up the idea of building something like this on top = of the "=3D default" style syntax, e.g. "constexpr std::stri= ng to_string(MyEnum) =3D default;" or a similar style for operator<= <, or perhaps even building it upon using attributes "[[printable]]= ", or even automatically and silently generating enum-to-string functi= ons (as constexpr to_string(MyEnum)" implicitly if ever used in the co= de, similar to existing default c-tor generation (or always for multiple co= mpile units, with elimination by linker stage optimization if unused)? Out = of these options, I prefer the last one - automatic generation if used.
I know that the C++ standards committee policy is usually t= o prefer generic solutions over specific solutions, but couldn't buildi= ng "enum to=C2=A0 string" on top of reflection be considered an e= xaggeration of that rule? It seems to me that the generic approaches listed= above may have to build on recursive templates or otherwise potentially sl= ow-to-compile operations, so certainly one argument in favor of more specif= ic language support would be potentially faster compile times for generatin= g what is really a very common pattern in most large C++ code bases.
<= div>

Moreover, I'm not usre there's any good rea= son to force the user to implement enum-to-string functionality manually. I= t's certainly less convenient for the user to do it manually (which the= reflection based approach would require), and it's also certainly poss= ible for a compiler to determine whether a call to enum-to-string is ever m= ade in the code base and in that way know whether such a method would need = to be generated. If for some reason certain users would desire compiler war= nings for unnecessarily generated to_string methods or a way to more easily= detect whether a method is implicitly generated, perhaps automatic generat= ion could be expressed by an attribute: [[printable]].

=
In order to be more generic than only applying to enums, this idea cou= ld be supported also for structs/classes, where the default option could be= to print all members in a similar to how they are printed in GDB, i.e. del= imited by suitable delimiters and with some form of hierarchy in cases wher= e a member is of struct type.


Den torsdag 25 augusti 2016= kl. 15:47:34 UTC+2 skrev Kamikaze Dominic Fandrey:
I searched this list for similar suggestions, but of c= ourse I may
have overlooked something.

I frequently use the following pattern:

=C2=A0 =C2=A0 enum class FooBar { KEKS, DOSE };
=C2=A0 =C2=A0 char const * const FooBarStr[]{"KEKS", "DO= SE"};

I use the strings to in error messages, verbose output, etc.

=C2=A0 =C2=A0 FooBarStr[static_cast<int>(FooBar::KEKS)] // &= quot;KEKS"

This has some disadvantages, e.g. enums with explicitly stated values
may have gaps, negative values and may be defined out of order.
Also, changing the enum also means changing the strings manually.

What I'd like to see:

=C2=A0 =C2=A0 static_cast<char const *>(FooBar::KEKS) // "KE= KS"

I think this would be simple to add to an existing compiler and it'= s
very unlikely to clash with existing code, because you have to jump
through some hoops to cast a strongly typed enum to a pointer type.

--=20
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


--
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/7a52afd9-2e2a-4a9c-a7e5-0302fc6cfca2= %40isocpp.org.
------=_Part_2696_1282017642.1537958488632-- ------=_Part_2695_932849456.1537958488632-- .