Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116232 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 28261 invoked from network); 5 Oct 2021 17:12:41 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Oct 2021 17:12:41 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 3D6751804C9 for ; Tue, 5 Oct 2021 10:57:12 -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=-0.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS 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-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 5 Oct 2021 10:57:08 -0700 (PDT) Received: by mail-ot1-f46.google.com with SMTP id c6-20020a9d2786000000b005471981d559so26871447otb.5 for ; Tue, 05 Oct 2021 10:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VRCcDpjITD+ic7UbGVMVc5YpnHhmh6FkgxqXn8H5PN4=; b=itvcKcZq+TvfZdP3MguCwmaNuLacK0aO857ULNlLf9UpT66Gyox7qx9kPE5HQJb5h8 qs1CMgJVCqjZg7aTRlucAUBniszF2Z05v5SwmSHynQQcRDQwYutETa4F2KfQTcIP+lU/ WrRrNKjOFf5wHN+q/Kgy9COdYQCkJMtQpPO5k2DzW/94MBvv1cecQBHE3+b8Ohfaf0p6 H4YfEh7qX0mf/Du1kaKBY2Bt1sYOzpo8W2LrQEGgu+MQS9422mRufHLBfiEE14AOBG0L RTVuxTk6Z8NUwXm7BbU/VTRrdfBYAt4Fpstmcp9rfwRkkxHOL/nl0LrhfdfT2Ed1FUtY TSxA== 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=VRCcDpjITD+ic7UbGVMVc5YpnHhmh6FkgxqXn8H5PN4=; b=FTZCLxXKjVsV91SdU5BH5QwWZN6dv21dHdjSpi+8uqgFvgWfEeAzEcWdvfwgGQHP1D vZCC2yUAubPF0dGl1MpyewC0n93JfFVlo3kVj03P7ypJertTpydSSSuBRSJtxYe3gT31 wMwBQ31RtqvQDM4sXb37VlG5Q6pivOXXtFrwZP+jN0xlo6VguQbuHzMNnmHki5CZmdPF kjwlipKVVOvvzl3gRgZxAiQkdot0MQa1ugCS8AVWU+Lmz2EkiURWGCar5USXHeB7FK8G NG3FKlp2ICtdBaEKw1mytee9QpJkLJ1bOYay4fMjncNQpRfgjEmjFmRARvXF0SPe0tz6 dRZA== X-Gm-Message-State: AOAM530uOvmP+eTByyb8LUKnHfC2G8hMHlcwkgHeubIBvg3MzWz7yq7R edqrCqQozpvX2dMPLlK3Hi+PdM9p0vGsCWt7ZfbCAioH X-Google-Smtp-Source: ABdhPJwkl6HMXvkAEKo6LnSvlJJVE7x/gNifRU8X3ZkWyLTZ5suwOHLjTamo6YeavvbIiJo2kjW/bDIXaAxkHZx/TDw= X-Received: by 2002:a9d:7588:: with SMTP id s8mr15603845otk.323.1633456628155; Tue, 05 Oct 2021 10:57:08 -0700 (PDT) MIME-Version: 1.0 References: <4638866.snJnjoNyIA@tempete> In-Reply-To: Date: Tue, 5 Oct 2021 18:56:55 +0100 Message-ID: To: Nikita Popov Cc: =?UTF-8?Q?C=C3=B4me_Chilliet?= , PHP internals Content-Type: multipart/alternative; boundary="00000000000013d58805cd9ec23c" Subject: Re: [PHP-DEV] [RFC] Allow null as standalone type From: davidgebler@gmail.com (David Gebler) --00000000000013d58805cd9ec23c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 5, 2021 at 3:45 PM Nikita Popov wrote: > On Tue, Oct 5, 2021 at 4:08 PM C=C3=B4me Chilliet wrot= e: > > > Le lundi 4 octobre 2021, 10:09:12 CEST Nikita Popov a =C3=A9crit : > > > If we make this change, I would however suggest to also support "fals= e" > > as > > > a standalone type. I think this change primarily has benefits from a > > > typesystem completeness perspective rather than a strong practical > need. > > > From that angle, it would be nice if all types that are usable in a > union > > > are also usable as standalone types, rather than shifting the special > > case > > > from null to false. > > > > It feels weird/wrong to slowly add values in the type system like this, > > rather than directly supporting static values as type hints. > > > > Why would function a(): null|false {} be legal but function b(): null|0 > > would not? > > > > This is inconsistent to me. And adding null, then false, then true for > the > > sake of completeness feels like avoiding to treat the static value as > type > > hint subject. > > > > Both null and false are already part of the type system. They're not bein= g > added, neither by the RFC in question, nor by my quoted suggestion. This > discussion is only about relaxing restrictions on standalone types. > I always thought false was part of the type system just to accommodate the legacy of internal functions which can return a (non-boolean) value or false. I mean, I've never written code that's type hinted something|false as a return type, to me a function/method return should either be type hinted bool or not. Even with union types, if I was writing something|bool there might be conceivable occasions it's justified, but I'd at least be asking myself if it could be a design smell in whatever I'm building. I guess I'm saying I've always considered the fact you *can* do this with false more a legacy of necessity than a feature which should be built on. Null is distinctly a type as well as a value so I can see the justification for the RFC; it seems harder to make that argument for false, beyond saying "well in PHP, it just is"...but...is that a good thing? > > So to answer your question: "null|false" would be legal because > "string|false" already is. "null|0" would be illegal because there is no > such thing as a "0" type (in our current type system). > Regards, > Nikita > --00000000000013d58805cd9ec23c--