Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115715 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 82842 invoked from network); 14 Aug 2021 12:17:13 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Aug 2021 12:17:13 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 68A631804B3 for ; Sat, 14 Aug 2021 05:48:42 -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_H3,RCVD_IN_MSPIKE_WL,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-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) (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 ; Sat, 14 Aug 2021 05:48:42 -0700 (PDT) Received: by mail-ej1-f41.google.com with SMTP id d11so23342647eja.8 for ; Sat, 14 Aug 2021 05:48:41 -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=IpkRoVDAQi52adL8r1x3yrbavkmHoAz5M4IuBsAqdFI=; b=LDJ1PvNIEYBZxuZBpVqzmM7KxZsTxGUEI8VG4pciViDs1ciyDNuGrSygzMdNjidUs0 ueSYvZm1QrkPpeLrZ6XCo1+iycLhN65Mmt3OVUGCiHGNTaMk9Pnh8QJqnklBVadAqgaO AEG3dvnSMSn2eePI/AVrGowFoQp/csfyeRELMaRctM9XO5FoQxPbqp2JiHy7tTrlcwfv Kij+dkxPlB4TKzBYxqw0f8b2ZIeoevS/X6WghtEk6UUSTf5g5qBkjbWdhKDHD7WYHsKV frgd96ntS4kQkq7YPaywKSdtBBUzVAPeI4AVZtQCeXqMDRUCHiAO2HU2B7LkwjFPCKyl ywDg== 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=IpkRoVDAQi52adL8r1x3yrbavkmHoAz5M4IuBsAqdFI=; b=oD6QzBxQAWbMacKXz3wU9WNYNLhTvNUNzSvoYRbTJ+/KPslZ2C2VA2kPVH8XGL6y9w AX3rgRrNQqijby6q1e8IqTSwyFnwuIMnkNQIKcBmNQxHxc/JiHXvtxjO5qCRjCs6//aW kuzCs1SR3bEeUWL1FPsho9xCoqdVY0H6kynvDunKVsi2sIL+/Fk2hotPXTVZShaPQeWJ jX75jOP5GtfHWNl6GjsE1SyqTmWDGV6VVOGfeSYHqjAOJHb45IXagk1OdU5iQ48aXzFD sL1OKyXD3ofPMrgdUCM/wRKvarWy2NEeMfYzMLddezegkQjpmkCvUGDbcVC1dfdBbIpr Q5rg== X-Gm-Message-State: AOAM533P5p/O7PdFwMs/b0dZpKNyHTAble1J2+pJb/pAHp0Tjy/NYKHF yc0DvkcDb8vyag5QK5sSRzFasHtMDgx0SLMZSkg= X-Google-Smtp-Source: ABdhPJz+MQU73Jkz+KgnPRXryNhKp4MuZbqiNFalWisCQKQZhCrF77mUB5cpc2FU8hBieLM8nfcjo6uNuk6dxldcYuM= X-Received: by 2002:a17:907:1c01:: with SMTP id nc1mr7175692ejc.504.1628945318444; Sat, 14 Aug 2021 05:48:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 14 Aug 2021 14:48:25 +0200 Message-ID: To: Deleu Cc: Jordan LeDoux , PHP internals Content-Type: multipart/alternative; boundary="0000000000001081e905c98463ec" Subject: Re: [PHP-DEV] [RFC] Never For Argument Types From: george.banyard@gmail.com ("G. P. B.") --0000000000001081e905c98463ec Content-Type: text/plain; charset="UTF-8" On Sat, 14 Aug 2021 at 10:55, Deleu wrote: > Hi Jordan, > > Does it make sense to explain in the RFC the difference between never and > mixed in this context? The RFC vaguely mentions that never can never be > used directly, but if it's limited to abstract class and interfaces, isn't > that already impossible to use directly? Or does it mean that the type > would "be allowed" on any function, but because of its intrinsic behavior > it would always fail if used in non-abstract methods? > > Another clarification I'd be interested is about dropping the type > declaration entirely (e.g. https://3v4l.org/a4bfs), because of covariance > (or contravariance, I never know), sub classes can completely drop type > declaration entirely. Will never not allow this? Why? Why not? If it does > allow this, does it really differ from not having any type declaration on > the abstract function? > > My knowledge in this area is practically null so if I'm asking stupid > questions that are easily explained by some blog post I'd he happy to read > it. > never and mixed are on opposite sides of the type hierarchy. mixed is the top type, meaning it's the supertype of any other types, and any other type is a subtype of mixed (excluding void which is not really a "type" if you look at it, from my understanding, in a type theory way). never on the other side is the bottom type, meaning it's the subtype of any other type, and any other type is a supertype of never. Finally a lack of type declaration is treated as mixed. Liskov's substitutions rules dictate that return types are co-variant i.e. more specific, and argument types are contra-variant i.e. more general. This is why any return type can be replaced by never and any argument type can have it's type dropped/changed to mixed. As such replacing never by mixed in an argument is totally possible as mixed is a wider type than never. How I personally see never as an argument type is that you require a mandatory argument but you leave the type constraint up to the implementation. A recent example which bit us in php-src/the PHP documentation is the interface of ArrayAccess, all of the $offset parameters have a mixed type. Until recently the ArrayObject/ArrayIterator had incorrect stubs [1] by indicating that the argument was of type int|string, which practically is the case as SPL's ArrayAccess handler will throw a TypeError on different types, however this is done manually within the call and not when the call is made. Ideally the $offset parameter would be of type never such that SPL, and userland, can specify what type of offsets they accept, be that the usual int|string, only int for list-like objects, only string for dictionary-like objects, maybe even object|int|string to allow GMP objects for arbitrary precision. Whereas every implementer of ArrayAccess is forced to accept mixed for the $offset and need to manually enforce the type. This is the "power" of the never type as an argument type. Best regards, George P. Banyard [1] https://github.com/php/php-src/pull/7215/files#diff-e330df347cac9e68d2d07a06535c534cd8c2438a1af703cd4245b8ce91ec65afL9-R10 --0000000000001081e905c98463ec--