Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109324 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 54160 invoked from network); 26 Mar 2020 10:24:57 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Mar 2020 10:24:57 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 198EF1804E6 for ; Thu, 26 Mar 2020 01:49:50 -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,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-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (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 ; Thu, 26 Mar 2020 01:49:49 -0700 (PDT) Received: by mail-lf1-f44.google.com with SMTP id t16so3287285lfl.2 for ; Thu, 26 Mar 2020 01:49:49 -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=x9Gaa+1HfilNPpXNXdt2oIysy+SWi2mLbUZ5sqq6xgI=; b=vMmRgQN6A19hkbB2XJb5jh4v8Frw+z9CiJDXHXWos+OmsvfVnHIDH5d1Gx1lLYDlId q8xFG6ODoWhPDy0QJncE0mGTCKmCkNvOfIOWEHiOmj5azsnfJRNW+sGXfxpvAdfXujdf PLRntbUhnwoGFDYLsG1pYsGkfdTg3t1I7JNukxNvtayUSHSHSqT6w18kgkiZbRXF1lV0 9vFDyxQfoTDJN4VBQeWgI5HbOQ8aq8cxSFiDG7bKH6BS8vThUKdh0zto6ze8hlMaMBjW NmWB9ocztXMGlE0ntCzOXWnIMLcih4y9nZdBc9UDY5h8u1mVmErlQ7LoUZdhPLUnc7tT kjwg== 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=x9Gaa+1HfilNPpXNXdt2oIysy+SWi2mLbUZ5sqq6xgI=; b=CObTQr507ulgyojHF/eIrz2S3Q/uHqWndpI/Dl0DhDXolbeJ6X6W00yfiQI1VJHMPw inV6g6Zwn36CJ4DENkHUGrkB9R4z8xH3JAg75DhZjAYLIlvHcV/eDPmQJVrHW+jxvFjd Ny9S6Tfe7fa2ifkJbDTsn0DWifdkDZfgXq6BuLomUj32YKY8gWthWpm9x9VtHBkWJ3H6 hssotNQUcz/Y+m3C8qElxpuwiyWpIqMVwMQKGqapHn2vjxjoylDZRPLZr0qXZhZps7xq cOE71iTnzaZi1G8NnPUXh2sOdrdSlI9aT4M3z57wDvw4v97d8o2jwn/ASZCttXILHz1O YveA== X-Gm-Message-State: ANhLgQ3yWvv+taUd/MAysKD7uuedqDCo4qaZk5S/c8/XWdJXVmG7gBrO fvn2tZ2N/gKqbDB8Zwp8K5hzfnngY2HQ/EFrmrU= X-Google-Smtp-Source: ADFU+vtuO1lFhskKPnjjp1s2gTDH/ZENFP8F8z1V3dS6YGCfR1kOzp52sXyEZhz8VxF1ObdO5eCogwa4etFvg7vzR74= X-Received: by 2002:a19:5e06:: with SMTP id s6mr5136278lfb.154.1585212587481; Thu, 26 Mar 2020 01:49:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 26 Mar 2020 09:49:31 +0100 Message-ID: To: Levi Morrison Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000002b9f4405a1be11c9" Subject: Re: [PHP-DEV] Removing warning for failed include From: nikita.ppv@gmail.com (Nikita Popov) --0000000000002b9f4405a1be11c9 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 26, 2020 at 1:11 AM Levi Morrison via internals < internals@lists.php.net> wrote: > It's bothered me for quite some time that a failed include emits a > warning. This is because it's by design that the author chose > `include` and not `require`. It's _expected_ that it may fail and they > are okay with that. > > As an example, consider a classic autoloading case. It could be as > simple and performant as: > > $file = /* something derived from class name */; > include $file; > > But because of the warning, in practice authors tend to use > `file_exists` + require instead: > > $file = /* something derived from class name */; > if (file_exists($file)) { > require $file; > } > > Weird isn't it? Authors are using require instead of include for the > case where failure is tolerated. This is a clear signal to me that > include isn't doing its job. The warning gets in the way. > > Any reasons we shouldn't just remove this warning for PHP 8? > I don't think this really matches how include is being used in practice. I think to the most part "include" is just the legacy spelling of "require", and people are going to be very confused if it can silently do nothing. If you want to make a change in this area, I'd go for deprecating "include" to reduce the language complexity in this area (include, include_once, require, require_once, which should I use in any particular situation?), though probably the case for that is not particularly strong either. Regards, Nikita --0000000000002b9f4405a1be11c9--