Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115560 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 90511 invoked from network); 23 Jul 2021 12:44:54 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Jul 2021 12:44:54 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 732341804D8 for ; Fri, 23 Jul 2021 06:10:51 -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-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) (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 ; Fri, 23 Jul 2021 06:10:51 -0700 (PDT) Received: by mail-ej1-f44.google.com with SMTP id nb11so3640544ejc.4 for ; Fri, 23 Jul 2021 06:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K46n7glaFmIOa+k64PmTbkfwl8lcsOQT+L0ZCCaT47E=; b=F/+ZKVDDipsldUHF+Jtq3QcqOEjnzEVe2PUNT6Gaz6rqZJCnRbaNizRnKiMQz0fl6x SlfaGvMpPzo1/K4cIdXe9QLBHAMj0cBQtGoHX2PK60jiQtuwsTGKG9gXsEHkrWxBMcNb yw8ea0p1ApqF5AFf+NaZRhAlKa3VVXuexH7eF2sphthBZH6x4dUOTbeOV4J+QJPfV/YJ JYHOnB0qNeGiqLMRq3F/6cE52xorDO3k5+oolh+quVYr3/gOLqBPzmPVE4baMkVMskKJ kS/c+c6l8SnR8AGzRrc0fyn2jh9RHh4txUWKjwK46aiSOY8s6ZLCkLuqEIw0RXTT2jYa yBKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K46n7glaFmIOa+k64PmTbkfwl8lcsOQT+L0ZCCaT47E=; b=CF7IRTVZry9XLNMD0NNWCQ7fTKsKWC+c9+HS4Kg13Sa+NGSy4mCn/19J3OCopBG59T AQ0mU9MqH1dE2lvnLMtPUH3+xCQl4/d7Jad1BigBSDhxkYmDyLQKQNBc2+wVDAaILlCL v9RVD649tlId6TFl6UWxTcEuzqNDSMWrQVUQ0UnjbF5KR1/uKgC6/6jXoSlActsVsHUb LOKF1ZUkHqsXVBNIAK1osZ/yRTttjPcoFD9jPxPz8kBK8EE9uMJbA/agZlGxfaK4L4kM cXFpNQz6Hwv4PRVPeRvlQ6oR7E7rwG7DYxI6RhFmCeDj0dhEZTTS8jJdJGMvjMJbTUAE J2Hg== X-Gm-Message-State: AOAM533ezcMOQb9ona5jBNMs7uFQM1AhdQofDEy/sEgIqg5bmRLfZMx7 1VVw1+C5GVuB7vyh+hXDGY3pxAXQrBY98fXrbPU= X-Google-Smtp-Source: ABdhPJw5jve6P1xebXdjB1/v0hKQXittEMpVztDEerkvYUeRzPUBplsitCq3qA0w2mbbX6JGv4a+Xp1LlPp8UkndX+8= X-Received: by 2002:a17:906:c256:: with SMTP id bl22mr4686949ejb.115.1627045848811; Fri, 23 Jul 2021 06:10:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 23 Jul 2021 15:10:36 +0200 Message-ID: To: Derick Rethans Cc: PHP Internals List Content-Type: multipart/alternative; boundary="000000000000da0c1e05c7ca2155" Subject: Re: [PHP-DEV] [RFC] Nullable intersection types From: nicolas.grekas@gmail.com (Nicolas Grekas) --000000000000da0c1e05c7ca2155 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > as proposed by Nikita and Joe, I'm submitting this late RFC for your > > consideration for inclusion in PHP 8.1. Intersection types as > > currently accepted are not nullable. This RFC proposes to make them > > so. > > > > I wrote everything down about the reasons why here: > > https://wiki.php.net/rfc/nullable_intersection_types > > > > Please have a look and let me know what you think. > > From the RFC: =C2=ABTaking all these elements into account, the preferenc= e > of... and thus to use the "?X&Y" syntax=C2=BB. > > I think this would be a mistake. You touch upon operator precedence, and > needing to know whether | or & is higher, and inventing a new precedence > for ?. > > I would strongly advocate for not getting into the realm with any > operator precendence, but instead *require* parenthesis for any > combination. This gives the code reader and writer an immediate clue > about what the code does. Most coding standards also recommend this for > expressions in "if" statements and the like. > > I do however agree with Sara's =C2=ABover-delivering syntax that hasn't b= een > entirely thought through=C2=BB point. It will take a lot longer to come u= p > with a proposal to combine intersection and union types. > That's another reason why I prefer going with "?X&Y". The situation we have here is very close to what we had back in 2016 when nullable types were introduced: we figured out that nullability was very much needed now, so we went with a syntax that would not overlap with a possible future RFC for unions. IMHO, going with (X&Y)|null is forcing a future we know little about. > That in combination that you're proposing this RFC after feature freeze, > while you've had four months to make this arguments as part of the "Pure > Intersection Types" RFC, I am currently not going to support this RFC > for inclusion into PHP 8.1. I wish I could have spotted that this discussion was needed earlier. Still, this is important for 8.1 (IMHO). From the RFC: > For userland, if this nullable capability were added to a later version of PHP, making a parameter nullable later would cause a BC break (or force a major version bump when using semver.) Also this: > When PHP 7.0 introduced scalar types, it was obvious that the special nul= l type was missing as a way to declare that null was a possible return value. PHP 7.1 added the =E2=80=9C?foo=E2=80=9D syntax to declare their nullabilit= y. This lesson from history tells us that the nullable type is special and very much needed in PHP. Nicolas --000000000000da0c1e05c7ca2155--