Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104300
MIME-Version: 1.0
Date: Fri, 8 Feb 2019 08:20:09 +0100
Message-ID: <CADqTB_gteykpHroN8MFLuMEFsh+oNmZ3RhsGvBx_yY-5zGvnJg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000750c0a05815ccaf0"
Subject: Mixed type-hint
From: rasmus@mindplay.dk (Rasmus Schultz)

--000000000000750c0a05815ccaf0
Content-Type: text/plain; charset="UTF-8"

Regarding the mixed type-hint RFC:

https://wiki.php.net/rfc/mixed-typehint

> When no native type is present, it is unclear what type is expected

Regarding variance - in the examples shown in the RFC, it is still unclear
whether your intention was variance, or if you just omitted the type-hint
by accident.

The introduction of the mixed type-hint, as I was trying to explain
earlier, could have addressed that problem - by allowing mixed variance
only with an explicit type-hint and disallowing implicit variance.

As I pointed out when the variance RFCs were accepted, it's too late to
remove this allowance now, as that would be a breaking change.

However, could we at least make it an E_STRICT?

So that, given the following:

class A {
    public function foo(int $value) {}
}

The following would emit an E_STRICT:

class B extends A {
    public function foo($value) {} // E_STRICT: implied variance
}

And the following would not:

class B extends A {
    public function foo(mixed $value) {} // explicit variance
}

An E_STRICT is not a breaking change, right?

At least then we can map E_STRICT to an ErrorException during development.

Without this, the mixed type-hint is basically meaningless noise, is it
not? About as effective is a doc-block?

--000000000000750c0a05815ccaf0--