On 09/08/2019 22:02, Sara Golemon wrote:
2. Strict(er) typing - I'm not sure, on the surface, what future expansions
we'd plan for in this area which couldn't fit into standard PHP in a non
BC-breaking way.
Union types and general reflection do spring to mind on this. I assume
any APIs using them would need to return more complex objects describing
them, rather than individual strings from getType().
Typed arrays are also another one which has been in high demand that I
imagine will present some BC issues if shared between stricter and
less-strict code.
From what else I have read on here, the real biggy is probably going to
be generics (hallowed by thy name).
3. Failing closed. Things like strpos() being able to return int(0) which
is a falsey value. This has been a long standing "complaint" about PHP
which isn't actually "fixable" without a big BC fail. We've already shown
we're willing to bite this bullet for security issues
(openssl_random_bytes).
strpos returning 0 for the start makes perfect sense to me, what doesn't
make sense is returning false. I think these problems need to be
murdered-to-death with scalar objects (ideally returning -1 or, at a
push, null, because at least the return type could be expressed as ?int,
but IMO -1 is far superior).
I think scalar would be a huge game changer for allowing more sensible
function names / return types without completely killing backwards
compatibility on the existing core functions.
The entire argument order issue could potentially be wrote off with SON.
My guess is that whatever happens, it's going to require one version
that really brings the pain, to set the groundwork for the future.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
