Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115697 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 28558 invoked from network); 12 Aug 2021 13:17:09 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Aug 2021 13:17:09 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8CFA0180088 for ; Thu, 12 Aug 2021 06:48:08 -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-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (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 ; Thu, 12 Aug 2021 06:48:08 -0700 (PDT) Received: by mail-ed1-f50.google.com with SMTP id dj8so1899158edb.2 for ; Thu, 12 Aug 2021 06:48:08 -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=sOR0K87quXpXg5CY4Pt5FkzgAWnfkk3pJocU9bQGiPw=; b=UYIhBQtFZmlJDya+FnIlRupda0t3H3FI3bU1oOz5ge8c0hfgU9PnLz0aV3yofgYFpJ h2JBxEyWpUOIfNWtkr3t4kHU8c9+WkAHcleenib5Eypw0udRtD/36jO355M4XHM8SbWR dcq27ZbtB0ZdcxkYvkqiNOJuo+X5A2FxafAi5fyoKEio+JhSxQUP/+jFduXj9nLeQ7UQ 5Uj116c5+cXZV6NJ0mgABClpHrV3KQ9iGWo5V0SDkdE1INCQ0iK9NSTOz7qGfn7I2UpL BH0c338ypyZZAGEWKoEKCd/npmhbHdrS4J4f6olDDGqyDpgQGmNOyo12EdV4ORjRiOfH uY8w== 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=sOR0K87quXpXg5CY4Pt5FkzgAWnfkk3pJocU9bQGiPw=; b=tlh6Bunr6Gq0Q56LH7wH8vuFwGaqNn/tr6EYlRQLwey+muSGl3vjxsEPoBfZUV7WXv p7QpjNwFyGzJGuNU3ip8kO7k1N9We3byn7XTo52lHO/0UZ471G/Q7hn1dIpCHFXoH+kH h7CD2iA9bcvvIbqW6PBiHy1d8lRwwVyztL9LTE7KdBfkOnAtx42e61eztMv94XVfvZum ZPPrifUTWignGrTZgKVb+mvvSpb8pDT3qwfyH/dC8u6ilHq3Nvb1xvgrGHq8uuBV+V6E f1F678JHx8rbO9796UwQ57J0RHC8bnTSoKfL4vOwkNVhgGSwo0YrZImhTQGHBbtPcBwI OQWg== X-Gm-Message-State: AOAM531DQbldgszbxzOopXb5xt5l9vd4Cqcp2xkOsp6d3sMKWMV/hTll c8mLLNEpwNUSZ21hydI9Kn38qrQ1TrPOr3TxKAw= X-Google-Smtp-Source: ABdhPJzPVTfrkJ8eCY3rT7RurL3KTVLJbft45xMUiA5Nzs3lNg+sC4K3tBs8LiZseL9BCLpYHElAh9ZlBdPL8AzixKM= X-Received: by 2002:aa7:d3cc:: with SMTP id o12mr5415778edr.335.1628776079952; Thu, 12 Aug 2021 06:47:59 -0700 (PDT) MIME-Version: 1.0 References: <09e013c7-7104-82be-6711-41f74d9f1666@gmail.com> <7ea8efdf-38b0-47d3-59b6-f6cb6665b284@gmail.com> In-Reply-To: <7ea8efdf-38b0-47d3-59b6-f6cb6665b284@gmail.com> Date: Thu, 12 Aug 2021 15:47:47 +0200 Message-ID: To: Rowan Tommins Cc: PHP Internals List Content-Type: multipart/alternative; boundary="000000000000aa0e2a05c95cfbb0" Subject: Re: [PHP-DEV] Re: [RFC] Nullable intersection types From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --000000000000aa0e2a05c95cfbb0 Content-Type: text/plain; charset="UTF-8" > On 11/08/2021 13:09, Nicolas Grekas wrote: > > > > On 10/08/2021 13:39, Nicolas Grekas wrote: > > > I will wait if I don't have the choice, but as many others > > reported, the > > > experience with 7.0 missing nullability was a pain. > > > > Apologies if you already did and I've forgotten, but could you please > > expand on what "pain" you are referring to here? > > > > > > I personally did not experience that pain because I just skipped 7.0, > > since it wouldn't allow expressing the nullable return types I had to > > express in the APIs I maintain. > > > Sorry, I'm still confused what the "pain" is *other than* feeling > obliged to wait until 7.1. > Maybe others that read this can share their experience on the topic? > The larger issue is that when used as a type on arguments, adding the > > nullability flag isn't possible without a BC breaking change. > > > I can't imagine many people will force a parameter to be non-nullable > just to use the shiny new syntax, then re-allow nulls in a subsequent > version. More likely, they will leave that parameter un-checked until > the full type can be specified. > > There is also a lot of code out there which is either: > > * in stand-alone applications, so backwards compatibility has no meaning > * in private libraries with a handful of uses, so bringing uses in line > is trivial > * in public libraries, but marked "private" or "final", or documented as > "internal use only", and therefore not subject to compatibility guarantees > > > > But until it's too late, I'm willing to engage in this topic because I > > think the current state is far from ideal for 8.1. > > > There are always more features we could add, and there will always be a > judgement call of what versions of PHP a code base should support. > > If it was generally agreed that there was only one right way to > implement nullable intersections, and it was a trivial change, then I'd > support it as a "quick win"; but that doesn't seem to be the case. > It is a trivial change from a technical pov, that's why I submit it for 8.1. There's zero risk. Thanks for your feedback btw! Nicolas --000000000000aa0e2a05c95cfbb0--