Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115723 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 97137 invoked from network); 14 Aug 2021 14:08:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Aug 2021 14:08:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 17AA81804D4 for ; Sat, 14 Aug 2021 07:39:45 -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-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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 07:39:44 -0700 (PDT) Received: by mail-ed1-f53.google.com with SMTP id by4so19799616edb.0 for ; Sat, 14 Aug 2021 07:39:44 -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=iHcqTk9MmlJijCFeIl6zvVaAqyvVlHkmaRrXAttkHrw=; b=OvrWFxOMPLzk0EnjFtKkcQxTtbEZeSDKziXNAyWiBCMzsUHgQRHbXZbwGfP2pQkCuZ zNQ4DG7tUDQwDRGttp7gBKHHqftE4OHJDTefDe6nzcIQzFcLz5snB+786KpzatzRtxb7 hyRxV23NWikIk6uF8d7xxOa4htD5i1YIZNDvb0spjqoM6bScYS+M9wmBennBV9BFJ85T AnwOtko2Qc77KiqV267EDXFUF4jb7gS1XTyM9nr1z/cJqwQRmAPWEw8Xjo9isFd9IWpv vVnSy8HVHMxApLnNAhNPOOaB8PRaj9MDMJfk/dJL1vbsepLgqkWVHdfNU6urHA4Rgf8e UEcA== 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=iHcqTk9MmlJijCFeIl6zvVaAqyvVlHkmaRrXAttkHrw=; b=ueUiqdnBn5QNKTbs1C1LE5SbiyqG1L2X+UWefIN0WPtVrYQOYjprl2EFFNU8sZnmVz GeDkJZHtHd9LzdWWTXEx4gKD9YG3HXN3yGckAwa8fiZHawghjIIQATgI7U6JIj+e2qER +4nF8pyZETqOmnqj0WLXu/CbbeNlyvljX+wmA7q6vgFNYqhjRWbOrpCtzcyp8G/8fST+ y5mNvAd3ww9OnTUqoM8aqQkHx4Ik0EffGdb6CYNOanLC7zBMUX76TXYPLSsfVx+JWsHC SsFezdYOd0wegDvaCHeH59iW/EdK+c8eEXwv6Cx6k4HItnpnalj6ji3w2mJ1wokf6zbd C9VA== X-Gm-Message-State: AOAM531lfDRN1OqdDEgnv08WblSvjYw9c4c5CaxRRCyFzrvAXDO1tgTb L6n3KvrU7+8JxHZ6uTtw4kQi/B1P13ZFyYkeass= X-Google-Smtp-Source: ABdhPJzYBluOhM6UHMB41henz6MwhzX3Z5tz7zGLNPgfnOFf/bc24INU/P6UGa+AESgKuwZnv8XSZR2EVKMCfuqyumg= X-Received: by 2002:a05:6402:2787:: with SMTP id b7mr9461714ede.293.1628951983393; Sat, 14 Aug 2021 07:39:43 -0700 (PDT) MIME-Version: 1.0 References: <64b3800a-c54e-c1cc-8bab-bc503a969c37@allenjb.me.uk> In-Reply-To: <64b3800a-c54e-c1cc-8bab-bc503a969c37@allenjb.me.uk> Date: Sat, 14 Aug 2021 16:39:31 +0200 Message-ID: To: AllenJB Cc: Jordan LeDoux , PHP internals Content-Type: multipart/alternative; boundary="000000000000538ffc05c985f053" Subject: Re: [PHP-DEV] [RFC] Never For Argument Types From: george.banyard@gmail.com ("G. P. B.") --000000000000538ffc05c985f053 Content-Type: text/plain; charset="UTF-8" On Sat, 14 Aug 2021 at 16:01, AllenJB wrote: > This RFC only considers this feature for arguments. Why is it also not a > valid feature for return types? I think it might be useful for abstract > classes and interfaces (for example, the Iterator interface) to force > implementers to specify a return type for certain methods whilst not > specifying anything about it themselves. > You can already do this since PHP 7.4, because return types are co-variant. Any implementor can add a return type to specify what they return, as mixed is the top type. This RFC is not about "forcing" X to declare a type, it is to allow variance changes which cannot currently be done (well except adding a dummy argument type of bool that you can widen to something more general and just need to check the case is not bool but that's also hackery). This feature is for sure an edge case and not a replacement for generics, but the main motivation I see is to be useful for engine hooks like a Equatable/Ordable comparison overload or more general operator overloading, where if the object doesn't specify it's capability it is like it "implements" the magic method (or whatever it comes to be) with an argument type of "never" which results in a TypeError meaning it does not support this operation. Maybe it does not make sense to make this available for userland, but I do think it is somewhat necessary for these sorts of features to have this concept. Best regards, George P. Banyard --000000000000538ffc05c985f053--