Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106082 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 84205 invoked from network); 27 Jun 2019 12:11:44 -0000 Received: from unknown (HELO lb2-smtp-cloud8.xs4all.net) (194.109.24.25) by pb1.pair.com with SMTP; 27 Jun 2019 12:11:44 -0000 Received: from [IPv6:2001:983:6fc5:1:65e8:669:5cd7:f637] ([IPv6:2001:983:6fc5:1:65e8:669:5cd7:f637]) by smtp-cloud8.xs4all.net with ESMTPA id gQhWhEQFY7KeZgQhYhnTiP; Thu, 27 Jun 2019 11:28:20 +0200 To: Arnold Daniels , PHP Internals References: <2c0a414b-859d-3c25-d92a-048c1b8b259f@xs4all.nl> Message-ID: <48f15247-79e1-7902-41f7-91e0ae3211c5@xs4all.nl> Date: Thu, 27 Jun 2019 11:28:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLNMexzPG57mZQKHcgJaGSo1Qk8Bs4DX/ZR7vZeSHkJbaC+T3LDb2QlXxpCVc8teyi+Rj2rrcGo1mQ+ZAsW+6YhL8yQB+QUt/b3lIVwUeKUR6+gT8wgz ZjtAPWf0vu/GKlLwyza/zaVxavvjPPkeuHWKNdLZQmjUeiK9hfx2Y4/akGimGLeKtz4sjnb4+rGZiLlWT5c4IywQUkcVTzlyw9p6IYvsyyDD5L0v1ksNYaou gWdYkVEfd0llNdmkwjIjcEQD2t2H5Jv0ZnL8vQBqKioDCOp0AE567qND3BNfJOcCIs1gSSUeSaLCq+QUWgT7Sw== Subject: Re: [PHP-DEV] [RFC] Strict operators directive From: d.takken@xs4all.nl (Dik Takken) On 26-06-19 23:22, Arnold Daniels wrote: > > I would argue the following; The explicit use of the strict_operator is > intentional, meaning that the author consciously chose to be strict and > does not expect some operators to still be non-strict. The issues pointed > out, apply to all comparison operators. Ignoring == and != in the RFC > creates an inconsistency, while not properly addressing those concerns. Yes, I guess you're right about treating all operators in a strict way with a simpler set of rules is more consistent. Concerning the issue with copying existing code into a file that uses stricter interpretation of the code: I think this should be regarded as performing an upgrade of the code that is being copied. No problem in my view. In the section about widening the scope you address the type juggling that happens on array access, like $array[12.34]. One could argue that accessing an array item by key is implicit use of the == operator, just like a switch statement is. I would love to see it included in the main proposal in stead of proposing it as part of a different directive. The change in behavior could be similar to what is proposed for the switch statement: Array keys are compared using the === operator. Regards, Dik Takken