out, it would allow:
$output = (?int)$input ?? $default;
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e ?? $default.
Equally I see a lot of use in the following to nullify unexpected inputs
such as if $_GET['something'] was an array:
$input = (?string)$_GET['input'] ?? '';
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hen prints `int(1)`
In the absense of a nullable modifier, that makes so little sense that
it definitely needs to throw a TypeError IMO.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ll
I don't think it would go down very well to have non-nullable casts
throwing TypeErrors for common cases, without an elegant
could-not-convert fallback that doesn't require a 5 line try-catch block.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
tems');
}
$value = (?string)$_GET['name'] ?? '';
if ($value === '') {
// also, ?name[]= can sod off
throw new Exception('You must provide a name');
}
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on
and returns null. Otherwise moves on to next option and casts it to an
integer.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
of whether it
passes or fails, you should both be holding your heads high that you've
made the effort.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ll replace it as the recommended
inbuilt method that handles strings with whitespace and trailing junk?
Will there be one?
I'm aware that the most common IDEs suggest using (int) instead of intval.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
$obj;
}
throw new InvalidArgumentException('Cast expected ' . T);
}
$x = cast($obj);
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 23/04/2019 14:39, Mark Randall wrote:
It keeps coming back to the feature we've all been praying to the PHP
Gods for... generics.
Replying to myself (sorry).
I just wanted to point out that the same syntax would also solve your
other issue from the nullable casts thread:
function
t holds no weight with me.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ary of would be if you were
computer-generating code, as it would not pick up literals.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s *significant*.
Until someone can convince me otherwise, I will continue to strongly
believe that foreseeable future (years).
I'm half tempted to RFC it so it can go to a vote.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eir entire
codebase against each one. But we all know that's not how the real world
works.
For all those reasons, I am in favour of your proposal to fail-safe with
a compiler error.
(Also: Did I miss a vote option which would have made short_open_tags
always on?)
--
Mark Randall
--
PHP
rd
his proposals as an RFC with all due haste, as it's quite clear the
current plan cannot go forward as-is.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
#x27;, MyObject::class ];
}
}
Eh, my suggestion is probably a terrible ideal.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tion errors.
4. Leave the existing functions as-is, finally claim the \php namespace,
alias all of the internal functions into it, and make their default,
unchangeable behaviour be to throw a RuntimeException on error.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To uns
gt; null;
I know this is a huge tangent, I just wanted to throw it out there as a
possible option for handling chaining, that would potentially kill many
more birds down the road in the process.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eing able to tell the difference would have at least some
useful applications.
Clearly there's ways around that using the current, more verbose method,
but it would be nice if a way could be found so that this potential
ambiguity wasn't there in the first place if this new mechani
0;
$y = 1;
$closure = function() use (...) {
};
Where "use (...)" would auto-capture all of the used variables in a
similar manner to short closures, that would certainly save a bit of time.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
IMHO would provide best-of-both-worlds.
The benefits of public key vs a symmetric key are that the logs remain
secure even with read access to php.ini.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
}
return -1;
};
$x and $y would be captured, $z would not be. I believe this is how
short closures are implemented, but is at present only supporting a
single line.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ke descriptions or unions with different requirements for each type.
Well-docblock'd stubs, C definitions, documentation pages etc would then
be the drawn from the JSON rather than the other way.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
r the web?
function x(utf8_string $x): utf8_string { ... }
These are all just questions I have no answer to or firm opinion on, but
I would be interested to know people's general ideas as to solutions.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 20/06/2019 22:19, Rowan Collins wrote:
On 20/06/2019 16:36, Mark Randall wrote:
"Hello".substr(1) // would work as expected regardless of encoding
As I always point out when "multi-byte support" or "Unicode support" is
discussed, it's often ambiguous j
stretching the bounds of reasonableness too far
to suggest the creation of a dedicated page on php.net that contains a
description, a link to csfixer etc, and then that link be included in
the depreciation message itself.
--
Mark Randall
On 23/07/2019 18:54, G. P. B. wrote:
Hello intern
leaky code.
If short tags are to be removed, V2 is a significantly more reasonable
way of going about it.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 23/07/2019 10:00, Derick Rethans wrote:
DOs:
- Test test test test
- Tell your friends and collegues to test with their apps and projects
- Oh yeah: test!
Derick, congratulations on your RM role, however, for your personal
well-being, I feel obliged to ask if you have recently experienced a
X.
Certainly not a catch-all situation, but might present an opportunity
for doing some of the leg work automatically.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
cal directories. Sounds like a
job for composer tbh so userland workload would be limited for projects
using modern workflows.
This would of course be dependent on if the compiler stage has the
ability to branch off and call an autoloader the first time it
encounters the import_declares.
Ju
isn't it about time that an spl_autoload_list was
added that accepted the standard composer classmap [class_id => path]
and forewent most autoload callbacks entirely?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
IMHO short tag removal has one major thing going for it, consistency,
and by extension, predictability.
That's it.
Is that enough? I'm on the fence.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
iously
omitted), would treat code which was previously explicitly specified as
valid, as no longer valid, and would expose it to the world.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s obviously a big challenge for the internals team and
its contributors to create coexistent systems with versioning, but I
would simply offer the following:
If you're not going forward, you're falling behind, and sometimes going
forward requires sacrifice.
Mark Randall
--
PHP Int
ability to rip out
everything which wasn't kept would no doubt simplify a lot of things,
but I agree with Nikita's point that it only kicks things down the line
until the next break.
I think side-by-side engine versions are likely going to be the end
result if it's poss
ntion.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 09/08/2019 08:15, Zeev Suraski wrote:
You seem to believe that C++ is inherently superior to C. And it's
entirely within your right.
However, there are projects - to this date - that prefer C to C++ for a
variety of reasons. PHP is one of them, and others include the Linux
kernel, redis, ngi
just moving the version definition to a tag
instead of a declare, and having a "Anything and everything new" version.
Is there a major difference I'm not immediately seeing?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
patibility 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
On 10/08/2019 11:56, Nikita Popov wrote:
Hi,
Lack of type information for internal functions in Reflection is a
long-standing issue. In PHP 8 we finally have all the necessary technical
groundwork done to support argument and return type annotations on internal
functions at scale.
Question - I
st of backwards compatibility. Prioritizing backwards
compatibility did not receive a strong response.
I seem to remember listening to Nikita on Derick's podcast a while ago
where he made comment on his observation that newer generation
programmers were looking for improved typing and strictne
asic comments?
One thing I did see in the GD library with _php_image_create_from is
that ZPP is different depending on logical expressions, rather than
pre-processor statements. How should these be handled?
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsu
o
package and may depend on that package definition to control its
behaviour (especially if it gets loaded up with declares or editions).
I'll simply be replacing my ubiquitous strict-types declare with
whatever was used to reference this package.
Mark Randall
--
PHP Internals - PHP
not use an autoloader, the
__nsmeta.php would need to be loaded first, this is something that
PHP7.4 autoloaders would need to take into consideration.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
my own packages which
deal with wrapping up css / js / html template files.
Perfect for runtime, not so good for compile time, but if I'm wrong I
dare say someone will let me know.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
l the autoloader internally but it would require userland
loaders to be upgraded with it, not exactly a huge stretch, especially
with most things being composer-based, but a dummy class would make it
work out the box, including optimization steps like dumping the class list.
Mark Randall
--
rm game plan for PHP, and build a consensus
on things such as strict typing, overloading in the core functions, and
perhaps most divisively, if "cleaning up the language" is in itself a
viable justification for backwards compatibility breaks, and if so, what
weight it should carr
knowing that "PHP" has agreed to weigh certain general concepts in a
particular way.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
h_dump(
fn() => func_to_test("hello"),
fn() => func_to_test(1234),
fn() => func_to_test(false)
);
I am however, unsure where this script should be placed in the codebase.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
not as focused on the
quality of their code as we (and their customers) would perhaps like
them to be.
For everyone else, it's one more tool to help make us aware of problems,
and prevent those problems from propagating along the stack and
effecting other things.
Bring it on.
--
w would it?
Besides, we have tools available for years now to make this behaviour
more defined:
$counts[$key] = ($counts[$key] ?? 0) + 1;
"If $counts[$key] is not set, use the value 0".
Null Coalescing was explicitly designed to provide for this behaviour.
--
Mark Randall
--
PHP Int
comes.
Don't build your business on a foundation of eggshells and then complain
when something comes along that makes those eggshells crumble.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
features that could help us to build
new features".
The manager says: "Lay this out to me"
You reply:
"It's like our company car still works, but it no longer tighter meets
emissions standards so they won't let us take it into the city any more"
"Crap"
g at the code.
To use the analogy someone posted elsewhere... the training wheels are
coming off. Time to be responsible and type those few extra characters
to be clear on your intent.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
every single sub-branch individually to get the
final word.
Something I am finding hard on Github, and maybe it's just because I
haven't found the option yet, is finding new posts.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
On 05/09/2019 22:45, Benjamin Morel wrote:
. One
thing that could be checked, is whether their API allows retrieving the
whole discussion history programmatically. If so, one could setup a
database to sync all messages to on a regular basis, so that the PHP
project could move the discussions back
Registration recommended by participants of 11
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
u want a per-file opt out, the notion of
declare(sloppy=1);
Has already been jokingly proposed, and I would personally have no
problem with it if people want to opt-in to less reliable enforcement...
but once again, I stress that the defaults should always be best-practices.
--
Mark Randal
e can probably find a way around it, at least
when running containerised.
Are you referring to installing shared libraries on the host?
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
BC break due to requiring bitwise mask comparison in existing
handlers.
Either way, this this would allow easily differentiating engine warnings
that will become more prominent in this RFC, with those contained in
PHP_FUNCTION scope.
--
Mark Randall
--
PHP Internals - PHP Runtime Development
haviour in light
of the existing internals guidelines regarding considerate posting, and
they may find themselves prevented from continuing those actions.
Something I think most people would consider entirely reasonable.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To u
itor
Avoid the XML parsing code. It's pure cancer.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ght of the existence of
better described and more well-known functions exhibiting identical
behaviour.
This RFC only covers the issuing a deprecation notice, and its complete
removal would be contained within a separate RFC.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To u
just having
identical behaviour, the compiler actually transforms the AST into a
userland function call to the named shell_exec function as per
zend_compile_shell_exec.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RFC states, there are already widely used tools available which
can do this reliably:
https://github.com/FriendsOfPHP/PHP-CS-Fixer
backtick_to_shell_exec
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
applies to most things, not just PHP.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tual topic of
the RFC, rather than trying to shift the conversation towards who can
and cannot propose RFCs :-)
If you want to discuss changing the RFC mechanics and who is entitled to
make them, please make your own RFC.
Thank you.
Mark Randall
--
PHP Internals - PHP Runtime Development Maili
leaves us with the choice that's within our power, deprecation and
eventual removal of backticks in favour of something that's much more
obvious in its intent and much less easy to miss.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nd poorly understood syntax, and people should
at some point in the next 4 or 5 migrate to the much more obvious
shell_exec.
By writing the RFC, it's pretty obvious which one I think is the best
and most realistic course of action.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 10/10/2019 23:04, Walter Parker wrote:
If this truly is the problem that you say it is, there should be plenty of
documentation online as to the issues that it has cause. Maybe you could
post some of the better cases (as the the responsibility of the person
suggesting the change to provide evi
owableForSureThisTime $ex) {
}
^^ Compiler Error.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11/10/2019 11:25, Nikita Popov wrote:
Purely syntactical deprecations, such as the recently discussed case of
backticks, but also the already accepted deprecations of the "alternative
array access syntax" and the (real) cast, can be performed automatically
and with perfect reliability.
I ima
On 16/10/2019 02:46, David Rodrigues wrote:
Hello. I like to suggests a discussion about a FR to make possible to
inline switch, as an alternative to nested inline conditionals.
```
http://www.php.net/unsub.php
e to add a
token that would effectively no-op in all circumstances.
It sounds like a job for a static analysis comment:
/** @DisableSwitchStatementFallthroughWarning */
switch ($x) {
case 1:
$x = doSomething();
case 2:
doLaLaLaLa();
break;
default:
doTralala();
}
--
Ma
l fopen('missing.txt', 'r'),
FileException => null;
if ($x === null) {
die('File could not be opened.');
}
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
is to
be found.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
think easy cognition has likely gone out the window.
There are plenty of much more expressive ways of doing this without
introducing new syntax IMHO.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 27/10/2019 02:12, Mike Schinkel wrote:
Hello all:
And for everyone:>
What do you think of this as a potential future for PHP?
I had received the impression that a lot of the problems for performance
optimizations relate to how PHP can shift things around at runtime,
where identical code a
been accidentally sitting in an outbox for
a bit too long and has just sent, but the vote has been underway for a
while now.
It currently has more than 90% in favour with good turnout.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
the PHP Internals News podcast.
Mark Randall
marand...@php.net
https://wiki.php.net/rfc/deprecate-backtick-operator-v2 is now open for voting.
This is a standard yes / no vote, requiring a 2/3 majority to pass.
The vote will run for 2 weeks and will close on 2019-11-15.
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 31/10/2019 17:01, Mark Randall wrote:
https://wiki.php.net/rfc/deprecate-backtick-operator-v2 is now open for voting.
This vote has closed with 11 in favour and 26 against.
Backticks will therefore be left unaltered.
Thank you to everyone that voted.
Mark Randall
marand...@php.net
of
function / constant / anything-but-class level autoloading, things might
as well be in a readily available location.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hen PHP8 lands.
+1 from me.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t was a warning now, it
would end up a compile error a few years from now.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'd much rather have something like:
declare(ambiguous_element_lookup=0)
declare(ambiguous_element_lookup=off)
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
on
would be to simply remove support for them entirely in favour of static
methods, and at that point the door is open to make functions and
constants be global-only.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
or cannot exist
in a reasonably performant way? Doesn't seem so except for a readonly
property.
If not, leave it to userland.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, and there is an exactly zero percent
chance of it being removed at any point in the next 50 years.
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, thus get_debug_type will return
"int" rather than "integer" etc.
https://wiki.php.net/rfc/get_debug_type
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ade that a supermajority may exist in
a straight up or down vote rather than a 3-way
(https://wiki.php.net/rfc/engine_warnings).
So on one hand, consistency is good.
On the other hand, being consistently bad is still being bad.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Developme
verloading operators on
objects that don't have the relevant method available should trigger an
Error.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 16/02/2020 10:16, Mike Schinkel wrote:
Why "debug" type?
I would imagine because it is only really useful in the context of
debugging. There is no reason to ever expose such information to userland.
The name is up for debate.
--
Mark Randall
marand...@php.net
--
PHP Inter
eaning
towards a general "No".
What I can't express on this strawpoll though, is that I would
unequivocally vote against "any function or method call" in all
circumstances.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
T
On 17/02/2020 08:42, Nikita Popov wrote:
Can you please add some examples for the behavior? Preferably the precise
output for all primitive types, for classes and for anonymous classes.
Added to RFC
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.n
de /
migration tool would be rather well-received, an easy mechanism to scan
a file / directory for standard extension functions with known reference
args and re-write them appropriately.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 15/02/2020 14:32, Mark Randall wrote:
Greetings,
https://wiki.php.net/rfc/get_debug_type
Just a heads up that I will be putting this to the vote tomorrow.
As this seems fairly uncontroversial, and in the absence of any
well-supported suggestions, the vote will be on adding this as
Greetings,
I have opened voting on the get_debug_type RFC:
https://wiki.php.net/rfc/get_debug_type
Voting will run for 2 weeks and will close 2020-03-16.
--
Mark Randall
marand...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
On 02/03/2020 14:08, Rowan Tommins wrote:
The problem with this kind of behaviour change is that there's no way
for PHP to know whether a particular piece of code has been changed to
expect the new behaviour or not
Lump it in with editions maybe?
--
PHP Internals - PHP Runtime Development Mai
1 - 100 of 237 matches
Mail list logo
