Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106545
MIME-Version: 1.0
References: <CAF+90c99ftVY4KndJAH_851sEAF===4iyUgSqrc3nEsL833BhQ@mail.gmail.com>
 <CAESVnVqvSt_U8g=cwRu0pfEVrByYVmec_LHDa8jHtem95E=i9g@mail.gmail.com> <CAF+90c98JVkbOO7wrD5=ESDeD0wC8ChWo4WvC0by+MMjiMry3g@mail.gmail.com>
In-Reply-To: <CAF+90c98JVkbOO7wrD5=ESDeD0wC8ChWo4WvC0by+MMjiMry3g@mail.gmail.com>
Date: Sun, 11 Aug 2019 08:01:38 -0500
Message-ID: <CAESVnVrd7zmKr=CAOw0OQ1ojDCOCFAnnYbo-AMD8qtcWSZevAg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b5faa8058fd702fa"
Subject: Re: [PHP-DEV] Adding return types to internal methods (PHP 8)
From: pollita@php.net (Sara Golemon)

--000000000000b5faa8058fd702fa
Content-Type: text/plain; charset="UTF-8"

On Sun, Aug 11, 2019 at 7:51 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon <pollita@php.net> wrote:
> > P.S. - Perhaps a way to the middle might be to introduce implicit return
> > type hints.  If a child method is implemented with no return type
> specified
> > on a parent method which has one, then the parent's type is assumed at
> bind
> > time, then we provide a better runtime error if that assumption is
> violated
> > in a strict_types=1 context which is the only place where strict
> covariance
> > of return types matters to PHP.
> >
>
> This is an interesting idea. There's still a BC break here, but it's more
> limited and only applies to code that is actively violating type contracts
> (that were previously implicit). Imho this should not be bound to
> strict_types though: strict_types controls coercion behavior of scalar type
> annotations, and nothing else. It should not be overloaded with this
> additional meaning (and I don't think the BC break is nowhere near large
> enough to justify this overloading).
>
> Fair.  Just trying to tread as light as possible, but there is a vanishing
point.


> Do you have this in mind as something for use by internal classes only, or
> as a general language feature? I can see the use as a general language
> feature (see for example the debacle where PHPUnit added "void" annotations
> to some methods). The migration problem of adding return types is certainly
> not limited to internal classes. On the other hand it does seem somewhat
> weird that an (inherited) return type will be enforced that was not
> explicitly given in the source.
>
> I agree that it would be as useful to userspace classes as internal ones.
It would allow library authors to embrace strong typing without breaking
consumers who are already conforming to docblock types.

It's probably worth proof-of-concepting this and making an RFC irrespective
of the push to annotate all the things.  If feasible and accepted, I'd be
much more on board with including return types for internal methods in that
plan however.

-Sara

--000000000000b5faa8058fd702fa--