Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106543
MIME-Version: 1.0
References: <CAF+90c99ftVY4KndJAH_851sEAF===4iyUgSqrc3nEsL833BhQ@mail.gmail.com>
 <CAESVnVqvSt_U8g=cwRu0pfEVrByYVmec_LHDa8jHtem95E=i9g@mail.gmail.com>
In-Reply-To: <CAESVnVqvSt_U8g=cwRu0pfEVrByYVmec_LHDa8jHtem95E=i9g@mail.gmail.com>
Date: Sun, 11 Aug 2019 14:50:44 +0200
Message-ID: <CAF+90c98JVkbOO7wrD5=ESDeD0wC8ChWo4WvC0by+MMjiMry3g@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000023a9c058fd6dc2f"
Subject: Re: [PHP-DEV] Adding return types to internal methods (PHP 8)
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000023a9c058fd6dc2f
Content-Type: text/plain; charset="UTF-8"

On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon <pollita@php.net> wrote:

> On Sun, Aug 11, 2019 at 3:44 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> What do you think about this? As we are currently annotating everything
>> with types, and we're at a major version, this would be the ideal time to
>> make this change. But there's certainly a BC break here. (And, for the
>> record, this is not the type of BC break where P++ or editions help,
>> without creating a larger mess.)
>>
>> I think your original proposal was spot on.  It added to the language
> without creating any BC breaks. The ideal outcome.
> This modification adds an admittedly small BC break for an equally small
> benefit.
>
> -1 from me.
>
> -Sara
>
> 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).

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.

Regards,
Nikita

--000000000000023a9c058fd6dc2f--