(when I have a
clear idea/opinion formed on a topic upfront) or at the end, when the RFC
has gone through the ironing out a lot: the in-between is a brawl for which
24h/day aren't sufficient.
The nature of email threads in a mailing list makes RFCs extremely hard to
approach anyth
h detail was added in handling
all the weird edge cases of the language: in fact, going as far as
exploring by-ref semantics (instead of just saying "no" to them) is also a
big problem.
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Sat, 30 Mar 2024, 05:19 Ben Ramsey, wrote:
> On Mar 29, 2024, at 20:20, Bob Weinand wrote:
>
>
> On 29.3.2024 23:31:26, Daniil Gentili wrote:
>
> In light of the recent supply chain attack in xz/lzma, leading to a
> backdoor in openSSH (
>
On Tue, 19 Mar 2024 at 17:46, Deleu wrote:
> On Tue, Mar 19, 2024 at 1:42 PM Marco Pivetta wrote:
>
>> One note: if what you are going for is what `azjezz/psl`, be aware that
>> exception / error tracing design needs special attention here: it's not as
>> simple as it
around this kind of
tooling:
https://github.com/azjezz/psl/tree/5f0aeacb708a33d5b2d53a832736c7767a99b215/src/Psl/Type
One note: if what you are going for is what `azjezz/psl`, be aware that
exception / error tracing design needs special attention here: it's not as
simple as it looks!
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Thu, 25 Jan 2024, 06:22 Hans Henrik Bergan, wrote:
> On Wed, 24 Jan 2024 at 17:59, Marco Pivetta wrote:
> >
> > Depends on the actual numbers: is there any way to make a comparison that
> > is relatively stable across architectures?
> >
> > Would it be fea
feasible to start with the
cross-platform-let-the-compiler-do-its-job version (that somebody may
actually be capable of auditing), and then introduce other versions when
the jump is significant enough?
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
5 ... 97% Yes
>
Seen this?
https://github.com/php/php-src/pull/1034#issuecomment-74066967
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
rc provided legacy functions
(which will likely keep emitting warnings for a while, due to BC concerns).
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
a section describing this in HHVM, which is the kind of
problem-space I was thinking of:
https://hhvm.com/blog/713/hhvm-optimization-tips
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
n get
> both a reproducible build AND know when/what it was generated from.
>
Also, refs have a timestamp :-)
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
tainly help people
while jumping across branches, when trying out new RFCs, and it should be
stable.
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Fri, 21 Jul 2023, 22:05 Dusk, wrote:
> On Jul 21, 2023, at 12:38, Marco Pivetta wrote:
> > Hey Jorg,
> >
> > What is the reason for using this over these?
> >
> > * https://www.php.net/manual/en/function.ceil.php
> > * https://www.php.net/manual/en/
Hey Jorg,
What is the reason for using this over these?
* https://www.php.net/manual/en/function.ceil.php
* https://www.php.net/manual/en/function.floor.php
On Fri, 21 Jul 2023, 21:26 Jorg Sowa, wrote:
> Hello internals!
>
> I would like to propose introducing two new modes to the
foo'
3 1 > RETURN 1
This is by design, since otherwise each `::class` lookup would result in
autoloading, which would be disastrous for large maps of classes (like in
service containers).
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
Hey Máté,
Only voted "NO" for `ReflectionProperty#setValue()`, mostly because any
kind of pre-existing subtype will be kinda broken, but it isn't a major
issue.
It's fine if libraries drop support for PHP 8.2 before PHP 9.0 is out.
Marco Pivetta
https://mastodon.social/@ocram
Amazing wording Dan: great way to drive people away. YIKES.
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Mon, 22 May 2023 at 13:49, Dan Ackroyd wrote:
> On Thu, 18 May 2023 at 09:12, Marco Pivetta wrote:
> >
> > I am not sure this RFC is
Hey Tim,
On Thu, 11 May 2023, 18:37 Tim Düsterhus, wrote:
> Hi
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>
>
>
> RFC: Marking overridden methods (#[\Override])
> https://wiki.php.net/rfc/marking_overriden_methods
>
> Proof of concept
FYI: https://externals.io/message/87501#87501
Also: wow, that was 7 years ago?! :O
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Wed, 12 Apr 2023 at 15:53, Alex Wells wrote:
> Hey.
>
> PHP currently uses internals@lists.php.net for comm
I'm also curious to hear whether any participants in this thread do/did
support the PHP foundation in any tangible way :D
If you treat it like an LTS provider, perhaps it's time to pay up the LTS
support fees?
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Tue
to consider that `final` as the
implicit default is an existing contract that really enables ENUM usage.
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Wed, 29 Mar 2023 at 11:05, Rokas Šleinius wrote:
> > to restrict options within a certain range.
> Ok
not even be under your control.
Greets,
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Wed, 29 Mar 2023 at 10:31, Rokas Šleinius wrote:
> Enums were a very useful addition to PHP, however one aspect of them is
> neither
> explicitly documented - or
hymko" with the intention of
> submitting the RFC.
> Could someone please approve the account and give it some karma?
>
> Looking forward to collaborating with the internals team!
>
>
I don't want to shoot this down too early, but:
1. why in the language, when a simple userland function suffices?
2. what's wrong with writing `array_values(array_filter(...))`?
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
Hey Ilija!
On Thu, 19 Jan 2023, 20:26 Ilija Tovilo, wrote:
> However, as demonstrated by the 3v4l, it's not
> exactly trivial. It also requires the full stack trace, as well as all
> frame objects and arguments. That's not going to be great for
> performance. So saying debug_backtrace() exists
Not just that, but `debug_backtrace()` already exists for that purpose.
On Thu, 19 Jan 2023, 19:23 Aleksander Machniak, wrote:
> On 19.01.2023 17:23, Nicolas Grekas wrote:
> > Hi internals,
> >
> > Ilija and I would like to start a discussion about the following RFC:
> >
stem be capable of documenting exception types?
Greets,
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
t help it and given the history of private usage and the
> refusal on relaxing them I do not see this improving with the readonly. At
> all.
>
> On Sat, Dec 3, 2022 at 2:42 PM Marco Pivetta wrote:
>
>> Terrible idea: reflection is mostly introspection tooling, and doesn
our system instead.
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
On Sat, 3 Dec 2022 at 23:39, Karoly Negyesi wrote:
> Hello,
>
> If push comes to shove, private properties can be changed with reflection.
>
> Readonly properties can't.
>
> Please add
On Sat, 26 Nov 2022, 23:56 G. P. B., wrote:
>
> As all the invariants will be maintained in the child classes
>
> The invariant here is the immutability from a behavioural PoV.
LSP has 100% been broken in that example.
>
>
On Sat, 26 Nov 2022, 20:45 Máté Kocsis, wrote:
> We proposed this change because it wouldn't break anything that's already
> not "broken".
>
That's quite a terrible rationale, TBH
>
int(1)
[1]=>
int(2)
[2]=>
int(2)
}
```
I took a simplified example on purpose, just to demonstrate the problem
with `readonly` disappearing in child classes.
That's really really confusing, buggy, and, from a consumer PoV, broken
(LSP violation too, transitively).
That said, allowing mutation in `__clone()` is fine.
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
On Fri, 4 Nov 2022 at 15:40, Larry Garfield wrote:
> On Fri, Nov 4, 2022, at 9:31 AM, Marco Pivetta wrote:
> > Heyo,
> >
> > On Fri, 4 Nov 2022 at 15:26, Ilija Tovilo
> wrote:
> >
> >> Hi everyone
> >>
> >> I'd like to propose a simple
bitrary limitation.
>
> https://wiki.php.net/rfc/dynamic_class_constant_fetch
>
> Please let me know if you have any thoughts.
>
What's the problem with using `constant()` for this?
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
> For better or for worse (IMHO, for worse), `SimpleXMLElement` instances
> representing attributeless empty elements are already falsy, so yes, it is
> absolutely feasible.
>
> —Claude
This is absolutely terrifying.
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
Since this topic fits like a glove, just dropping the "why I don't use
`__toString()`" argument here:
https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460085493
A falsifiable object is worse than `__toString()` in this context, IMO.
Mar
On Wed, 19 Oct 2022, 19:04 David Rodrigues, wrote:
> Hello!
>
> I'm converting my code to use short closures where possible, and I ran into
> a problem using compact().
>
> Basically, the names used in compact() cannot be accessed due to a bug,
> reported in 2019 still in PHP 7.4 (ID 78970).
>
>
Tbh, this affects a new minor and a new major, and only in an unhappy path
scenario, where the current PHP API is bad.
PHP 9 will introduce a hard crash: good.
It's a BC break: yes, native de-serialization is one of the most unsafe
parts of the language, and it requires hardening.
The fact that
This will also throw an exception (**GOOD**) if the cast is not safe to
perform.
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
unless someone can
> > come up with an ultimate counter-argument.
> >
>
> What's your take about 8.2? As I demonstrated, readonly classes are broken
> because of this propagation to child classes.
>
s/broken/working as expected
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
It doesn't break anything: we have a new limitation, we observe if it is
problematic, we remove that limitation if that is the case.
That already happened for PHP 8.1, although I can't remember the exact
feature.
Let the side wheels attached for now
On Sun, 4 Sep 2022, 12:46 Nicolas Grekas,
IMO good as-is: can be relaxed later (8.3 or later), if anybody believes
it's a show-stopper.
Readonly classes don't really need to be lazy.
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
On Fri, 2 Sept 2022 at 19:31, Nicolas Grekas
wrote:
> Hello everybody, hi M
is seems expected behavior to me: it's "nullsafe", not "undefinedsafe".
If it operated like `??`, then `$undefined?->bar()` would be valid too,
which seems wrong, IMO.
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
ntly do it, perhaps once every 2 months :D
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
: let's take the
occasion to disallow references completely on asymmetric access, perhaps?
It would be nice to see references gone for good. No need to pollute the
engine for the edge case of `ArrayAccess` and similar APIs :P
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
gpost that puts
measurable value on traits.
I measured negative value over here, over years.
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
On Wed, 6 Jul 2022 at 16:17, Larry Garfield wrote:
> On Wed, Jul 6, 2022, at 4:45 AM, Marco Pivetta wrote:
> > Hey Shinji,
> >
> > On Tue, 5 Jul 2022 at 23:39, shinji igarashi wrote:
> >
> >> Hello internals,
> >>
> >> I've starte
ented:
it just solves a problem that doesn't/shouldn't need solving.
Greets,
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
elevance of this parameter almost null
2. complicates an API signature for a very tiny detail
3. if the problem is linting/preferences, have your favorite linter
process the file in the way you deem most appropriate
Doesn't need to live in php-src.
Greets,
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
On Mon, 4 Jul 2022, 19:15 Arnaud Le Blanc, wrote:
> > Important to note how `Zend/zend_compile.c` now depends on `Optimizer/`,
> > which is a potential design issue.
>
> The Optimizer was moved to `Zend/Optimizer` earlier so that in the long
> term
> it could be used by the compiler pipeline
Clear "no" from me on this: this is something similar to a PSR-7 URI
object, but with a clunky and mutable API.
Something like this would/should go to packagist first, to assess adoption
there, but I would certainly not use it.
On Tue, 5 Jul 2022, 01:34 Pierrick Charron, wrote:
> Hi internals,
fusing way.
Important to note how `Zend/zend_compile.c` now depends on `Optimizer/`,
which is a potential design issue.
Greets,
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
On Fri, 1 Jul 2022 at 16:05, Larry Garfield wrote:
> Greetings, Internalians.
>
>
Hey Nikita,
On Thu, 9 Jun 2022 at 21:35, Nikita Popov wrote:
> On Thu, Jun 9, 2022 at 9:29 PM Marco Pivetta wrote:
>
>>
>> On Thu, 9 Jun 2022 at 21:27, Nikita Popov wrote:
>>
>>> On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc
>>> wrote:
>>>
On Thu, 9 Jun 2022 at 21:27, Nikita Popov wrote:
> On Thu, Jun 9, 2022 at 8:15 PM Arnaud Le Blanc
> wrote:
>
>> Hi,
>>
>> On jeudi 9 juin 2022 18:46:53 CEST Marco Pivetta wrote:
>> > ## nesting these functions within each other
>> >
>> &
memory leaks.
Assuming following:
* these new closures could capture `$this` automatically, once detected
* these new closures can optimize away unnecessary variables that aren't
captured
Would that allow us to get rid of `static fn () {` declarations, when
creating one of these closures in an
On Wed, 8 Jun 2022, 08:15 CHU Zhaowei, wrote:
> > > declare(ignore_newline_after_close_tag=false); // defaults to true, i.e
> > existing behavior
>
> > This would avoid any new syntax rules, but still provide the ability for
> > php-as-template-engine to behave in the user's preferred mode.
>
>
Hey Craig
On Sat, 7 May 2022, 10:39 Craig Francis, wrote:
> Not what I'm going for... but anyway, to get an idea of your position, do
> you think the string '15' should be coerced to a number, or should it fatal
> error as well? e.g.
>
> $my_number = round($request->get('my_number'));
>
.
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
Hey George,
How would the engine behave (with this RFC included) with an inheritance
check?
Specifically:
interface A {
function foo(interable $param): iterable;
}
interface B {
function foo(array|\Trabersable $param): array|\Traversable:
}
Would they be compatible with each other, if
bout
> potentially using AllowDynamicProperties to pull double duty, allowing
> reads without an error as well, but I do not believe that would be in
> the best interests of the language, and so removed it.
>
> Mark Randall
>
Perhaps worth mentioning that magic methods keep working?
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
BC break for later on :-)
Marco Pivetta
https://twitter.com/Ocramius
https://ocramius.github.io/
On Tue, 5 Apr 2022 at 13:58, G. P. B. wrote:
> Hello internals,
>
> During the review of the implementation of the RFC which introduces null
> and false as standalone types there h
Hey Ilija,
Overall not a fan: want more `sprintf()` and less interpolation, where
possible
Couldn't we let the construct slowly decay into nothingness, perhaps?
On Thu, 17 Mar 2022, 23:27 Ilija Tovilo, wrote:
> Hi everyone
>
> I'd like to start discussion on a new RFC for arbitrary string
>
On Sat, 5 Mar 2022, 04:31 Kris Craig, wrote:
>
>
> On Wed, Mar 2, 2022 at 4:51 AM Marco Pivetta wrote:
>
>> Hey Christian,
>>
>> On Wed, Mar 2, 2022 at 1:41 PM wrote:
>>
>> > this is exactly the problem. Russia did not just invaded Ukrainia o
e do not need to do that on php.net.
>
Please GTFO: we don't need more of Putin's propaganda over here, as they're
busy enough with butchering civilians over there.
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.io/
as Grekas wrote:
> >
> > > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a
> > écrit :
> > >
> > >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas <
> > >> nicolas.grekas+...@gmail.com> wrote:
> > >>
> > >>> But t
endor/` code for 8.0->8.1 stuff, and it doesn't bring anything but
frustration: this stuff is statically introspectible, and even more
side-effects are just more trouble.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.io/
On Mon, Feb 21, 2022 at 12:39 PM Tim Düsterhus wrote:
> Hi
>
> On 2/21/22 12:12, Marco Pivetta wrote:
> >>>> If it's not going to be removed, what's the point of annoying people
> >>>> with deprecation warnings (that they would patch out/silence anyway)?
&g
On Mon, Feb 21, 2022 at 11:10 AM Tim Düsterhus wrote:
> Hi Marco
>
> On 2/21/22 10:15, Marco Pivetta wrote:
> >> If it's not going to be removed, what's the point of annoying people
> >> with deprecation warnings (that they would patch out/silence anyway)?
> >
ly to be removed in `9.0` or `10.0`? Yes, it should be removed at
some point.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.io/
On Sun, 20 Feb 2022, 14:17 Tim Düsterhus, wrote:
> Hi Steve,
>
> On 2/20/22 12:44, st...@tobtu.com wrote:
>
>
> > If that's the case, you may not know that password_verify() can verify
> all password hashes created by crypt(). The whole point of deprecating and
> finally removing crypt() is that
1. You need to be part of https://github.com/orgs/php/people
2. Your group must have issue triage rights
On Mon, 14 Feb 2022, 05:34 Pierre Joye, wrote:
> Hi,
>
> What has to be done that the github issues can be handled by the same
> developers than in bugs.php.net?
>
> It is a bit weird that I
roxies are complex, annoying, necessary (with measure), but debugging them
shouldn't be harder than it already is.
I wouldn't implement `__debugInfo()` nor `__debugType()` on them, ever.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.io/
l
need to upgrade to ~7.0.0 first anyway.
Also, my customers are gently asked to sign a piece of paper in which I'm
not responsible for their bad security awareness.
For those projects, should it be needed, Zend provides commercial support
as a "OMG WE DON'T ACTUALLY WANT TO PAY TO ACTUALLY IMPROVE
On Wed, Jan 5, 2022 at 3:19 AM Jordan LeDoux
wrote:
>
> On Tue, Jan 4, 2022 at 1:27 AM Marco Pivetta wrote:
>
> Can I expect this for other math related RFCs, or is this dogmatic about
> operator overload specifically? I have no clue, and at the very least, I
> would like to l
him multiple times that he should just get paid for it,
since spreadsheets run the frikken world), but to show that this is indeed
a niche use-case.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
ype-safe operations with a different
language than the "main" one:
https://wiki.haskell.org/A_practical_Template_Haskell_Tutorial#Shakespearean_Templates
In addition to all the above, I just noticed that the entire reflection API
in the RFC requires major BC breaks in the reflection API
Hey Jordan,
I've voted "no" on this one: infix functions may have been interesting, but
adding a whole new type system around operators is really not worth it,
given:
* Added AST nodes
* Added method definitions for niche use-cases
* Complexity in support for static analysis tools
I
Gonna vote `no` on this: please design new/dedicated functions, rather than
expanding optional parameters.
On Sat, 4 Dec 2021, 10:57 Hassan Ahmed, <7sno...@gmail.com> wrote:
> Hello, this is a proposal to upgrade the functionality of
> `array_column` to return an indexed array for all of the
y design), and therefore a custom runtime
type would be a bit too "optimistic" about its values, as it would not
verify anything.
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
opt and plan for disaster,
should it become an Evil Corp seeding ground: what is there to be lost, and
how hard would it be to recover?
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
e no on this.
>
> cheers,
> Derick
>
Remember that all information on public repos is also available on
http://www.gharchive.org/
If data retention is the problem, mirroring that could be an effective
solution.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
all against having it on the ML: I set up a filter to ignore those
pesky emails by Intel.
As much as I appreciate their effort, they were really noisy, and not
really useful to the larger group.
If your tool could export the results in machine format with something like
an attached XSD or JS
Hey Tyson,
On Sat, 25 Sep 2021, 18:00 tyson andre, wrote:
> My original message had a section with reasons why an end user might want
> that.
>
Yeh, it sounds like stuff we wanna get away from
> Not a push for getting rid of stdClass. Way too many things use stdClass
> to get rid of
Hey Tyson,
On Sat, 25 Sep 2021, 17:45 tyson andre, wrote:
> What are your thoughts on allowing the `(object)` cast in initializer
> types where `new` was already allowed, but only when followed by an array
> literal node. (e.g. continue to forbid `(object)SOME_CONSTANT`) (see
>
.dev/r/f9c51f72c2
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
Hey Tyson,
Would it perhaps make sense to drag in php-ds, which has matured quite a
bit over the years? I'm referring to:
https://www.php.net/manual/en/class.ds-sequence.php
Is what you are suggesting with `Vector` different from it?
Note: For some reason, I can't quote your post and then
Hey David,
On Sun, 12 Sep 2021, 01:28 David Rodrigues, wrote:
> Hello!
>
> I would like to suggest a feature I saw being implemented in the V8 9.4
> engine called "*class static initialization block*".
>
> https://v8.dev/blog/v8-release-94
>
> In short, it is a method that is executed once when
Heyo,
On Wed, 8 Sep 2021, 02:19 Andreas Hennings, wrote:
> Hello internals,
>
> The function array_column() would be much more useful if there was an
> option to preserve the original array keys.
> I can create an RFC, but I think it is better to first discuss the options.
>
New function,
Hey Nicolas,
On Wed, Aug 25, 2021 at 7:30 PM Nicolas Grekas
wrote:
> I would welcome a new RFC to clarify what is allowed during the feature
> freeze.
>
See https://en.wikipedia.org/wiki/Freeze_(software_engineering)
Greets,
Marco Pivetta
http://twitter.com/Ocram
emonstrated (over the
years) that this can be achieved in a type-safe way anyway, and dynamic
properties are not needed at all.
Over the past decade, I've not seen a single valid use of dynamic
properties either.
If this passes, I'll also deprecate and discontinue experiments like
https://git
Heyo,
On Mon, 16 Aug 2021, 02:04 Tobias Nyholm, wrote:
> It is to correct a mistake
No mistake: the "pure intersection types" RFC was explicitly designed to
avoid scope creep (this RFC).
Heyo, just a follow-up.
On Fri, 13 Aug 2021, 13:30 Marco Pivetta, wrote:
> Hey Nicolas,
>
>
> On Fri, Aug 13, 2021 at 11:35 AM Nicolas Grekas
> wrote:
>
>> Hi everyone,
>>
>> I'm happy to announce that the vote for nullable intersection types is now
gn around reflection API here.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
to be used in
the pipeline.
As a plain "chain of functions with one input parameter and one output", it
makes little sense to have it as a custom construct, as it only adds
complexity to the AST.
Greets,
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
me rather
than runtime.
You could call it a political choice to push a tool like psalm, instead of
the language having a runtime construct to further "duck-type safety".
In addition to that, a mechanism to un-taint values is missing, but it is
not a concept symmetrical to `is
pecifically the type inference bit, in
https://github.com/loophp/combinator , so I see hope to get better types at
a later stage.
Therefore:
* userland runtime **implementation** is trivial
* userland type-safe definition is non-trivial, but not insurmountable
Marco Pivetta
http://twitte
Hey Max,
On Sat, 10 Jul 2021, 11:09 Max Semenik, wrote:
> I've been thinking about extending PHP's cast syntax to user-defined types,
> e.g. not only (int)$foo but also (MyClass)$foo. Currently, a T_STRING in
> parentheses is always treated as a constant - would it be acceptable to
> hijack
the RFC with any further feedback
there, and only checked again today as per a calendar entry I created for
this.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Thu, Jun 24, 2021 at 1:20 AM tyson andre
wrote:
> Mi Marco Pivetta,
>
> > I'm opening the vot
saying what "approximately" means
I can imagine that removing `get_called_class()` could also yield some
engine improvements in future, as there's also less "magic information
about caller scope" to be retained.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
ards more granular data-structures.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Wed, Jun 23, 2021 at 5:49 PM Guilliam Xavier
wrote:
>
> Meanwhile, if anybody knows why the RFC isn't listed on `/rfc`, lemme know
>> :D
>>
>
> You have to add it manually, cf https://wiki.php.net/rfc/howto 3.4
> (yeah...)
>
Excellent, thanks :-D
Marco Pivett
1 - 100 of 624 matches
Mail list logo
