Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116237 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 22861 invoked from network); 7 Oct 2021 01:08:11 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Oct 2021 01:08:11 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BEA621804DB for ; Wed, 6 Oct 2021 18:53:00 -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=-2.1 required=5.0 tests=BAYES_00,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-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (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 ; Wed, 6 Oct 2021 18:53:00 -0700 (PDT) Received: by mail-ed1-f54.google.com with SMTP id p13so17255368edw.0 for ; Wed, 06 Oct 2021 18:53:00 -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=gJBB1rIDEWvb9eX6FeC8WY+22k/9yAQCE2r+2oGrAJo=; b=SKlSZs4T0pvsZ/cwRlMLPSlhkqX8ZIh9taWLaQiu7VNJMTqWxQ6qXGhjefpfyEt8AL obdb3ROQB3NpE3ZEyNWQhz50sair01uJzr2yz2eR1gUlVlhb3OeObIA0DFrB7IbrWzsm 8SST+UcqNjIVUGY9y/oO8r6Gw9JLfPywiWltPlpX87RH2wgaRZv99uj9h6Bv9UByDV64 /cjo8Ula0B8avjMxcvnQrIoquXIXq5JAFpGAVnRzGFkzMIlEI2vYVC7CFHsAgXsHNerP mr4XTSBoV3sEkbAV6QTtzZ9Xb0A5CF5V4aQEC8KdK1pDdBlhIsp5pfYrgK7mi8GrKXec gWyg== 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=gJBB1rIDEWvb9eX6FeC8WY+22k/9yAQCE2r+2oGrAJo=; b=rctfab8jKYQgr0YU1vAKdBvr6yVudwfkc8vjTZ13NI779bNk2K1oa6id5Q8qiiu55I IyIZ8wD+8VdGHbadIFwzyLdL08WVNfzynXHOWFE2Er/icQu7nasDIDHybrzS64Zqd0mw XDtDWDln2mFOTomD6URZoTg0vrDwcLBXnUvvAjdALNFDcOp1d51emx8sv7Nfz1kKNTzA vn9wRrZkezRQbdK4Q75kkfvsYw8pe+JRCQRUoNMfW8Zcu4JwtO+FBWJf3CXQx31uGiyV xNzYLVYPqfwbG1gtMkpeTdM9VFDa/C4KBYo0AtOqKsYZeAvUW0CBJgWXzYjnUBW4OdEl VTsg== X-Gm-Message-State: AOAM533UTdlLa1zQAKkO/XV3vmO7fd/HnglKlNXZOEqNMZXbGSrHuvct CDmyldmInHAjz1xZ43OVe37867K2EvClPrJkXLCurmwWtQDbVQ== X-Google-Smtp-Source: ABdhPJyHzaQhead3j19h3+KZ5eD9+67pkOopRBtk63PDmg/do4gUye9nxiHJv21j+WeBu37fdpSHMeZlj/k7g7Mgi2M= X-Received: by 2002:a17:906:e82:: with SMTP id p2mr2154955ejf.50.1633571578890; Wed, 06 Oct 2021 18:52:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 7 Oct 2021 04:52:42 +0300 Message-ID: To: "G. P. B." Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000accde305cdb985db" Subject: Re: [PHP-DEV] [RFC] Allow null as standalone type From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=) --000000000000accde305cdb985db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > On Tue, 5 Oct 2021 at 23:58, Alexandru P=C4=83tr=C4=83nescu > wrote: > > > But there is one more small elephant in the RFC that I believe should b= e > > discussed. > > null|false type will not be a nullable named type but it will be an uni= on > > between two named types. > > > > It's not totally unexpected. All types that are combined with false are= a > > union type so far. > > > > But also, related to null, it will be the first case that will be > > different. > > So far, all types that are combined with null are not necessarily union > > but their other type that has an allowsNull() that returns true. > > > > One could argue that we can also have it as a ReflectionNamedType with > > getName() =3D 'false' and allowsNull() =3D true. > > > > I feel that the preferred solution will push more towards the general > > desire to represent the nullable types notations more and more like an > > union. > > I can see how what was initially proposed in > > https://wiki.php.net/rfc/nullable_intersection_types for (X&Y)|null > > might end up being UnionType(IntersectionType(NamedType(X), > NamedType(Y)), > > NamedType(null)) > > instead of the originally proposed IntersectionType(NamedType(X), > > NamedType(Y) with allowsNull() =3D true. > > > > I mean, that's not necessarily a bad thing in my opinion. But maybe it'= s > > good to discuss the future plans as well. > > For any new nullable construct should we use a ReflectionUnionType with > > ReflectionNamedType for null and not use the allowsNull method? > > Should we have a plan to convert current nullable constructs to a > > ReflectionUnionType and eventually drop the allowsNull method in PHP 9.= 0? > > > > From my understanding and the comments in the source code, and Nikita mig= ht > want to clarify, the only reason why it still returns a NamedType is for > BC, to allow tools that worked on PHP 7 to still run on PHP 8 even if > nothing else changed. > As Reflection based tooling gets updated to deal with the additions to th= e > type system I expect that we will change the representation of ?T to a > ReflectionUnionType, as to maintain the old behaviour we do things that > could be removed and simplified by using the more standard representation= . > > Thanks for sharing this. In this case, using a ReflectionUnionType sounds perfectly in line with the plans for the future. Related to my mention about deprecation and dropping of allowsNull, I guess that is not really needed. I can see how we could add along with the current public function allowsNull(): bool a new function like public function allows(mixed $value): bool and keeping them both in the end could be fine. But this is a topic for some other RFC, not for this. > On the other hand, while we have the allowsNull method maybe we can keep > > the pattern and not have a BC break and use it everywhere. > > With an union, you need to iterate over all elements in the union and > > check that one is a named reflection for null. > > Is there something we cannot achieve if we do it like this? > > > > This is incorrect: https://3v4l.org/P9U4u > There is no intention to change this behaviour in this RFC. > > Thank you for the correction. allowsNull() can be used on the ReflectionUnionType directly, of course. I guess I was trying to find a disadvantage for it but failed. > > The slightly amended RFC can be again found here: > https://wiki.php.net/rfc/null-standalone-type > > Best regards, > > George P. Banyard > Regards, Alex --000000000000accde305cdb985db--