Removing warning for failed include

  109315
March 26, 2020 00:11 internals@lists.php.net ("Levi Morrison via internals")
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?
  109317
March 26, 2020 01:52 claude.pache@gmail.com (Claude Pache)
> Le 26 mars 2020 à 01:11, Levi Morrison via internals <internals@lists.php.net> a écrit : > > 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? >
A quick look on the code base I’m taking care of, reveals that most `include` instructions expect that the file will be in fact included. If it isn’t, the error handler will be triggered and send me a bug report. (Yes I know, all those `include` could have been spelled `require`.) On the other hand, in the occasional cases where I do want to include a file only if it exists, I wouldn’t lightheartedly remove the `file_exists()` check, because its presence makes the intent of the code clearer. —Claude
  109324
March 26, 2020 08:49 nikita.ppv@gmail.com (Nikita Popov)
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