Re: [RFC] [VOTE] Make constructors and destructors return void

*just let me know if that is a minor change and I'm okay with updating the RFC right now. Best regards, Benas Seliuginas On Fri, Jul 3, 2020, 6:20 PM Benas IML <benas.molis.iml@gmail.com> wrote: > Hey Zeev, > > For me it doesn't really matter if we enforce void rules > implicitly in > PHP 8.1 or PHP 9.0. Just that we do at some point. > > Thus, I'm okay with closing the secondary vote and updating the RFC to > mention only PHP 9.0 (and not PHP 8.1). > > Best regards, > Benas Seliuginas > > On Fri, Jul 3, 2020, 6:05 PM Zeev Suraski <zeev@zend.com> wrote: > >> >> > On 3 Jul 2020, at 13:27, Nikita Popov <nikita.ppv@gmail.com> wrote: >> > >> > Now, whether this RFC actually makes a sufficient case to disregard >> policy >> > here is a different question, and at the discretion of the voters. >> >> I think this is key here (the first part, not the second). >> >> It doesn’t seem as if the RFC makes any case at all why it urgent to >> enforce this compatibility break outside of the standard policy. In fact, >> unless I’m missing something, it doesn’t attempt to tackle that question at >> all, and portrays it as a simple choice between two equal options that are >> up to personal preference. That is not the case - our standard policy is >> an outward facing contract, which we should be very wary of breaking - and >> at the very least do while taking a very informed, measured decision. >> >> We can not assume that all voters fully understand the implications of >> breaking the policy, or even that this would be breaking policy at all, >> given that it’s not even mentioned in the RFC. >> >> As such, I do think the current state of the RFC is somewhat problematic, >> and to actually consider introducing it into 8.1, the RFC requires 3 >> amendments: >> >> 1. State that per policy, if the RFC is passed - it would generally go >> into PHP 9.0. >> 2. Make the case of why the RFC author believes it’s important to do it >> in 8.1 and not wait for 9.0 per our public-facing policy. >> 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, >> despite our compatibility policy”, and turn it into a clear Yes/No question >> that clearly requires a 2/3 majority. Since technically it might be an >> issue, perhaps we can stick with the current wording, but still make it >> clear that for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. >> >> I think those are fairly minor amendments that can be done without >> restarting the vote, given where it’s at. >> >> Zeev > >