7;s "quirks" &
"limited-quirks", JS's "use strict" - but it doesn't scale, so it's
never going to replace the genuinely hard question of how to improve a
language for new code, while limiting pain for existing code.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
x" wasn't well-defined, but going in and
out of userland callbacks like this is presumably rather inefficient.
Perhaps the "register" functions should take an optional list of namespace
prefixes, so that the core implementation can do the string comparison, and
only despatch to th
; their
reasoning seems sound (from https://getcomposer.org/doc/04-schema.md#psr-4):
> Namespace prefixes must end in \\ to avoid conflicts between similar
> prefixes. For example Foo would match classes in the FooBar namespace so the
> trailing backslashes solve the problem: Foo\\ and FooBar\\ are distinct.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On 11 April 2023 13:01:08 BST, Dan Ackroyd wrote:
>On Tue, 11 Apr 2023 at 09:48, Rowan Tommins wrote:
>>
>> Similarly, I think it should be possible to "unpin" a function
>> lookup with a later definition,
>
>Can you say what the technical justification f
ue of
foo::function would be dependent on runtime state in a way that Foo::class is
not.
Meanwhile, the main use case for such a syntax - getting a reference to use as
a callback - is now well served by the first class callable syntax
my_function(...)
Regards,
--
Rowan Tommins
[IMSoP]
-
and
just to discover a new file, so function autoloading feels more natural.
Regards,
--
Rowan Tommins
[IMSoP]
[1] https://heap.space/xref/php-src/main/SAPI.c?r=9d5f2f13#1085
[2]
https://heap.space/xref/php-src/sapi/apache2handler/sapi_apache2.c?r=4da0da7f#371
Regards,
--
Rowan Tommins
[IMSoP]
time(true) in your application to calculate the duration from
REQUEST_TIME_FLOAT to start of profiling, with all subsequent profiling
using hrtime?
Regards,
--
Rowan Tommins
[IMSoP]
usted users to split and
merge threads)
* Spam control
Regards,
--
Rowan Tommins
[IMSoP]
cket,
and one of those weird Japanese fireworks, all from people who haven't
otherwise participated in the conversation ... I'll just ignore them and
carry on.
It's certainly not a killer feature I'd uproot an entire community for.
Regards,
--
Rowan Tommins
[IMSoP]
n-up forms you encounter *before* you hit the list.
Because if it's the latter, migrating the entire community to a new
platform won't help - we'll still suck at introducing anyone to that
platform - and most of what we need is someone who's good with words to
update s
but then I
see comments like this ...
The only downside i can think of is threading, github only does
level-2 threading.
... and I wonder if others really get that people aren't just defending
e-mail because we're old and stubborn, we actually like how it works, or
at le
g the documentation to signpost them better is
something that can happen right now, whether we move or not.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
like
\foo\strlen('x') should become an implicit alias for \strlen('x'), which
is apparently the current proposal.
I really like the majority of this proposal, but right now would vote
against it based on that.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Ru
ed as
the instance. Maybe someone has a less ugly suggestion?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ehaviour change is actually a BC break, because the examples so far
haven't convinced you?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
roposed change in behaviour, so if you want a test
that passes on existing versions and fails on the current branch, just delete
the last two lines in the EXPECT section.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
lists or automatic call to the parent
constructor. I think with clean errors that's a good first feature set, and
if someone comes up with an implementation for manipulating existing
constructors, that can be proposed later.
So, "watch this space", as the saying goes :)
Regards,
--
Rowan Tommins
[IMSoP]
e property
references. It's a lot of extra complication to duplicate things the language
already has.
Having played with it a bit while implementing, I also like the conciseness of
objects with no explicit body at all:
$who = new class use ($firstName as string, $lastName as string) {};
echo
have an example of how this looks
with the clone-with syntax.
2) How does this interact with an __clone() method? I'm guessing the
__clone() would be called first, and then the with-clause applied?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing Li
t = clone $point with {'x' => $x, 'y' => $y, 'z' => $z};
$point = clone $point with {x: $x, y: $y, z: $z};
$point = clone $point with {:$x, :$y, :$z};
Rather than making everything use an array or array-like syntax, I would
probably go the other way a
hStatus($statusCode, $reasonPhrase = null): Response {
$newProps = [:$statusCode];
if ( $reasonPhrase !== null ) {
$newProps['reasonPhrase'] = "Old: $this->reasonPhrase, New:
$reasonPhrase";
}
return clone $this with (...$newProps);
}
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
to files.
Precisely. PHP doesn't need to do anything to change this, it's entirely
up to users. There are ways that PHP might be able to optimise for
different use cases, but the power of the autoloader being a callback
function is that it can do whatever you want it to. It doesn't even need
to involve files at all, if you don't want it to.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
o we still want to minimise that impact.
(As an aside, I'd personally much rather type \ in front of functions
than maintain a long "use function" list in every file, even with the
aid of tools; but apparently I'm in a minority on that.)
Regards,
--
Rowan Tommins
[IMSoP
cma262/multipage/ecmascript-data-types-and-values.html#sec-object-type
Regards,
--
Rowan Tommins
[IMSoP]
"default" list is pretty much up to whoever
configures PHP (the Linux distro, hosting company, etc).
That's assuming we go down the "object with efficient constructor and
operator overloading" route. If we made deeper changes to make it scalar
(which would be A LOT
quot; and "band-aid"
hyperbole, though. It could give better errors, but the solution is still
"never initialise decimals from floats", and that would be true whatever
was built into PHP.
Regards,
--
Rowan Tommins
[IMSoP]
lacing both variants also makes it easier for
users to find everywhere they've used it, and polyfill both variants,
rather than having to examine each.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Fri, 28 Apr 2023 at 05:17, Alexander Pravdin
wrote:
> On Thu, 27 Apr 2023 at 07:03, Rowan Tommins
> wrote:
>
> > You have to load the value somehow; bcmath accepts strings directly, so
> > parses the values each time, which isn't very efficient; but php-decimal
>
ill quiet, or going around in circles.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
On Fri, 28 Apr 2023 at 09:16, Rowan Tommins wrote:
> On a different point, I think "assert_options" is a peculiar name for
> either setting or getting a single option, and would suggest it be
> replaced with two new functions, assert_get_option and
> assert_set_option.
>
hink due to the current unclear naming, options 3 and 4 are superior to
options 1 and 2. Do you have a specific reason to prefer option 1?
Regards,
--
Rowan Tommins
[IMSoP]
or 10.0
b) Deprecate in 8.3, remove in 10.0
c) Do not deprecate
Now if the votes are a:5, b:4, c:4, we can say:
- 9 people voted for deprecation in 8.3, vs 4 against
- only 5 voted for removal in 9.0, vs 8 against
- 9 voted for removal in 10.0, vs 4 against
So we conclude that we should deprecate in
it's better documentation to stop people confusing
deprecations for errors, and better functionality for users to choose which
messages they see.
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
x27;s trivial to include a definition somewhere wrapped in
function_exists.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
x27;; it needs to know the qualified name of the
function the user referenced, 'Acme\bar'.
Similarly, I'm not wholly clear why nameof(MyClass::method(...)) should
evaluate to "method" rather than "MyClass::method" or indeed
"Full\NamespaceOf\MyClass::meth
.
>#[SomeAttribute(callback: nameof(\Acme\bar(...))]
>...
>
>I hope this helps!
Not really, I'm afraid. If I have to write out the fully-qualified name, why
would I bother with nameof() rather than just using a string?
The more I read in this thread, the less I understand what the
n't trigger autoloading, so whether
it gives a Warning or not depends on whether other code happens to have loaded
the definition of Foo
- probably other options that I haven't considered
With the "no error handling" version, this becomes moot, because it's just a
string manipulation exercise. That's how ::class currently works, apart from a
few specific cases like static::class and $someInstance::class
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
oud") are based in Germany, and haven't added any
other translations.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
d", etc depending on type doesn't really
add anything, since the output is always a string anyway, not some
type-specific thing.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
:
> Fatal error: Uncaught Error: Undefined constant "NoExist\TEST" in /in/gltKN:5
Take the constant part away so that the next line runs, and
https://3v4l.org/q0XQO shows the fully qualified name right back up PHP 5.5,
because expanding the name is actually the *only* thing that ::
ot;, or to have a rush of changes because "we've only just decided 9.0 is
soon".
It also helps avoid putting a release number on an experimental feature that
might never arrive, as with Unicode strings in 6.0; or that might turn out to
be less important to most users than other ch
e installed. If you've got an up to date PhpStorm,
you can actually use it directly from a scratch file. (Huge shout-out to Sjön
Hortensius for making and maintaining such a useful tool!)
Regards,
--
Rowan Tommins
[IMSoP]
t had the most promising responses when banging
that drum in the past.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ity to cause issues for a lot of codebases.
Given that we changed a whole list of resources to objects in PHP 8.1, it's
clearly not considered that massive a shift to most people
https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.resource2object
Regards,
--
Rowan Tommins
[IMSoP]
A compromise might be to have a planned cycle, but with some leeway for
major projects, e.g. "a major release will happen no more often than every
4 years, and no less often than every 6"; or, to put it a different way,
"there will always be an x.3 release, and never an x.6".
Regards,
--
Rowan Tommins
[IMSoP]
e already out there.
Bottom line, I think there is some merit in having part of the standard
library be written in PHP rather than C, but we'd still want to be very
conservative in what went in there, because most of the downsides of
locking it to the PHP release cycle would still be there, and C
me of the data
structures in ext/spl.
IMHO, the things that would benefit from being written in PHP then bundled
are things that are so low-level that it's hard to get them wrong; the
building blocks that the community will use to build things like Monolog
and Guzzle.
Regards,
--
Rowan Tommins
[IMSoP]
trivial, and have a
wider pool of contributors who could work on it - as long as they didn't hit a
limitation that needed to be fixed in the C layer.
Regards,
--
Rowan Tommins
[IMSoP]
e stakes are higher, and the abilities for rework
and forking far more restricted.
Regards,
--
Rowan Tommins
[IMSoP]
defines "graphemes" or
"grapheme clusters" to better match the common intuition of what a "character"
means.
Perhaps we should instead, or also, add a "grapheme_strpad" function to
ext/intl?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ld save everyone having to rediscover them the hard way.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
have
mandatory pre-compilation stages which can and do perform static analysis.
Regards,
--
Rowan Tommins
[IMSoP]
hey
don't add it, the feature has zero benefit to them.
So the argument is that the key estimate for whether to include it in the
engine is how many users will add the attribute, but not run a static analysis
tool. If that number is very low, adding it to the engine has a very low value.
R
inherited from a base class, at which point there is a contract that all
descendants of that base class will have the property available. So it seems
logical that that contract could also be included in an interface.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Devel
ll niche for the engine to care about, unless
it's the beginning of a larger project to standardise and encourage such
attributes.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
it.)
I'm still in two minds on the general concept of this RFC, as it is placing a
burden on users for the mostly minor convenience of maintainers; but I think
you've done a good job responding to concerns and improving the proposal.
Regards,
Hi Máté,
Sorry I didn't get round to
predictable and accessible language, and I care less about minimizing
> backward compatibility breaks.
I think Claude is taking the same premise, and reaching a different
conclusion: returning true is consistent with the other methods on the class,
and that consistency makes it more predictable and more accessible.
Regards,
--
Rowan Tommins
[IMSoP]
rth adding to their code, I don't think I'd be able to answer.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
nd I'm not entirely sure what you're
actually proposing - how does an alias fit in to something that's about
splitting a function into two?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ameter form,
I'm not sure. As you say, it's probably pretty rare, particularly because
according to the docs that parameter is ignored for most file formats the
function supports anyway.
Regards,
--
Rowan Tommins
[IMSoP]
ets a session
handler using an object instance". Thus, the first is
"session_set_handler_functions" or "session_set_handler_callbacks" or so,
and the second is "session_set_handler_object" or
"session_set_handler_instance" or so.
Without any suffix at all, it seems like "set a session handler the normal
way" vs "set a session a special different way"; like how
"array_merge_recursive" is a special version of "array_merge".
Regards,
--
Rowan Tommins
[IMSoP]
more I'm leaning towards not doing
anything being the best choice. The benefit seems small, and the cost high.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
cast a No vote on that question, but I
thought I'd raise the concerns early to avoid surprise.
Regards,
--
Rowan Tommins
[IMSoP]
deprecating something
that's been working fine for 20 years.
Regards,
--
Rowan Tommins
[IMSoP]
e some feedback or suggestions on the documentation when I
get a chance.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t;query('some SQL');
$cacheItem->save( $result['item_name'] );
} );
... or macro-based:
$name = null;
$cache->memoize!($name, block {
let $result = $db->query('some SQL');
$name = $result['item_name'];
} );
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
signatures, so what does making it the preferred signature (with
users of the other having to change their code) have to do with
"history/legacy"?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
that class A doesn't define a contract for method
bar falls to static analysers, and the same would be true for default
implementations on interfaces.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
that inherits them.
This is also hinted at in the exchange between Levi and Alexandru about
private methods on the interface itself, which would not be visible
anywhere outside the interface. Again, that's different from traits,
where members marked "private" are private to the
t users have a clear choice between
the two. Deprecate the existing function completely.
All the other suggestions seem likely to create a lot of confusion, and
not actually leave us much better off in the long term.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Develop
e have
two names at all, they should both be chosen with new users in mind, not
fudged based on a combination of current and new naming styles.
Once the deprecation period is over, we should be left with a pair of names
that obviously signals the difference; or, we should be left with only one
function.
Regards,
--
Rowan Tommins
[IMSoP]
bals
How about "request_form_populate_globals"?
Regards,
--
Rowan Tommins
[IMSoP]
classes, not something specific to interface default
methods. The lack of those constraints in PHP is likewise not something
that's specific to this proposal, the language *always* allows you to
attempt any method call on any object, including $this, even if a type
checker would say the call is invalid.
Regards,
--
Rowan Tommins
[IMSoP]
7;t get any of the
(very small) benefits of removing the extra signature until the final
removal anyway.
Regards,
--
Rowan Tommins
[IMSoP]
is is a direction we want to go, but thought I'd
throw it out there.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
or library for a userland
implementation.
[1]
https://github.com/php/doc-en/commit/56562880bd287b2d96519932044f911db518f2cf
[2] https://wiki.php.net/rfc/precise_session_management
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
d all your other work.
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
- basically, describe
every property that DOM would expose on each node.
For debug output, the main concern is showing what you'll get with
various styles of access in SimpleXML, so a single "@text" =>
"foobarbaz" would make sense; or maybe even "(string)"
array_filter($array, $callback, $mode) );
}
// In another file:
var_dump( backwards_array_filter($some_array, call_me_back(...)) );
Regards,
--
Rowan Tommins
[IMSoP]
r now is a short and slightly off-topic one: someone really
needs to look into adding opt-in block scoping to PHP, similar to JS "let". It
would fit so well with proposals like this one!
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ve a setOutputOptions() method to be called
before asXml(). Still a bit clunky though.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
about how to fit
them with the existing language. I will continue to engage in good faith in
discussing those proposals, but find it disheartening to be labelled as part of
a "camp" that needs to be "overcome".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Run
-term planning".
As Jordan said, if you really want to have a productive discussion about a
feature, try to come across more positively, e.g. "I was thinking it would be
useful if the language had this feature, and was wondering if it's been
discussed before?" Bonus poin
constraint int|float
}
The actual attributes could either be built-in, making them official
parts of the language, or managed in a library that static analysers
co-operate on, making them standardised but more agile.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Develop
gh the
cost of "type declarations can no longer be trusted".
Regards,
--
Rowan Tommins
[IMSoP]
ace, enum, or type alias.
Coming back to the lack of a build stage, that also means type aliases would be
opaque to compile-time optimisations, which are mostly per-file. I'm not sure
what impact that would currently have, but it's worth thinking about.
Regards,
--
Rowan Tommins
[IMSoP]
1. As a Unix timestamp, that's a one-second
accuracy for any time 285 million years into the past or future.
https://www.wolframalpha.com/input?i=2**53+as+unix+timestamp
Possibly you're thinking of a representation that counts integers as
milliseconds or microseconds, instead of second
le::createFromTimestamp($value / 1_000_000) - as
discussed above, this will not lose any accuracy for dates in the next
200 years or so.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
next chance to break compatibility is
in 9.0, not 8.anything. While there are often grey areas around this
rule, there is absolutely no question that empty() could be removed any
time before that. If anything, proposing removal in 10.0 might be more
reasonable.
Regards,
--
Rowan Tommins
[IMSoP
if preloading remains
optional. We could produce an error if any generic/extended type was
encountered without being preloaded, but that poses a dilemma for libraries:
either don't use the new types, or impose a requirement for applications to use
preloading. I'm not convinced there&
codes!
maybe stabilising them for deployment, maybe just using the existing OpCache
preloading.
If you use the JIT in advance, it becomes a very different tool - the point of
JIT compilation is to make use of runtime information about hot paths, the
actual types of dynamic arguments, etc
Regards,
--
Rowan Tommins
[IMSoP]
;warm" the JIT in advance as part of preloading, but that
seems to be mostly orthogonal to what we're talking about here in terms of
static analysis.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
ant an SQL
null, not ''; but if the [imaginary] sql_escape function doesn't reject
nulls, you may not notice the bug until you've ended up with garbage in
your DB.
Regards,
--
Rowan Tommins
[IMSoP]
te debate than anything
that the declare() covers.
Wherever it is used, "null" is a confusing and often controversial
concept. In different contexts, it is used for different things, and has
different ideal behaviours. It's a whole debate on its own, and bringing
in other types of coercion just confuses the conversation.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
RMs).
So maybe what's really needed is to draft a new copy of the policy document,
updating or removing those parts that are no longer relevant, and adding a
timeline for the pre-release phases?
Or possibly there's a different document I should be looking at, and the RFC
could contai
an initial draft to start the discussion, because the current
behaviour is quite hard to explain in a short e-mail.
Please let me know your thoughts.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
non-starter since we didn't even manage to remove "var" in favour of
"public", but I wanted to say it for completeness.
Maybe someone can come up with some other variation or compromise?
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
t to the RFC, at least to consider.
The RFC to add "mixed" gives an example of removing the type as invariance, but
doesn't seem to justify why "untyped" and "mixed" should be considered
different, from a type system point of view.
https://wiki.php.net/rfc/m
d autoloading
support for such functions, and that's a whole different problem...
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
1 - 100 of 1311 matches
Mail list logo
