Hey Theodore, On Fri, 3 Jul 2020 at 19:52, Theodore Brown <theodor...@outlook.com> wrote: > > On Thu, July 2, 2020 at 4:12 PM Benas IML <benas.molis....@gmail.com> wrote: > > > I have opened the voting for the RFC, let's hope everything is going > > to be smooth :). If you have any other questions, let me know! > > > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Hi Benas, > > Thanks for your work on this. I'm in favor of deprecating the ability > to return values from constructors and destructors to align their > behavior with the documentation and how most other languages work. > > Unfortunately, the RFC doesn't provide an option to vote just for > this. Instead it only offers combining the deprecation with a new
Quite honestly, this would also question why the "Ensure correct magic methods' signature" RFC was introduced in the first place since it also limited some magic methods to only having a single type (if declared) i. e. `__toString()` might only have `string` return type. > option for developers to choose whether constructors and destructors > are explicitly typed as void. > > But what will be the benefit of typing constructors/destructors as > void when this is the only allowed type, and after the deprecation > adding the type won't change anything anyway? It will lead to a > situation where some projects require the explicit type, others > require not having an explicit type, Same with the `void` return type in general. If you go onto GitHub, some projects have an explicit `: void`, others not. Every single feature is used by some group of people and isn't used by another. This is again, a rather subjective thing. ...and for more arguments, please read Larry's, Rowan's and my replies on the original discussion thread since I did go into mor edetail on this matter. > and the rest have a mishmash of > the two. This will lead to further bikeshedding in projects and > unnecessary code changes. If this was the case, we would also see a ton of tabs and spaces' mixed together in projects but we don't. > Allowing an explicit void type on constructors is also at variance > with other languages. For example, TypeScript does not allow > constructor return type declarations. [1] Nor does C# [2], nor does > Java. [3] Likewise, C++ constructors do not allow an explicit return > type [4], nor do initializers in Swift [5] and Kotlin [6]. ...and also please call constructors/destructors directly in any of those languages like you can in PHP. I. e. `$object->__construct()` and `$object->__destruct()`. Unlike in any of those languages, constructors also don't look or behave like constructors in PHP so comparing those languages with PHP doesn't make a whole lot of sense. > For these two reasons, I voted no on this RFC. I think it would be > fine to deprecate the ability to return values from constructors/ > destructors, though, and this could happen in PHP 8.1 if there isn't > time for it to land in PHP 8.0. > > Best regards, > Theodore > > [1]: > https://www.typescriptlang.org/play/?target=7&module=5#code/MYGwhgzhAEBiD29oG8BQ0PWPAdhALgE4Cuw+8hAFAJQBc0AbvAJYAmK6mAvqj0A > [2]: > https://www.c-sharpcorner.com/article/different-types-of-constructor-in-c-sharp/ > [3]: https://docs.oracle.com/javase/tutorial/java/javaOO/constructors.html > [4]: https://docs.microsoft.com/en-us/cpp/cpp/constructors-cpp?view=vs-2019 > [5]: https://docs.swift.org/swift-book/LanguageGuide/Initialization.html > [6]: https://kotlinlang.org/docs/reference/classes.html#constructors Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
