Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123680
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-522-ga39cca1d5-fm-20240610.002-ga39cca1d
Precedence: bulk
MIME-Version: 1.0
Message-ID: <673a1803-83c4-44b4-bd73-4ba61e83412e@app.fastmail.com>
In-Reply-To: 
 <9d28c9tOCChpWUcP1SFiFwtf2-w2XAtDzHsmM73myA7zfBsn7TxxEqs-VCnxRAgZjsk2TxS55owmM8wSLgBQL8LgeQLntUQ9toeLMkjTVx4=@gpb.moe>
References: 
 <CAPzBOBMidokE3xw251f+_qbCPAyQQRcN1WnyVF0xfuzaPBU3JA@mail.gmail.com>
 <9d28c9tOCChpWUcP1SFiFwtf2-w2XAtDzHsmM73myA7zfBsn7TxxEqs-VCnxRAgZjsk2TxS55owmM8wSLgBQL8LgeQLntUQ9toeLMkjTVx4=@gpb.moe>
Date: Wed, 19 Jun 2024 10:34:59 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jun 19, 2024, at 10:07 AM, Gina P. Banyard wrote:
> On Tuesday, 18 June 2024 at 17:37, Robert Landers 
> <landers.robert@gmail.com> wrote:
>
>> Hello internals,
>> 
>> [...]
>> 
>> What are your thoughts?
>
> As self-proclaimed leading expert on PHP type juggling.
> That it is a terrible idea with no gains whatsoever.
> Renaming the declare statement does not improve the situation.
>
>> PS. Personally, I would rather unify non-strict and strict in some way
>> that makes sense ... so, that route sounds nice too.
>
> See my old meta RFC: https://github.com/Girgias/unify-typing-modes-rfc
>
> It is a somewhat known hot take from mine that I think the strict_type 
> declare statement was a mistake. [1]
> Mainly because it affects barely nothing in regard to the engine.
>
> I have written/co-authored multiple RFCs over the years to make the 
> default coercion mode less whack. [2][3][4][5][6][7]
> And my container/offset RFC is in the same vein [8] which lead me into 
> a different rabbit hole then the one I was expecting to explore which 
> is addressing PHP's weird comparison semantics. [9]
>
> Therefore, I would rather we focus on *actually* fixing PHP's 
> semantics, than arguing about changing the name of something that 
> shouldn't really exist in the first place.
>
>
> Best regards,
>
> Gina P. Banyard
>
>
> [1] Slide 68 of my PHP UK talk "PHP's Type System Dissected": 
> https://gpb.moe/doc/slides/PHP_Type_System_Talk_PHPUK2023.pdf
> [2] https://wiki.php.net/rfc/saner-numeric-strings
> [3] https://wiki.php.net/rfc/implicit-float-int-deprecate
> [4] https://wiki.php.net/rfc/saner-inc-dec-operators
> [5] https://wiki.php.net/rfc/locale_independent_float_to_string
> [6] https://wiki.php.net/rfc/exit-as-function
> [7] https://wiki.php.net/rfc/deprecate-boolean-string-coercion
> [8] 
> https://github.com/Girgias/php-rfcs/blob/master/container-offset-behaviour.md
> [9] 
> https://github.com/Girgias/php-rfcs/blob/master/comparison-equality-semantics.md

What Gina said.  Renaming the declare key would involve changing *literally millions* of files, even if it's over the course of a decade, for little if any benefit.

Reducing the delta between weak mode and strict mode to the point that it makes little difference (by making the PHP type juggling system less nonsensical and random) is a much more achievable goal, and actually has value to justify the effort (both for Internals and for people updating their code).

Also, as someone who does put every file into strict mode as a matter of course, and appreciates the many languages that do not even have a concept of non-strict mode (like Go or Rust), I really don't appreciate the backhanded comments in this thread about people who, you know, care about type safety.  (Something that weak mode, when it was introduced in PHP 7, only marginally provided if at all.)  Strict mode prevents bugs, full stop, and we should not fault anyone for applying that bug-stopper tool liberally.

--Larry Garfield