Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116227 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 7845 invoked from network); 5 Oct 2021 14:00:47 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 5 Oct 2021 14:00:47 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B7F461804DB for ; Tue, 5 Oct 2021 07:45:16 -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_H2,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-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (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 07:45:16 -0700 (PDT) Received: by mail-ed1-f43.google.com with SMTP id p11so26536935edy.10 for ; Tue, 05 Oct 2021 07:45:16 -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=K9JrGKZA42uf3ya9VGEg9foRHKLNacoi1t/oQ/rbgxU=; b=k4bWhWXLjAaoGpNXqw5mztaJq4J4cjh7lJMguwGuhGejCUVC4T5VoFS3c70OmNQYE3 6+ed9OdMJHg5Jfd+SXJTf2ivyEkEbJ/uXp2n6U+P9zDi8JgUq3m2v5BNb/ReyxqdslQ6 tbSIs/ULiZszelaoGwfe7aWIv18XL3p93Exw7XzctKLrsVt68f/ZT+I5nI4HclEjUl7J pep0nXcNReaLVvio9mxYJN6bwu5NGIKImYgyVKikfLHYrbBnoFOtwI6BQCBsKj/uL3ca JIU6XSu/qomknDfDGdbtb748k9Ala3nWV768IWi/THsDNXhNN6R7rpS3ovzDBKKmzI0E JGmw== 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=K9JrGKZA42uf3ya9VGEg9foRHKLNacoi1t/oQ/rbgxU=; b=Pj6/ezQtCLZRLVs3GR6wJeJy9NsJRvw/5IUREY2cMvu0tj5A4WMFt3ImfLvUUvYqiz v3NWjSHpYO4nd+++a+LXWLHgS8fh2vRAvd9csSkbJ3+5L/YqLSgB8/rTrj2u9zFt6oZK 8mSGk3i4NUkM/HwoRjeJZvTTH4Roba0xw5VKC6KiT9Chw2iJiyI1pP9uL+xW0BVSv08t wFcFWXI+OSw4Rlq4qpOmA9glotfyqY4bBjfUHAKH7lKulwCM0ObWAmOAS7EssDzWXUh3 pDZM4vAac+PiKZXKOlvrh7gyPMXtI1C9x7FfGwJde8atbXqi/WF8GmfUVbu9iSrrghVY HUyA== X-Gm-Message-State: AOAM531M6u8lo9VNOVqhjozlWs0EolKSENo2RoYeAkGbPdIBKAB3T1ex VTxiqgjNK0SX8VTH/Q2ssTiHLYTO5f8zo0CPufqEz+WH X-Google-Smtp-Source: ABdhPJzIrZlrJcMAKvf8QM4/qh5rbqZhDNwh6+WfPgNcCVORU8WsVL2sSNA+BCYfabQlODjNG23AiTW38LUD5Qkn4pc= X-Received: by 2002:a17:906:2b53:: with SMTP id b19mr20432852ejg.339.1633444967939; Tue, 05 Oct 2021 07:42:47 -0700 (PDT) MIME-Version: 1.0 References: <4638866.snJnjoNyIA@tempete> In-Reply-To: <4638866.snJnjoNyIA@tempete> Date: Tue, 5 Oct 2021 16:42:31 +0200 Message-ID: To: =?UTF-8?Q?C=C3=B4me_Chilliet?= Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000001302c105cd9c0b7f" Subject: Re: [PHP-DEV] [RFC] Allow null as standalone type From: nikita.ppv@gmail.com (Nikita Popov) --0000000000001302c105cd9c0b7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 5, 2021 at 4:08 PM C=C3=B4me Chilliet wrote: > 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 "false" > 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 uni= on > > 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 th= e > sake of completeness feels like avoiding to treat the static value as typ= e > hint subject. > Both null and false are already part of the type system. They're not being added, neither by the RFC in question, nor by my quoted suggestion. This discussion is only about relaxing restrictions on standalone types. 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 --0000000000001302c105cd9c0b7f--