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
