Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114140
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] [Vote] Adding return types to internal methods
Thread-Index: AQHXN0sQDOXF4BnTpkyjI+fKo2GPt6rAKyIAgAO81wKAACPdAIAACfuN
Date: Sat, 24 Apr 2021 20:41:01 +0000
Message-ID:
 <DM6PR07MB6618CA1C569701DF4DF66022F9449@DM6PR07MB6618.namprd07.prod.outlook.com>
References:
 <CAH5C8xX87sVh5NDuQ1EfeEbSxdHawO5yNfk5zHEToAqYGJa7=Q@mail.gmail.com>
 <CADyq6sJ5StVLhgEW86xXcVeETTBUodXWrFkv0Lpin+9+du_WJg@mail.gmail.com>
 <DM6PR07MB66185BDCC679C2F1D621A9A7F9449@DM6PR07MB6618.namprd07.prod.outlook.com>,<CADyq6sKvW7EmyDMraowpbeoKON-K3hQZ5nRrZpvSq_+L9tu4SQ@mail.gmail.com>
In-Reply-To:
 <CADyq6sKvW7EmyDMraowpbeoKON-K3hQZ5nRrZpvSq_+L9tu4SQ@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [WsPJuN2OrqRmr+8kgZgDYlralNvkr/t+5RRIQlNDnukIbxuU9zFJSOQ8WKMXc9Vk]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 4b7cd5ce-afbf-46e7-4693-08d9076145e0
x-ms-traffictypediagnostic: MW2NAM10HT231:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 GPUZIkpmgiRkpj87ClrOEn2jFNtLDh8B5EEyEEb5vT9lHOvRSQRrF4xytgkcXwpjsf+sVrRpV86VAttLv9+5aEO7GP4oDLTZeqamitUmOuVDthgTeG8mcugGZQxkpA9MpSGonph8vvJrF70C6chQ4S05gSc0cM9KQcKhRPSOLH5iiscFRWb+X+d1mEppLYRkPRZ1YQgp2/mcufMJZ0bhtZ8zzA29Gnw8a9MeSz4X5yX3ZPCWMJO7HECmCcgzPvdP6a+YJkKoT4WHZTxONP1op+9egHEl1tTiNOjvx4RAuCKc+AjfoMvh4XbgmQGf7PgLAMUNct+nCiP/v0xjC4g9ZNnktVM8IPP4DDsiG4PtA21ItxatI4zTvbQGKqhaakuBBe51GI3EIX6bEzGWjdzOzXMK96YS5v8Yk3J2YncUOD1oo5l47A78E7fBwzVu4sqo
x-ms-exchange-antispam-messagedata:
 K4VlfANAp/hOmdZHSGlg8qvd8lc42FHsWYNl4nj8+POQMCmR+zgEikNRMWXT6z04QDlLFqTtzrouTCxLwImPM+iVgjBB6Ee+NLbLlWjrVye29iEuhijlou9mcNrZYOXUIjqE+QhupKufzhUmEA8DfJRTt7CP17oTm1yl7g8ZmxLJ62yDyRm8rdOmYbJR5g849jVSFBJRSH3qx4nW0kZMVQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: MW2NAM10FT034.eop-nam10.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b7cd5ce-afbf-46e7-4693-08d9076145e0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2021 20:41:01.4464
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2NAM10HT231
Subject: Re: [PHP-DEV] [RFC] [Vote] Adding return types to internal methods
From: tysonandre775@hotmail.com (tyson andre)

Hi Marco Pivetta,=0A=
=0A=
> > In fact, if reflection were to switch to the actual runtime return type=
s of=0A=
> > those methods, I don't see a reason why downstream consumers would brea=
k=0A=
> > (stubbing tools, code generators, type checkers, dependency solvers, et=
c.)=0A=
> =0A=
> If the published library/application had to support older versions (e.g. =
php 7.4),=0A=
> but the tentative return types contained types/syntaxes that required php=
 8.0 =0A=
> (e.g. union types such as `string|false`, new types such as `mixed`/`neve=
r`, etc,)=0A=
> then the code generators and type checkers and stubbing tools would need =
to be =0A=
> updated to exclude the new tentative return types much earlier than absol=
utely needed.=0A=
> =0A=
> From experience, code generated with tooling while running on newer PHP v=
ersions is already incompatible with older PHP versions: you re-generate th=
e code when changing any of the dependencies anyway (think "no ABI compatib=
ility").=0A=
> =0A=
> This is at least true for all codegen tools I worked/contributed to/used =
on so far.=0A=
=0A=
Mocking libraries and static analyzers that don't result in published code =
were my largest concern, generated code that gets published was a smaller o=
ne.=0A=
=0A=
Changing getReturnType would significantly increase the scope of that incom=
patibility earlier on for users that don't install multiple php versions=0A=
(users/maintainers may default to whatever is provided by their package man=
ager for convenience)=0A=
=0A=
I'd rather have a larger time window with deprecations to change those and =
have any potentially breaking changes =0A=
(from the perspective of users of older versions of code generation tools, =
test libraries, static analyzers)=0A=
in 9.0 instead of 8.1, to put the (small) BC breaks in major releases where=
 possible.=0A=
=0A=
The introduction of many `mixed` tentative types which makes sense from a t=
ype system perspective,=0A=
but with your alternate proposal for changing getReturnType(),  =0A=
but would result in code generating tools generating a lot of `: mixed` ret=
urn types (requiring php 8.0+ runtime) in various interfaces and classes =
=0A=
which would be incompatible with a missing return type override due to http=
s://wiki.php.net/rfc/mixed_type_v2#explicit_returns=0A=
=0A=
> We're mostly breaking BC (new methods on reflection symbols, requiring sp=
ecial treatment) for stuff that is really an edge case that is only affecti=
ng tooling that would really work just fine even if the reflection API star=
ted to report the real return types now (no API change whatsoever).=0A=
> =0A=
> What's the plan for PHP 9 about these methods? Deprecation/removal? Or ar=
e we adding something that we'll have to drag on forever?=0A=
=0A=
The RFC proposal https://wiki.php.net/rfc/internal_method_return_types stat=
ed those plans.=0A=
=0A=
Unless new information comes up in the case of specific methods such as bre=
aking commonly used frameworks,=0A=
in almost all cases, I'd assume tentative types in php 8.x would become rea=
l types in the next major version (php 9.0).=0A=
=0A=
> Non-final internal method return types - when possible - are declared ten=
tatively in PHP 8.1,=0A=
> **and they will become enforced in PHP 9.0.** It means that in PHP 8.x ve=
rsions,=0A=
> a =93deprecated=94 notice is raised during inheritance checks when an int=
ernal method =0A=
> is overridden in a way that the return types are incompatible, =0A=
> **and PHP 9.0 will make these a fatal error.** A few examples:=0A=
=0A=
Tentative return types would also be used by PECLs, so the getTentativeRetu=
rnType would continue to be used forever.=0A=
(I'd expect PECLs would generally add tentative types in `n.x.y` and change=
 the real type in `(n+1).0.0`)=0A=
=0A=
The alternate design you've proposed of changing getReturnType seems to hav=
e issues=0A=
- For user-defined types (if we allow an annotation mentioning a tentative =
return type exists without indicating the type),=0A=
  it'd be possible for hasTenativeReturnType to be true but getReturnType t=
o be null, which is the opposite of internal classes=0A=
- As I'd mentioned before, if return type functionality gets extended to al=
so work on functions that already have return types (user-defined and/or in=
ternal),=0A=
  in which case php would need to add `ReflectionFunctionAbstract->getRealR=
eturnType`, but I'd rather keep the current semantics of `getReturnType`.=
=0A=
=0A=
I personally expect your alternate proposal to be more controversial due to=
 the larger potential bc break and barriers to upgrading in a minor release=
 rather than a major release, but may be mistaken.=0A=
=0A=
Thanks,=0A=
- Tyson=0A=