Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115502 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 41295 invoked from network); 19 Jul 2021 17:51:31 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 Jul 2021 17:51:31 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 35E8B1804F3 for ; Mon, 19 Jul 2021 11:16:33 -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-Virus: No X-Envelope-From: Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (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 ; Mon, 19 Jul 2021 11:16:32 -0700 (PDT) Received: by mail-ej1-f47.google.com with SMTP id qa36so8867625ejc.10 for ; Mon, 19 Jul 2021 11:16:32 -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=BUHsbmoTRzUdiY1kTbfuCK9NH02jFRjpK6kI6dufOOA=; b=PZIp5ywr1OTrSfgDvP7a93ORcV5k1K3XueId0MsM2b6HYdS4XFSmXL0uFCt4indHrD M56fqJ+IikJSjP3zDHrE5e4zIXqZ9ne43fx6wVUBBTVl/ujQipzrKl6S96ixwr5y0tKe 6NbqLUzQRi8yfE18QbVj2cDlLdP04fiBgwhO+f1MJz4BmHpIRHbItYpvh7TddiEZIbko tdTC2A223NlGhKwG9nHGOgxagxmveLKJ6SRV03vofiNXwKpDD1F99Ll+T5v1E+akAtP9 muK11zZ1KQQWXkIH0989L3m02diy1L7tUl/L/oNBD3S0eG4e2N1k2zSGYbfI8u/VNy5+ 2ahg== 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=BUHsbmoTRzUdiY1kTbfuCK9NH02jFRjpK6kI6dufOOA=; b=Owc0foUpmob3dIQf2VjUgOhBKhZK29AKcXlBwu9hHhr/ObuoyXWqKLBNMQ5xrtdy+P 5yD7XbKm5fvV+40xczfEL8K9j/8vwpLqhsFmalIk4bxyzY05q7kb8pQCiunN7V8ZqE+J la4/L9wD2VRozfnPHfIq3e/13nyeClSzVdq56LwdAztKDGjwiVsmwNQhLMnbrjnF+OgH Ub2BAiB7ZeB/LBs8WAfwQHm43gQG+NKwTvMBtqexdqp9o+sK1hh9YPhOpcTDZeeanTbo X5PFZSib55Axh2fb7I1LQ5uUA4Zv6nO9apXMENMne2Q3Sp08Hn2mb33DTga9ub4MijWA GU1Q== X-Gm-Message-State: AOAM531zAFQKKh54EWsMfvEKr+fNwNtFj43KtLLC3viCBlVLxJo9GrYm nRgpAfZR2dCZ1mdmRas4gzO9Ae8BHRyVWKoUpr8= X-Google-Smtp-Source: ABdhPJw6EBtz51RP/QBiIuHOqk59q3jNXBaOVdR2/fou3b6E6h5RYj98KEoJN0E74U12rcOVUUUhmxateHZ1IOf2Fmc= X-Received: by 2002:a17:906:2844:: with SMTP id s4mr28341268ejc.263.1626718591298; Mon, 19 Jul 2021 11:16:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 19 Jul 2021 20:16:19 +0200 Message-ID: To: Guilliam Xavier Cc: Dan Ackroyd , Nicolas Grekas , PHP Internals List Content-Type: multipart/alternative; boundary="000000000000c8aebd05c77def84" Subject: Re: [PHP-DEV] intersection types and null for defaults, properties and return types From: george.banyard@gmail.com ("G. P. B.") --000000000000c8aebd05c77def84 Content-Type: text/plain; charset="UTF-8" On Mon, 19 Jul 2021 at 18:26, Guilliam Xavier wrote: > On Mon, Jul 19, 2021 at 4:26 PM Nicolas Grekas > wrote: > > > > > https://github.com/php/php-src/pull/7259 > > > > Great! Thanks! Interesting how it works out-of-the-box with just this > addition in Zend/zend_language_parser.y: > > ```diff > type_expr: > type { $$ = $1; } > | '?' type { $$ = $2; $$->attr |= ZEND_TYPE_NULLABLE; } > | union_type { $$ = $1; } > | intersection_type { $$ = $1; } > + | '?' intersection_type { $$ = $2; $$->attr |= ZEND_TYPE_NULLABLE; } > ; > ``` > > On Mon, Jul 19, 2021 at 5:09 PM Dan Ackroyd > wrote: > > > nicolas-grekas wrote on the PR: > > > ?X&Y cannot be confused with > > > > It confused me. A compiler might understand it, but as a human I have > > trouble understanding it. > > > > Trowski wrote: > > > The syntax should be either ?(X&Y) or (X&Y)|null > > > > Non-ambiguous syntax is much better than ambiguous syntax. > > > > Maybe it's just a matter of habit? > For instance I got used to seeing things like `!$x = f()` (e.g. `if (!$x = > f()) { throw /*...*/; } /* use $x */`) because some CS consider explicit > parentheses in `!($x = f())` redundant (as PHP has a special case that > "overrides" the normal precedence `(!$x) = f()` which would be an error). > If you first consider `X&Y` as a type "unit", then it makes sense to make > it "nullable" by prefixing it with `?`, I think? > > > > > > But this discussion is moot for 8.1. > > > > This limitation might make intersection types not be considered usable > > by some projects, but the feature freeze is today. > > > > Which can also be reversed: "The feature freeze is today, but this > limitation might make intersection types not be considered usable by some > projects"? (playing devil's advocate, I don't master the process) > > Regards, > > -- > Guilliam Xavier > Since when is usability for a specific project a consideration an RFC needs to have? If Symfony can't use it in its current state tough luck, I'm sure plenty of other projects can, especially now that using 'new Class' is possible as a default object value. I frankly don't care about being able to have some sort of partial union possible with the usage of intersection types, because it seems the machinery in the engine which makes null work, should also allow any standard PHP types as those are part of a bitflag and handling variance with them seems to work just fine... But for the love of god, this proposed syntax is horrendous, saying ?X&Y is unambiguous is disingenuous. It can either mean (?X)&Y = (X|null)&Y or ?(X&Y) = (X&Y)|null, the former one being bogus as null&Y is an impossible type, something which should error out to point out a potential bug in the same way we do for redundant types that we know at compile time. And if we allow this syntax then we really should be allowing ?A|B which is dumb. (and no ?X&Y is NOT something I consider forward compatible when it is just going to become one more edge case we need to maintain because people have no patience). If ?(X&Y) is allowed then ?(A|B) should also be allowed, and that needs an RFC for sure due to the controversy it had in the union type RFC. The only remaining sensible choice is (X&Y)|null / null|(X&Y), but as I said above if the machinery for null is there it must mean the machinery for int/string/array/float/bool is also there, and frankly being able to do something like (Traversable&Countable)|array is also extremely valuable, maybe even more than nullability, but in any case this is going to be confusing for end-users why only null (or standard PHP types) can be combined in a union with intersection types. That's one reason why it's only pure intersection types, if I had more time (or for crying out loud somebody would have paid me) to work on this I would have loved to get full composite types working. And I find it frankly insulting that in the four month this RFC has been published for discussion, with multiple push backs for voting due to bugs and me wanting that people know what implementation is - for the most part - going to land in php-src, this specific point has not been raised. It just feels like you are pissing on 6+ months of *unpaid* work I did because it doesn't suit your needs, and you just realised that and so decided to throw a wrench into a carefully crafted RFC to "fix" it by using a Twitter mob to put pressure on us/me. Maybe this topic didn't come up because for nearly everyone else "Pure Intersection Types" means what it says on the can, moreso that in the RFC the following line: > This means it would *not* be possible to mix intersection and union types together such as A&B|C, this is left as a future scope makes it clear, and most voters also understood that '?' is not a type "flag" but is syntactic sugar for 'null|'. There are plenty of issues with the implementation, from the whack parser hack, the non support for static/parent/self, to the complexity of the variance code, but I made all of those clear because they made *me* uncomfortable with the implementation. So if you are going to force this crappy syntax, then I'd rather axe this feature completely (and nobody can use/play with it) then have something I do not accept, nor are forced to accept because of a vote, land in core making PHP even more of an inconsistent joke. Best regards, George P. Banyard --000000000000c8aebd05c77def84--