Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110840
To: Benas IML <benas.molis.iml@gmail.com>, PHP Internals List
	<internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return
 void
Thread-Index: AQHWULV7dKXBUq42GUWHL4FwYaiwzaj2EvbB
Date: Fri, 3 Jul 2020 16:52:02 +0000
Message-ID:
 <BYAPR05MB6535288425CB5EB8593AE9ADDE6A0@BYAPR05MB6535.namprd05.prod.outlook.com>
References:
 <CANeKSiRe95yUeyUV5S3MU1Bzh7A_Z0OQF_WVNFK16CcbE5wYqw@mail.gmail.com>
In-Reply-To:
 <CANeKSiRe95yUeyUV5S3MU1Bzh7A_Z0OQF_WVNFK16CcbE5wYqw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [6x3fB9G3BmhoqUFXCVi3SWKVeILRvz6o]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: d0a62eae-5dc9-4020-09c6-08d81f7168d1
x-ms-traffictypediagnostic: SN1NAM04HT052:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info:
 F17CRTiSP5lEYUfo5kccI7w4DsVSPsJKFTcTd4i5OkBngUFVwBS2UWn+SkSluJNtI9aTwFrb4u2yOm2gHQ9OPmXYZJIG+m8rp38aRAiLa+BezcSx6DtT6wtZ5mS6hGGWZYm+1o3QbyiuSHV06jjSJdQFvaIVrZU6YKJI7Kk6Xa8crHdV0fqkhrObFBpSLE76a/qah92PdBWgzDvo0FYkyJ+6ldKLSeGeC4Y2Jr2nHYrtlEQY7i7kUuUaSwxvPBUT
x-forefront-antispam-report:
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR05MB6535.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901;
x-ms-exchange-antispam-messagedata:
 ilJM0vK+/PsU678t6PZe29ifHKA7YHTRAs+pwQGhH0pRRlwLJiaRxp8rchdbxXB97cY8EAPFnmKfjFBnVek9ZBaBeZm84FosyAhn3JyCKB4FON6dWj6tObB+GFqzJaVrSfa1qjbmMweTY7MJJCCYeA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: SN1NAM04FT048.eop-NAM04.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: d0a62eae-5dc9-4020-09c6-08d81f7168d1
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2020 16:52:02.2121
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT052
Subject: Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return
 void
From: theodorejb@outlook.com (Theodore Brown)

On Thu, July 2, 2020 at 4:12 PM Benas IML <benas.molis.iml@gmail.com> wrote=
:=0A=
=0A=
> I have opened the voting for the RFC, let's hope everything is going=0A=
> to be smooth :). If you have any other questions, let me know!=0A=
> =0A=
> RFC: https://wiki.php.net/rfc/make_ctor_ret_void=0A=
=0A=
Hi Benas,=0A=
=0A=
Thanks for your work on this. I'm in favor of deprecating the ability=0A=
to return values from constructors and destructors to align their=0A=
behavior with the documentation and how most other languages work.=0A=
=0A=
Unfortunately, the RFC doesn't provide an option to vote just for=0A=
this. Instead it only offers combining the deprecation with a new=0A=
option for developers to choose whether constructors and destructors=0A=
are explicitly typed as void.=0A=
=0A=
But what will be the benefit of typing constructors/destructors as=0A=
void when this is the only allowed type, and after the deprecation=0A=
adding the type won't change anything anyway? It will lead to a=0A=
situation where some projects require the explicit type, others=0A=
require not having an explicit type, and the rest have a mishmash of=0A=
the two. This will lead to further bikeshedding in projects and=0A=
unnecessary code changes.=0A=
=0A=
Allowing an explicit void type on constructors is also at variance=0A=
with other languages. For example, TypeScript does not allow=0A=
constructor return type declarations. [1] Nor does C# [2], nor does=0A=
Java. [3] Likewise, C++ constructors do not allow an explicit return=0A=
type [4], nor do initializers in Swift [5] and Kotlin [6].=0A=
=0A=
For these two reasons, I voted no on this RFC. I think it would be=0A=
fine to deprecate the ability to return values from constructors/=0A=
destructors, though, and this could happen in PHP 8.1 if there isn't=0A=
time for it to land in PHP 8.0.=0A=
=0A=
Best regards,  =0A=
Theodore=0A=
=0A=
[1]: https://www.typescriptlang.org/play/?target=3D7&module=3D5#code/MYGwhg=
zhAEBiD29oG8BQ0PWPAdhALgE4Cuw+8hAFAJQBc0AbvAJYAmK6mAvqj0A=0A=
[2]: https://www.c-sharpcorner.com/article/different-types-of-constructor-i=
n-c-sharp/=0A=
[3]: https://docs.oracle.com/javase/tutorial/java/javaOO/constructors.html=
=0A=
[4]: https://docs.microsoft.com/en-us/cpp/cpp/constructors-cpp?view=3Dvs-20=
19=0A=
[5]: https://docs.swift.org/swift-book/LanguageGuide/Initialization.html=0A=
[6]: https://kotlinlang.org/docs/reference/classes.html#constructors=0A=