Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115726 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3592 invoked from network); 14 Aug 2021 15:10:26 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Aug 2021 15:10:26 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D2D241804D8 for ; Sat, 14 Aug 2021 08:41:56 -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-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (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 08:41:56 -0700 (PDT) Received: by mail-lf1-f48.google.com with SMTP id c24so25742572lfi.11 for ; Sat, 14 Aug 2021 08:41:56 -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=rbTXhmuVD8BDcqGQ/X7kCxiSxB0B3QAKWBRt9I7YIWQ=; b=k0dXfcKiyYzTSD40dapNutxaeclcexCAlkqHygk6DAZFVtcBvJckcWtcCkQIMEkoNa w6NieJpHFfAc/pOe7uv7bBx8NpavOlvV+Qixz+odgMErGbXwgb+4u93X0kB/I4lsxiVG M28VaSkG+n2PC97E1LEeteBGNp+1dyxU+g9IaDXdFD/1DkOaBdGIdBB/qT0ynN3lCNbV y+Wy42B5EccGOXnCnqVtB9i9Nb5kitm64kNioKbhhItKBZpoVsLLVi+wMoeV7kDldMSb xRn6X8e637uZCGZoupz4ROl9TUAhQLl6R96mgECgWv8T/sy8DpfXhGhdk7Y3HQYFZ1pc sJcA== 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=rbTXhmuVD8BDcqGQ/X7kCxiSxB0B3QAKWBRt9I7YIWQ=; b=R9RK1JCfMrJzCmPmGIxSbMxh/22Nvxt2fd6f0BP+9oCGUYHMi5mWGDkQfKdwGpBYZU fxL5Z1dNK3/oZ1HHgyPjaRrZBiDg3rD38zV/smi2+56LOEIkRzpNpabCcpWLGI9keVHb qeFhQPxbiDI9HwH0kLaCSSJfvLWxvAnhjuKlZiSseGoiIZvB4GS7mee9PBuDHQ564eGX 7kq4JrbjKeAnpe38B0UOnOYgmGJAvMxsHSXQwT+/BFQitXkgh2gcAY+dum8qItmq0SR/ iMo/AWiVtqMFTu9CISn7cT6zG+8FeKYYa6hhqyFik3aERw4Sbuzhjd6in3fNdBg99Zgi MCAQ== X-Gm-Message-State: AOAM5329wF3Z0yokGvOnBtb2m0OTu1uVOUX7GWqH3h62W6J7XJL99p+p DMOu9k9r3ll83Ye8xenIKdqelxl40PlVRl7oyn4= X-Google-Smtp-Source: ABdhPJygX5FahJLBJ9EOXAtyQQ9K5QLVy0QhSbvdtMyd/8YK9OuBbUtHjQY6QUPGTb5eL/aQpwUYEUqgbLYmWhqhk9Y= X-Received: by 2002:a05:6512:16a0:: with SMTP id bu32mr5503823lfb.322.1628955714962; Sat, 14 Aug 2021 08:41:54 -0700 (PDT) MIME-Version: 1.0 References: <64b3800a-c54e-c1cc-8bab-bc503a969c37@allenjb.me.uk> In-Reply-To: Date: Sat, 14 Aug 2021 08:41:50 -0700 Message-ID: To: "G. P. B." Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000becbb705c986ceab" Subject: Re: [PHP-DEV] [RFC] Never For Argument Types From: jordan.ledoux@gmail.com (Jordan LeDoux) --000000000000becbb705c986ceab Content-Type: text/plain; charset="UTF-8" The RFC has been moved to the wiki: https://wiki.php.net/rfc/never_for_parameter_types The most critical points of discussion in my mind are: 1. Should never require **explicit** widening as discussed? This could be very useful but would make it the only case in PHP where omitting a type is not seen as "mixed". (This could be set up as a secondary vote.) 2. If the answer to question #1 is yes, should an error specific to this case be provided instead of the more generic "declaration of A must be compatible with B"? 3. Should we attempt to limit usage of this feature to only interfaces and abstract classes? (NOTE: It's unclear how such a thing would be implemented or if it is feasible.) If it must be available to all function parameters due to implementation, is that acceptable? To clarify, this feature is most critically useful for certain internally provided interfaces, such as ArrayAccess or the proposed interfaces in my draft of Operator Overloads. I'm sure it would find use in user code as well (I know that I would use it in certain interfaces in my own libraries), but it's absence actually makes certain core features very difficult to provide in an intelligent way. Jordan --000000000000becbb705c986ceab--