Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118045 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 13534 invoked from network); 22 Jun 2022 10:44:24 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Jun 2022 10:44:24 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 54072180538 for ; Wed, 22 Jun 2022 05:33:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 22 Jun 2022 05:33:53 -0700 (PDT) Received: by mail-wm1-f50.google.com with SMTP id j5-20020a05600c1c0500b0039c5dbbfa48so10980290wms.5 for ; Wed, 22 Jun 2022 05:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beberlei-de.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GhmUjtA7S/GqvmBgp741PY+sv/L5VRImaO/jj0Sg0qQ=; b=OliD0f/D9lIwAMFvxrKMlZQ7mMKs0puS7dO2lOz2DCXfix2R0UNw6cDnShavkES5gs c0GeQPQYBeBLY65EgR6JWW064vwTO3W2ED0qxzzgzuApzFnlUSTQGj7tUd0LMlo2xfUP swESxqRyAX9ahSCmjjRsrm94qZBdGyLVSc4W3QH2mCikP93JNRaYbWJjuGPPZvgMAaWB IBbSwMeryilyviugyNeeLfvt/zm6XrQbWcSu0ey81YZZnM6h1+vIjnEj+0w+GXbPn3JW abEI7RdUNdmavhNEFQDhvd3JqredSFRzXjmVZJacpe/GduDZHLt9JCE0K99ju75RetW8 2vzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GhmUjtA7S/GqvmBgp741PY+sv/L5VRImaO/jj0Sg0qQ=; b=hw8b0uJQCYjfz1yj1XJV9l/VBe1zrKqJcG5FdqaCmn9APZSG6s+bKl7UxP2C0Lw0rL ALxoxrKXY75MVYRrQE3DY+BrTBq63jTeYtkorVxUa0huH+tOjDuD4qA4xQmdCFT+SCn/ 0oGm7/gvdBCva6XTZGK5/oBzIXxLYUw5hLOuTpmvLS0nl4qpCTYzzyQHTdgUy6NWjQJF WK1n3z737VWM3o+JpB/ikQ2BBFh7STd/hobwCO52M0me2PZoJdYDH1bkz7ekOoBs73/q Ztq4fVCfkGspEK0Lxkgjr37UOJKTWwDERdGEgtzrWjH0vrpH8bvIFdc3+qPLw6ahGGW6 6IuQ== X-Gm-Message-State: AJIora83CDOjXFan8YNVPfwvmyK9SSMAKyP6CMX77BbGbgV5H624Iyvf YoJiWnbv/gCpbMw4qqdUCIPw3UK1sXB4OzO9LCij8A== X-Google-Smtp-Source: AGRyM1ue46/s2wULO/ahzmapFkErzirh3W6tses0IgFF3XfbnHKYOf3Km/M8ZyJZHbtYxxxWUw5e2iyGA1NpoXwgRpI= X-Received: by 2002:a05:600c:2e14:b0:39c:58c4:c6ed with SMTP id o20-20020a05600c2e1400b0039c58c4c6edmr3685997wmf.156.1655901232547; Wed, 22 Jun 2022 05:33:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 22 Jun 2022 14:33:41 +0200 Message-ID: To: Nicolas Grekas Cc: PHP Internals List Content-Type: multipart/alternative; boundary="000000000000bfe1c805e2088c11" Subject: Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for string backed enums From: kontakt@beberlei.de (Benjamin Eberlei) --000000000000bfe1c805e2088c11 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 22, 2022 at 12:47 AM Nicolas Grekas < nicolas.grekas+php@gmail.com> wrote: > Hi everyone! > > I'd like to open a discussion on this RFC, to auto-implement Stringable for > string-backed enums: > https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums > > I'm looking forward to your feedback, Hi Nicolas, Hi Ilija, I would prefer if this was an explicit opt-in to have a __toString on a backed enum. Maybe a special trait for enums that has the implementation, so that a custom __toString cannot be implemented or a new syntax "enum Foo : Stringable". My concern is that auto implementing __toString, will lead to decreasing type safety of enums in weak typing mode, since they get auto-casted to string when passed to a function accepting strings. This effectively adds more type juggling cases. The example in the RFC about attributes accepting strings or Enums can be solved by union types on the side of the library developers, it doesn't need to be magically implemented by the engine. I don't consider "use strict mode" a good argument to avoid this problem, because that has other downsides such as overcasting. > > Cheers, > Nicolas > --000000000000bfe1c805e2088c11--