Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115574 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 53995 invoked from network); 24 Jul 2021 06:17:27 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Jul 2021 06:17:27 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 0BE06180503 for ; Fri, 23 Jul 2021 23:43:35 -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.6 required=5.0 tests=BAYES_00,BODY_8BITS, 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-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (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 23:43:34 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id f18so5717230lfu.10 for ; Fri, 23 Jul 2021 23:43:34 -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=tOyGKl1kgM7U558q5DHELIrceBeZ3Esz++cw8xqb754=; b=uPS82kCt4xu1DRHa/GqZa2CyQBoiDwci8HgpMn7uVppo+u/WsTMO1pFJVuv1zaAX/K uGrnsu1/ftRVOBI6wJUyobtM0qceRVVvFVgMc2fyRKmFMr7MwLVOYREhWp30l+PQBYzJ mTB9L1Wg7TipfiTGSG3dEKYoHyUyAFfVhnrpwN+hZx6Aes+TtTbD2Bst48VXjOwLNv8x GhV5XjVja52Vj2MMgSenSCBc3KPlZ4ND6tqv1wJVyMAFop7qqsqLc/ez0EBARSlyQQyK UYJ8A4LW6DRyo41mcEU4L1M+9PzLDZjLzkT0bH+Ui3UhAil8LmcUNdtksqnHn0hVYlN9 3gNQ== 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=tOyGKl1kgM7U558q5DHELIrceBeZ3Esz++cw8xqb754=; b=fxAqMAenFy30CZHPdxi9hC8SHLw3lMG2nQUB/3CMlKzpcTICY1AmDVzpQj3K5sJMxj NnWBXOVFuOXLc1/6wfb/sps7koBRi5cFztxs4OjEQAjcdKlcQ2uaZaKNnj7z5DSeXPR1 2pce+ndjtN7ANuFD4Fqc0zgmgxkIGQfszIC266LDG82WHNXrjzVCKaaAtonNhcuAl416 ss2MtSnQP0GNNV7cl0rPx3M2cz2koSrshiBC/jC/W9pi8X1JY81dnGg6iP7Di3+wE3gJ 4hYIojmI0uuLVLqFEEuv1SvoVG+6M3uardp0XsCqC2jLNrptzC2LPhb5ZfLvMes4qs5v BviA== X-Gm-Message-State: AOAM530Rh+TLJJ2OemYDgNTuS14Qte1c9ON4ECiJMkMgLzCHBiPBx3Qc Qa8kD6fE6UuFQr3GVE/bK11nOWpWoNr+CdENuQE= X-Google-Smtp-Source: ABdhPJxp4YJZwWc+zBxxd0RwK1YKBTkeJf6dV3RrSbAtJtwB/G2XCmnxFSn2EqDmo5lhmlKNyaWzDYzLapO0dud5DaI= X-Received: by 2002:a05:6512:ac7:: with SMTP id n7mr5381652lfu.564.1627109009729; Fri, 23 Jul 2021 23:43:29 -0700 (PDT) MIME-Version: 1.0 References: <353F9140-7E59-4CD4-95D3-9BA8F9CA6C29@newclarity.net> <43D8F75F-09B0-4AE4-A9EB-8775E231B367@gmail.com> In-Reply-To: <43D8F75F-09B0-4AE4-A9EB-8775E231B367@gmail.com> Date: Fri, 23 Jul 2021 23:43:29 -0700 Message-ID: To: Tobias Nyholm Cc: Mike Schinkel , Nicolas Grekas , PHP Internals List Content-Type: multipart/alternative; boundary="000000000000892ee405c7d8d6e6" Subject: Re: [PHP-DEV] [RFC] Nullable intersection types From: jordan.ledoux@gmail.com (Jordan LeDoux) --000000000000892ee405c7d8d6e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I do not think this is strictly true. The issue that this RFC is running into is that combination types between intersections and unions was something that was avoided for the intersection types RFC. Not because the authors never thought of it, but because the RFC would have become very broad and encompassed many different discussions. But since the issue of adding combination types *only* for null is now being presented, it seems to me that a lot of people are taking the position that the syntax for it should match what the future implementation of combination types is to avoid confusion. I don't think that's an unreasonable position to take, and the difficulty of that discussion perhaps illustrates why this wasn't included in the original RFC. > We are not seeking compromises at the moment. We are seeking the best technical solution to a technical issue. But this presumes that the ONLY technical issue at hand is the ability to have nullable intersections. Intersections are only available for class types, you can't use intersections with scalars. The *best* technical solution since there are no scalars is for people to use classes which have a null state internally, or at least I could argue that's the case. (In fact I *did* argue that's the case in a previous thread.) I'm not even convinced that this is a technical issue at this point, so the idea that there's no need for compromise is rather strange to me. If the goal is to support nothing but nullable intersections, there's an entire programming pattern[1] to solve that concern. But as nulls have always just "worked" for most PHP developers, I *can* see the argument for it despite the fact that I think it promotes bad program design. I know that I will use intersection types with the null object pattern in my own libraries even if nullable intersection types are added. So given that it's a special case of combination types, it makes sense that people are at least *discussing* what combination types should look like longer term. > I don=E2=80=99t understand why we should require something that is not ne= eded simply because it would give us an option to remove it later=E2=80=A6 The point (I think) that Larry was making is that the parentheses can always be made optional in the future, but if this is delivered without parentheses now, it will be very, very hard to make parenthesis mandatory later (BC break) if there is a reason to do so. What would that reason be? I'm not sure, because a full implementation and RFC for combination types hasn't been proposed yet So requiring parentheses places the fewest restrictions on the anticipated future RFC for combination types and allows the author to find the best technical solution to *that* issue. --- [1]: https://en.wikipedia.org/wiki/Null_object_pattern On Fri, Jul 23, 2021 at 9:43 PM Tobias Nyholm wrote: > > It seems this RFC is actually trying to accomplish two(2) things: > > > > 1. Add typehints for nullable intersection types to PHP. > > 2. Get PHP to support a preferred syntax for type-hinting nullable > intersection types. > > Yes of course. You cannot really do #1 without #2. > > I agree with Nicolas that `?X&Y` makes more sense. You add ? before the > type. If the type is scalar, a class or an intersection type should not > matter. But I hear some technical arguments from Derick so I won=E2=80=99= t argue > against that. > > Im fine with the syntax: `X & Y | null` > I don=E2=80=99t think parentheses should be required. From a mathematical > perspective you want to add parentheses when you want to override the > operation order. If you remove the parentheses and the expression has the > same order of operations, then the parentheses is clearly not needed. > > @Larry makes an argument to keep them: > > > Requiring parenthesis now leaves the option open in the future to make > them optional when doing full mixed types. > > > I don=E2=80=99t understand why we should require something that is not ne= eded > simply because it would give us an option to remove it later=E2=80=A6 Cou= ld you > elaborate why this is important? (Im probably missing something) > > > Given both of these sets of assertions I would ask the RFC's author and > proponents what would be a worse outcome? > > I don=E2=80=99t see how this question is relevant. We are not seeking com= promises > at the moment. We are seeking the best technical solution to a technical > issue. > > > Also, the entire discussion has claimed a "need" for nullable > intersection types but AFAIIK they have been presented in completely > abstract terms; i.e. no one has presented any real-world scenarios where > they would actually use nullable intersection types. > > > The =E2=80=9Cneed=E2=80=9D is covered by the discussion about PHP 7.0. Se= e this post as an > example: https://externals.io/message/115554#115563 < > https://externals.io/message/115554#115563> > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > When reading my message above could make it sound like I am pessimistic. > That is not true. I am excited about this change and I am happy PHP has a > long feature freeze so issues like this can show up before the release. > > Regards, > Tobias > > > > On 23 Jul 2021, at 20:53, Mike Schinkel wrote: > > > >> On Jul 23, 2021, at 5:58 AM, Nicolas Grekas > wrote: > >> > >> Hi everyone, > >> > >> as proposed by Nikita and Joe, I'm submitting this late RFC for your > >> consideration for inclusion in PHP 8.1. Intersection types as currentl= y > >> 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. > >> > >> Have a nice read, > >> > >> Nicolas > > > > It seems this RFC is actually trying to accomplish two(2) things: > > > > 1. Add typehints for nullable intersection types to PHP. > > 2. Get PHP to support a preferred syntax for type-hinting nullable > intersection types. > > > > Further: > > > > A. There seems to be consensus on the value of #1. > > B. There seems to be consensus on using a syntax with parentheses for > #1. > > C. There is a lot of pushback on #2. > > D. The desired syntax in #2 would reduce future flexibility, as Larry > Garfield commented. > > > > Given both of these sets of assertions I would ask the RFC's author and > proponents what would be a worse outcome? > > > > X. Getting typehints for nullable intersection types added to PHP, but > not the desired syntax? > > Y. Not getting typehints for nullable intersection types added to PHP? > > > > When answering please consider that #X is the outcome that would not > preclude possibly getting #2 at a future date. > > > > --------- > > > > Also, the entire discussion has claimed a "need" for nullable > intersection types but AFAIIK they have been presented in completely > abstract terms; i.e. no one has presented any real-world scenarios where > they would actually use nullable intersection types. > > > > It might be helpful =E2=80=94 or at least it would be for me =E2=80=94 = if the RFC could > add two or three real-world example use-cases where the author and > proponents would actually like to use nullable intersection types in thei= r > future PHP code. > > > > #jmtcw > > > > -Mike > > --000000000000892ee405c7d8d6e6--