Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112838 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62228 invoked from network); 10 Jan 2021 21:50:53 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 10 Jan 2021 21:50:53 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0E9141804AA for ; Sun, 10 Jan 2021 13:28:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, RDNS_NONE,SPF_HELO_PASS,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from out2-smtp.messagingengine.com (unknown [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 10 Jan 2021 13:28:25 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 176515C00AC for ; Sun, 10 Jan 2021 16:28:15 -0500 (EST) Received: from imap26 ([10.202.2.76]) by compute4.internal (MEProxy); Sun, 10 Jan 2021 16:28:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=bZvPiXTmYEDy9PnL1mlhXqc/WW3R8 DGL5D0khQKh7zs=; b=LVmYMKcfOaZyGugsssIt+/uyKQyCLz/msYjFxHFTxQCGo BSAmvPR5IYWFh423e4ykdrXYZpPZ7yZ8+Ra5qQ+0I8xabYYKpWxzHkfpxSQFMkZK kWaoOfI1ANW4+a8AAUNfi7fm4ar7caetHCb4x2hJbomi3NcBD2AEInHc2Cu6VvyY hTqq2xo6HRV3v3mD2cNbENTA9l8x11XTWBpoGitinToZSAw5lcSbUkMpD6zsls6Y qFEl2VOCuvEsNvn6U30TyD1QBAx1tbLUrjGH79d2OhzKhSkMPLxAyvuSqSYLnKlL R2Ke1x9bQfssRdpSo3+BTc+5TQHjaU/73eN3MAiEg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegledgudehtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgrrhhr hicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtghomh eqnecuggftrfgrthhtvghrnhepfeetjeekleegveetvdekudeitddtleejgeeutdfhfeek teffgeeiueetjeeiiefgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheplhgrrhhrhiesghgrrhhfihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B9F1F14200A2; Sun, 10 Jan 2021 16:28:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-ID: Date: Sun, 10 Jan 2021 15:27:12 -0600 To: "php internals" Content-Type: text/plain Subject: "TryX" idom for Enumerations From: larry@garfieldtech.com ("Larry Garfield") This is a little tangent from the Enums RFC, but I want to flag it because it it's the sort of in-passing decision that could have far-reaching implications, so shouldn't be done implicitly. At the moment, the Enum RFC for scalar enums includes two methods: public function has(string $name): bool public function from(string $name): self throws ValueError Nikita raised the point that has() seems kinda pointless as it would only ever be used to wrap a possibly-unsafe from() call. (In most other cases, calling cases() would be more useful or at least equally useful.) One of the proposed alternatives was the following: public function from(string $name): self throws ValueError public function tryFrom(string $name): ?self The "a method that begins with try is nullable, so watch out" idiom is present in C# and Rust, but to my knowledge has never existed in PHP. That doesn't make it bad; it actually combines quite well with the null coalesce operator to allow for default values, making a valueOrDefault() method unnecessary. $order = SortOrder::tryFrom($input) ?? SortOrder::Asc; I'm not opposed to following that pattern here; it would allow both a "hard fail" and "soft fail" variant of the operation. However, as noted that idiom has never appeared in PHP before that I'm aware. If we adopt it here, that means it will either start to spread and become a more common PHP idiom over time, OR it won't spread and Enums will have this weird one-off naming convention for a nullable method. The former would, of course, be considerably preferable to the latter. So, explicit decision time: Are we OK with introducing that idiom, and then following it consistently in the future in similar situations? (viz, tryX() means nullable, and no-try means not nullable.) I'm good with it if the consensus is good with it, but I want to see what the consensus is first. -- Larry Garfield larry@garfieldtech.com