Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118697
Return-Path: <tim@bastelstu.be>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 87432 invoked from network); 28 Sep 2022 15:42:53 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 28 Sep 2022 15:42:53 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id D6C451804A9
	for <internals@lists.php.net>; Wed, 28 Sep 2022 08:42:52 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2
X-Spam-ASN: AS24940 176.9.0.0/16
X-Spam-Virus: No
X-Envelope-From: <tim@bastelstu.be>
Received: from chrono.xqk7.com (chrono.xqk7.com [176.9.45.72])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Wed, 28 Sep 2022 08:42:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bastelstu.be;
	s=mail20171119; t=1664379770;
	bh=dCtTSfKW4/hpBlrK+8rlRrdrGwoLak/0gjVQbEdFvI4=;
	h=Date:Subject:To:References:From:In-Reply-To:From;
	b=HG6CPztZvEiwWsy6y7s0Wf+VP3oFnbF5semAbh9IpHAf9SMtH6jDwEXmqv8B9nonu
	 86pw8S6RhcwNmOtHpa3CBlineswtWq2UvfCfgrFN1jQJXVj76ZDLxsWNC/ZYYtzEjA
	 8fqs8hj3h8Ri5cWV9ep4VrUNyoxEyOxU4X2V5PNXaz1vsb6X6us758Vm9jTa5+A312
	 70TQKCa0Mxch4cudo9WMkULlHYcAmNVR7c2G+0KfDC68RCvoahwksrqKD8B9tI6KBQ
	 eVXlcZdLiHm9KzLQK3gKcgpvURD3NSGq6eh/z0FMFaxBX8jg9Jt67Lw8qVH9uUqHFS
	 YCKdQSsjb53sA==
Message-ID: <d71e16d8-58e4-3d49-dd64-b77795545c0a@bastelstu.be>
Date: Wed, 28 Sep 2022 17:42:49 +0200
MIME-Version: 1.0
Content-Language: en-US
To: "Christoph M. Becker" <cmbecker69@gmx.de>,
 Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <530b3a9d-0ee4-6061-8c69-df672d238032@bastelstu.be>
 <628f27cd-d7f0-4a75-bf5b-f4812ff459a5@www.fastmail.com>
 <2474d6fc-a61d-19e8-b903-ff389dbb9ff6@bastelstu.be>
 <de7c9a48-6ffb-4b48-831b-00f1a24cd7af@www.fastmail.com>
 <e2d62544-2b2e-d67f-5452-187971a56068@bastelstu.be>
 <d27551ce-78da-49b1-8531-41c2d5e97036@www.fastmail.com>
 <76b3ab60-8865-a0aa-3949-f9276cd35149@bastelstu.be>
 <720bc406-78f1-4f4f-b0fa-00c6eb541523@app.fastmail.com>
 <5c02132b-59b7-81dc-bd9f-a9d9210f7721@gmx.de>
In-Reply-To: <5c02132b-59b7-81dc-bd9f-a9d9210f7721@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC [Discussion]: Improve unserialize() error handling
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 9/28/22 13:41, Christoph M. Becker wrote:
>> Predicting people's second-place choice is risky business.  This assumption seems logical on its face, but I'm sure there are people that will buck your expectations.
>>
>>> The reasoning is that unless “E_WARNING in 8.x without future decision” receives more than 50%, more than 50% prefer an Exception no later than 9.0. Unless “UnserializationFailedException in 8.x” receives more than 50%, more than 50% prefer no Exception in 8.x.
>>
>> If you want to go that route, I'd go all the way to an RCV vote and be done with it.  Or else just make an executive decision as the RFC author and let the chips fall where they may.
> 
> I'm generally not too happy with secondary votes.  Sometimes you only
> support the primary vote for certain secondary options; to "be sure"
> that another secondary option won't "win", you'd need to vote "no" on
> the primary choice.
> 
> I'd prefer a single vote with pre-selected details.  I don't have any
> particular preference in this case, though.
> 

Would the increase of E_NOTICE to E_WARNING for the two cases that 
currently emit E_NOTICE be something that even requires a vote or is 
this something that can simply be decided by merging a PR? [1] In that 
case the second and third vote could be simplified to "Convert E_* to 
Exception" with the regular 2/3 majority required.

[1] I would hope that unifying E_NOTICE/E_WARNING to E_WARNING 
everywhere is uncontroversial.

Best regards
Tim Düsterhus