Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112399
MIME-Version: 1.0
References: <da80062f-2aa8-f769-969a-5b333640cc21@cubiclesoft.com>
In-Reply-To: <da80062f-2aa8-f769-969a-5b333640cc21@cubiclesoft.com>
Date: Thu, 3 Dec 2020 14:24:46 +0000
Message-ID: <CAFPFaMLAduLMWafsDc7rKXhcrK8e4+wqH+TUBuZYCOhd0qyFWw@mail.gmail.com>
To: Thomas Hruska <thruska@cubiclesoft.com>
Cc: PHP Development <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000dcaa5b05b5901f83"
Subject: Re: [PHP-DEV] PHP 8 incompatible change documentation issues
From: george.banyard@gmail.com ("G. P. B.")

--000000000000dcaa5b05b5901f83
Content-Type: text/plain; charset="UTF-8"

 Please use the documentation list to talk about documentation issues
and not the internal list.

On Thu, 3 Dec 2020 at 14:18, Thomas Hruska <thruska@cubiclesoft.com> wrote:

> https://www.php.net/manual/en/migration80.incompatible.php
>
> Under the "String to Number Comparison" section of the migration guide,
> there's no mention of explicit casts being unaffected.  Using an
> explicit cast should be the general recommendation anyway.  That is,
> anyone doing this:
>
> 42 == "42foo"
>
> Should be doing an explicit cast before the comparison:
>
> 42 == (int)"42foo"
>
> So as to avoid the issue altogether.
>
>
>
> "match is now a reserved keyword."
>
> No mention of variables named $match.  Assigning the result of
> preg_match() to a variable named $match is pretty common.  Linking
> "reserved keyword" to the page with the list of reserved keywords and/or
> reminding the reader that variables named $match are unaffected would be
> helpful.
>

PRs are welcome on https://github.com/php/doc-en/pulls


> "The needle argument for strpos(), strrpos(), stripos(), strripos(),
> strstr(), stristr() and strrchr() can now be empty."
>
> I fail to see how this change is useful/correct.  In my experience,
> passing in an empty string for the needle to any of those functions has
> always been part of a more critical application bug.
>

The point is about consistency with all these sort of functions from various
extensions (mbstring, intl, iconv).
Moreover, this has nothing to do with the docs, and cannot be changed at
this point in time.


> I'm also not sure why this is in the "Incompatible Changes" page of the
> migration documentation.
>

Because it is incompatible with code which expects these cases to return
false.


> --
> Thomas Hruska
> CubicleSoft President
>
> CubicleSoft has over 80 original open source projects and counting.
> Plus a couple of commercial/retail products.
>
> What software are you looking to build?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>


George P. Banyard

--000000000000dcaa5b05b5901f83--