get to both have an auto-close
time, and show the start and auto-close time on the wiki page. The vote closes
when the widget says it does. Presumably it would be easy for it to default to
the exact same time as the start stamp, and then... I don't care about leap
seconds or daylight savings time. It ends in ~2 weeks, automatically, and the
exact time is right there on the page. Plan accordingly.
Then all the faffing about with date-and-time edge cases goes away and we can
move on with life.
--Larry Garfield
y collections research with Derick a while back
included a `Set` type, which also supported operator overrides for the |, <,
<=, -, and other operators, so it did effectively give a very nice enum set
syntax. Whether that is the optimal approach or not is unclear. But an Enum
Set feature should work with any enum. (And of course runs into the eternal
generics question.)
So, Rob, which one are you really talking about?
--Larry Garfield
it and say "'nuf said,
we're voting, that will resolve this question, vote no if you are on team X."
Otherwise, again, we just keep talking forever.
-
I can easily see a mostly-run-its-course discussion thread that would be ready
for a vote in early December, but that would then run into the holiday blackout
period, so the authors delay the vote until mid-January. (I'm pretty sure I've
done that before.) However, that could run into the 6-week fallow rule
proposal. Should there be any sort of allowance for that, so that the
mandatory blackout period doesn't force delaying an RFC even more?
--Larry Garfield
s made sense, but on consideration,
that's not what clamp() traditionally does. It's just min/max shortcutting.
So let's just do min/max shortcutting and move on with life.
--Larry Garfield
max)
C++: clamp(val, min, max)
Java: clamp(val, in, max)
Javascript: clamp(val, min, max)
C#: clamp(val, min, max)
Kotlin: val.clamp(min, max) (as an extension function)
Ruby: val.clamp(min, max)
So it looks like CSS is the oddball here. We should follow the clear majority
approach. (Kyle, feel free to include this in the RFC.)
--Larry Garfield
On Tue, Aug 26, 2025, at 1:36 PM, Tim Düsterhus wrote:
> Hi
>
> On 8/26/25 16:48, Larry Garfield wrote:
>> I have multiple times just recently had need of "I have a numeric string,
>> should I cast it to an int or a float?", for which an
>> is_representable
ve multiple times just recently had need of "I have a numeric string,
should I cast it to an int or a float?", for which an is_representable_as_int()
function (or similar) would be quite helpful, and neater than the messy
solution I usually use.
I haven't had a use for is_representable_as_float() that I can recall.
--Larry Garfield
On Thu, Aug 14, 2025, at 2:30 PM, Larry Garfield wrote:
> So far, the best suggestion that's been put forward (though we've not
> tried implementing it yet) is to disallow a pipe inside a short-closure
> body, unless the body is surrounded by (). So this:
>
> f
On Sun, Aug 24, 2025, at 9:41 AM, Kyle Katarn wrote:
>>> (No need to change it in this RFC, just note explicitly that the expected
>>> behavior is identical to that min(max()) construct, regardless of type.)
>>>
>>> --Larry Garfield
>>>
>>
&
I don't even know what the logic here is. :)
https://3v4l.org/pTmiV
(No need to change it in this RFC, just note explicitly that the expected
behavior is identical to that min(max()) construct, regardless of type.)
--Larry Garfield
w. I think I
follow it, but it's clunky enough that I am not certain of it. :-)
Also, the text says $num but the code example says $value.
What determines comparability? What happens if you try to clamp values that
are not comparable? Eg:
clamp(new Point(1, 2), new Point(0, 0), new Point(5, 5));
I assume that will fail somehow, but the failure should be described explicitly.
--Larry Garfield
On Thu, Aug 21, 2025, at 4:07 AM, Hans Krentel wrote:
> On Thursday 14 August 2025 21:30:08 (+02:00), Larry Garfield wrote:
>
>> Does anyone have a better solution to suggest?
>
> I've been following the discussion on the pipe/short-closure precedence
> issue, and w
ich would likely cause even more confusion.
If we ever manage to get methods on strings by some mechanism or another, we
can consider naming that split() and having its behavior match that in our
sibling languages. But for now, I'd prefer to not mess with it.
--Larry Garfield
27;Value may not be null'));
};
$c(null);
This would not throw the exception as expected, unless parentheses are added.
It would var_dump() an exception and then try to throw the return of
varl_dump(), which would fatal.
RM approval to address this during the 8.5 beta phase has been given, but we
still want to have some discussion to make sure we have a good solution.
So, the question:
1. Does this seem like a good solution, or is there a problem we've not spotted
yet?
2. Does anyone have a better solution to suggest?
Thanks to Derick, Ilija, and Tim for tracking down this annoying edge case.
--
Larry Garfield
la...@garfieldtech.com
vs to think
about, but it does need to have a clear and graceful transition for existing
code. The above code does not strike me as "clear and graceful transition."
>From the RFC:
> Having multiple serializations methods which can be superseded by newer
> methods is somewhat confusing and add unnecessary complexity to the language.
I agree, which is why I voted Yes on that part.
> Because the __serialize()/__unserialize() mechanism is a straight up
> improvement over __sleep()/__wakeup() we propose to deprecate the latter in
> favour of the former.
This claim now appears to be incorrect, given Nicolas' investigation. (Ie,
it's not a straight up improvement, nor a drop-in replacement.)
I would be in favor of holding off implementing this deprecation until a better
transition process is found, and/or an RFC to reverse it. (I defer to the RMs
on the process they want to follow.)
(And I think this does lend still more weight to Juliette's frequent request
for more robust impact analysis for deprecations. Not because deprecations are
bad, but because we should know what the impact is so we know how to mitigate
it effectively.)
--Larry Garfield
;
> Feedback is very much appreciated.
>
> The change and some more details live here:
> https://github.com/php/php-src/pull/19087
I am not opposed to this, but I would like to see it go through an RFC.
--Larry Garfield
On Sun, Jul 20, 2025, at 2:10 PM, Larry Garfield wrote:
> I have opened the vote for property hooks on readonly properties. The
> vote will run for two weeks, until 3 August.
>
> As noted, there are two independent votes, one for allowing a "get"
> hook on readonl
her or not to proceed.
https://thephp.foundation/blog/2025/08/05/compile-generics/
Wearing my Internals/voter hat, my stance is a very strong "yes please!"
--
Larry Garfield
la...@garfieldtech.com
On Tue, Jul 29, 2025, at 2:22 PM, Hans Krentel wrote:
> On Monday 14 July 2025 15:29:31 (+02:00), Larry Garfield wrote:
>> Is their use for quick hacky scripts worth the cost of reserving a symbol
>> that could be repurposed for something else more generally useful in the
&
if a variable is a
primitive or not, at the very least.)
--Larry Garfield
On Tue, Jul 22, 2025, at 3:02 PM, Larry Garfield wrote:
> Hi folks. Just a quick update: We've made one small change to the RFC.
> Specifically, in order to prevent accidentally calling optional
> arguments from callback locations like array_map() or array_find(), a
> par
standardized
function for that would be most welcome.
The name is quite long though. :-)
>> - is_representable_as_float()
The same argument applies here, although in most cases is_numeric() is close
enough. A more precise option would not be unwelcome, though.
--Larry Garfield
on, but I cannot.
>
> I was always sure that the reason behind all methods of \Exception
> being final is Larry-Garfield-blogpost length/depth so I never bothered
> to ask and made workarounds.
Hey, I resemble that remark! :-P
(I actually have no idea what the original reason was
On Sun, Jul 27, 2025, at 8:09 AM, Tim Düsterhus wrote:
> Hi
>
> On 7/24/25 15:42, Larry Garfield wrote:
>> Just to clarify here, Single Transferable Vote and Ranked Choice Voting are
>> the same thing. I think it's just another Ameircan-vs-British English
>> qu
; policies, I would
still find Abstain useful. Maybe not critical, but useful. And getting it in
place, and people used to it, could simplify future steps of using Abstain for
those or other things.
--Larry Garfield
will cause an issue. I
do support interfaces and opt-in inheritance, but I don't believe it actually
tags an interface with #[Attribute] anywhere.
--Larry Garfield
on. It's simple enough for a user to
plug those two operations together themselves when appropriate.
--Larry Garfield
rray_find($array, cb(val: ?, key: ?)); // array_find expects
> $value, $key.
Which is valid, but on balance I think it's OK for that case to still be a
manual short-closure in exchange for less confusing behavior of PFA. In
practice, I expect most PFA uses to be creating unary function anyway, followed
by thunks, so it won't greatly matter.
Does anyone else agree/disagree?
--Larry Garfield
On Thu, Jul 24, 2025, at 5:03 AM, Tim Düsterhus wrote:
> Hi
>
> I did not yet have the time to check the changes and your reply in
> detail, but I already wanted to follow-up on some of the points.
>
> Am 2025-07-23 15:55, schrieb Larry Garfield:
>> $c = fn(string
On Thu, Jul 24, 2025, at 4:54 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-07-23 15:57, schrieb Larry Garfield:
>> What other changes there are unaccounted for? I thought we'd kept up
>> on the behavioral ones.
>
> The support for attributes (particularly #[\Sensitiv
t, rather than after those.
* This one is largely uncontroversial, whereas a quorum or "use it or lose it"
policy almost certainly would be.
Those all strike me as good reasons this is fine to adopt stand-alone and get
it out of the way, just as, eg, pipes could be adopted without PFA, on the
expectation of PFA later.
--Larry Garfield
On Thu, Jul 24, 2025, at 4:13 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-07-23 16:05, schrieb Larry Garfield:
>> The only thing I'd add is that in the case of multi-option secondary
>> votes, STV/RCV also be explicitly allowed. (Rank first, second, third,
>> etc.
or STV is kinda clunky on the wiki right now, but we know
how to make it work.) Perhaps even encouraged if "do nothing" is not one of
the options.
An example of both up/down and either/or secondary votes would also be helpful.
--Larry Garfield
On Tue, Jul 22, 2025, at 3:18 PM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-07-22 22:02, schrieb Larry Garfield:
>> It seems the discussion has quieted down and wasn't particularly
>> contentious to begin with (whew), so we're just about ready for a vote.
>
>
On Wed, Jul 23, 2025, at 3:56 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-06-28 07:06, schrieb Larry Garfield:
>> https://wiki.php.net/rfc/partial_function_application_v2
>
> I've now given the RFC an in-depth read. I have the following remarks:
>
> 1.
>
>>
On Sat, Jun 28, 2025, at 12:06 AM, Larry Garfield wrote:
> Hi folks. Arnaud and I would like to present take-2 at Partial
> Function Application.
>
> https://wiki.php.net/rfc/partial_function_application_v2
>
> It is largely similar to the previous PFA proposal from 2021, tho
d be a variable that references a Closure, and often will be. So
it's already quite clear what will happen
If we were to agree that there was a use case for "reverse assignment" (of
which I am not yet convinced), it should be its own stand-alone thing. Just
for argument's s
ther one can pass or fail independently.
https://wiki.php.net/rfc/readonly_hooks
--
Larry Garfield
la...@garfieldtech.com
ort their own RFC is
nonsensical, given that multi-part votes or split votes or secondary votes come
up multiple times every release. Rather, it means the different parts are
related enough and small enough to be digestible in a single RFC, but each can
stand on their own if necessary. In this case, nothing about the get hook
necessitates a set hook, and nothing about the set hook necessitates the get
hook.
--Larry Garfield
gt; PHP 8.5.
At this point, I fully expect the 'get' part of the RFC to not pass. Someone
else is welcome to then work on an init hook. The seemingly less controversial
'set' hook still has considerable value on its own, and hopefully that passes.
--Larry Garfield
s anymore.
Even on set hooks, which do not violate any of the interpretations of what
readonly "means" floating about? As the RFC notes, that's now a necessary
validation step with the improved clone() on its way.
--Larry Garfield
On Sat, Jun 7, 2025, at 11:16 PM, Larry Garfield wrote:
> As Nick has graciously provided an implementation, we would like to
> open discussion on this very small RFC to allow `readonly` on backed
> properties even if they have a hook defined.
>
> https://wiki.php.net/rfc/readon
or "classes.php" file that Composer just front-loads on
every request that contains a bunch of one-liner class definitions (or
functions, or whatever) is perfectly fine, and works today.
The only thing that would need to change is for SA tools (mostly PHPStorm) to
be less whiny if they see a class that doesn't match its file name. But I am
quite confident JetBrains can figure out how to do that.
In short: This is not a real problem. There's no need for us to make it one.
--Larry Garfield
t; 200;
> }
>
>
> --
> Best regards,
> Dmitrii Derepko.
> @xepozz
I have some concerns that there may be edge cases we've not thought about, but
at the moment I am generally in favor. An RFC and implementation would likely
help ferret out those edge cases.
I agree that this combined with single expression functions would go a long way
to making lightweight data structures even easier to create and use.
--Larry Garfield
On Tue, Jun 3, 2025, at 12:11 PM, Dmitry Derepko wrote:
> I've changed the structure, followed the rfc template now.
>
> The voting section isn't available now, because the RFC is under discussion.
Hi Dmitrii. Are you going to continue this? If you want to bring it to a vote
for this release, i
On Sun, Jul 13, 2025, at 6:28 PM, Ilija Tovilo wrote:
> Hi Nick
>
> On Fri, Jul 11, 2025 at 6:31 AM Nick wrote:
>>
>>> On 8. Jun 2025, at 11:16, Larry Garfield wrote:
>>>
>>> https://wiki.php.net/rfc/readonly_hooks
>>>
>>> To not get
Is their use for quick hacky scripts worth the cost of reserving a symbol that
could be repurposed for something else more generally useful in the future?
(Not immediately of course, but eventually.)
--Larry Garfield
get-hook's first return value cached; it
would still be subsequently called, so any side effects would still happen
(though I don't know why you'd want side effects), but only the first returned
value would ever get returned. Would anyone find that acceptable? (In the
typical case, it would be the same as the current $this->foo ??= compute()
pattern, just with an extra cache entry.)
--Larry Garfield
nd.
>
> Cheers,
> Ben
>
> P.S. For legal questions or concerns, I’m working with Pamela Chestek
> of Chestek Legal <https://www.chesteklegal.com> on behalf of the PHP
> Group. You may be familiar with her work as chair of the license
> committee for the Open Source Initiative.
This is long overdue and very welcome. Thank you, Ben!
--Larry Garfield
en?
Repeat all of the above on readonly properties.
I don't know the answer to any of those. We could probably collectively figure
out some answers to that in time, but that's a much larger lift than either
Nick or I have any interest in engaging in at this point, especially when there
is a reasonable solution right in front of us that is trivial to implement.
--Larry Garfield
at the
edge of reasonable complexity more complex.
An init hook would be clearer, certainly, though it also has its own edge
cases. Can you set something that has an init hook? What happens if there's
both a get and init hook? These probably have answers that could be sorted
out, but t
On Tue, Jul 1, 2025, at 9:27 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-06-09 17:11, schrieb Larry Garfield:
>> I also fleshed out the __get mention with an example that shows what
>> you can already do today, and in fact could since 8.1 when readonly was
>> introdu
On Fri, Jul 4, 2025, at 5:27 PM, Rob Landers wrote:
> On Sat, Jun 28, 2025, at 07:06, Larry Garfield wrote:
>> Hi folks. Arnaud and I would like to present take-2 at Partial Function
>> Application.
>>
>> https://wiki.php.net/rfc/partial_function_application_v2
>
On Fri, Jul 4, 2025, at 6:50 PM, Andreas Hennings wrote:
> On Thu, 3 Jul 2025 at 23:44, Larry Garfield wrote:
>>
>> On Thu, Jul 3, 2025, at 12:49 PM, Andreas Hennings wrote:
>>
>> >> A setter method injection is what I did in AttributeUtils, because i
n is one such multi-step case, there are lots of others, so in advanced cases
(most of what I do) the object will always have an incomplete phase, and that's
unavoidable. So I'm not *that* worried about there being a brief
incomplete-gap in time in core, because I'll always have one anyway, and I've
already figured out how to handle it.
--Larry Garfield
e
>> > downside here is that Attribute are, generally, serializable, but a
>> > Reflection object is not. So if someone wanted a serializable attribute
>> > they would have to accept the property, use it, and then remember to unset
>> > it at some point. That'
ocessing either immediately or later in the constructor. The downside here
is that Attribute are, generally, serializable, but a Reflection object is not.
So if someone wanted a serializable attribute they would have to accept the
property, use it, and then remember to unset it at some point. That's clumsy.
--Larry Garfield
ts in their respective driver classes? (If so,
please state that explicitly.)
Everything else seems reasonable to me at the moment.
--Larry Garfield
at has to then be checked for and rejected by the new functions.
That feels like clunkiness that we should be able to avoid. So with that
signature, false would still use the existing "unsafe" mode; there's no enum
case for "old unsafe logic", just for the new-correct modes.
--Larry Garfield
it's been a while) in the
discussion thread of your previous RFC. And voted against the RFC on the
grounds that I didn't feel it was robust enough to effectively replace PSR-7
and HttpFoundation.
--Larry Garfield
> targeted for PHP 9? Or would it be more appropriate to defer the
> deprecation to the PHP 9 cycle, aiming for removal in PHP 10?
> Alternatively, should a second vote be held to determine the
> preferred deprecation timeline?
Since we don't know when PHP 9 will be yet (Grrr...), I'd lean toward a
secondary vote or punting it to the usual mass-deprecation RFC that often
happens. (Side note: This is why we need a regular schedule for major
releases.)
--Larry Garfield
to go along with it so
that people can mock it for testing purposes. I would consider this a hard
requirement for any "user facing" HTTP client.
--Larry Garfield
pt,
don't worry.)
(Eg, I would strongly recommend leveraging properties instead of methods for
any built-in objects, which didn't exist when PSR-7 was written but now so; we
should absolutely use the new built-in URI/URL classes instead of user-space
ones, etc.)
Of course, as you can expect, "design and include request/response objects
powerful enough to supplant PSR-7" is a non-small and highly bikesheddable
topic, and PHP is notoriously structurally bad at being able to have those
conversations. That's part of why it's never happened.
--Larry Garfield
owan/.
>
> Best regards
> Tim Düsterhus
... I think that may be the second time I've confused you two. I have no idea
why I keep confusing you and Rowan. Sorry again. :-/.
--Larry Garfield
es of why that's a bad idea; and even
then, I'd expect to be able to default to it.
For the long-names issue that Tim pointed out, perhaps drop "Variant" from the
enum names? As they're namespaced, `Base32::Ascii` seems fairly
self-explanatory.
I am overall in favor of this RFC, modulo notes above.
--Larry Garfield
On Sat, Jun 7, 2025, at 11:16 PM, Larry Garfield wrote:
> As Nick has graciously provided an implementation, we would like to
> open discussion on this very small RFC to allow `readonly` on backed
> properties even if they have a hook defined.
>
> https://wiki.php.net/rfc/readon
On Mon, Jun 30, 2025, at 2:28 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-06-28 07:06, schrieb Larry Garfield:
>> https://wiki.php.net/rfc/partial_function_application_v2
>
> Some thoughts, I did not yet take an in-depth look:
>
> - Will PFA be available in constant-expres
On Sun, Jun 29, 2025, at 7:29 PM, Ben Ramsey wrote:
> Under the section “func_get_args() and friends,” one of the examples shows:
>
> $f = foo(?, ?, ??);
>
> I assume this is a typo?
One too many ?. :-) Fixed thanks.
--Larry Garfield
it now because, well, it's ready now. If the discussion goes
smoothly, we're OK calling a vote on it for 8.5, especially as it would
complement pipes so well. If the discussion runs longer, we're also OK with
targeting 8.6 instead. We'll see how that goes.
--
no further.
3. We should bundle an HTTP client that wraps Curl (with or without minor
improvements to Curl), exact scope TBD.
Personally, I'm open to either 2 or 3. 3 is more bikesheddable, but possibly
the better end result.
Where does everyone else stand?
--Larry Garfield
t trivial is also
important. Whether that's via a mini-response object instead of a string or
something else is open for discussion, I think.
Other questions:
* We have these shiny new URL/URI objects. Should those be supported directly?
--Larry Garfield
uot; or "what enum do I need that is a string?" unless I already know
> the implementation details by heart. The Info and Pause enumerations
> seem more useful in that regard as they reduce the scope in which I
> need to understand, process and decide.
I will agree here. Splitting enums by type doesn't add much value. Splitting
them by topic might, if the topics are sufficiently distinct that a separate
method makes sense. I don't know Curl's API well enough to make specific
recommendations there.
--Larry Garfield
C
should include examples of), IMO, good ergonomics is more important than
looking like the old, horribly obtuse API.
As a worst case, perhaps the top-20 options or so could be converted to
methods/properties, and the rest left to be ugly flags?
--Larry Garfield
correct,
but empty string may be more ergonomic in practice. I defer to Nicolas who has
probably had to deal with it more than I ever will. :-)
[1] https://www.garfieldtech.com/blog/empty-return-values
--Larry Garfield
On Tue, Jun 24, 2025, at 3:18 AM, Adam Cable wrote:
> On Tue, Jun 24, 2025 at 12:20 AM Larry Garfield
> wrote:
>> On Sun, Jun 15, 2025, at 3:12 PM, Adam Cable wrote:
>> > Hello internals,
>> >
>> > I'd like to present my first RFC - str_icontains, a c
t to determine if they're still relevant?
(I don't recall the details; I think one of them was function count explosion,
but I think there were more.)
--Larry Garfield
as for the lengthy, kind and
> productive discussion we had off list, and for the feedback shared.
>
> Kind regards,
> Volker
Despite my no vote, I am happy to see this pass and look forward to using it.
Congrats!
--Larry Garfield
on:
> *1. General appetite for enhanced debugging functions in core
> 2. Concerns about naming conflicts with existing userland helpers
> 3. Preferred feature scope
>
> Thoughts?
>
> Best regards,
> Braunson Yager
What exactly would dump() offer that's different/better than var_dump() already
does today? Is it just a pretty-printed var_dump()? I don't really see a need
for that.
--Larry Garfield
mPHP, Revolt, etc.) will give you 80% of what you're looking for or better,
today. Talking about anything even more drastic is severely premature until
that model achieves critical mass, and ideally becomes the most widely used
SAPI. Until then, this sort of "change the world" redesign is not feasible.
--Larry Garfield
to be a way to yield
> "all the way", so to speak, similar to what an exception does, and how
> effect handlers work in OCaml [2].
>
> The question is, would this be easy, hard, or very hard to add to the
> current PHP source code? Is it conceptually too different from generators?
> Would it be easier to add a way to "jump back" from a catched exception
> (kinda abusing the exception use-case, but that's how effect handlers work,
> more or less)?
>
> Thanks for reading :)
>
> Olle
Algebraic effects is a... big and interesting topic. :-) If we were to go that
route, though, I would want to see something more formal than just a "yield
far." That's basically another kind of unchecked exception, whereas I want us
to move more toward checked exceptions.
--Larry Garfield
It is, thanks.
For the name, I don't like the idea of this being the first `num_` function.
This feels like a place we want to start a namespace for such system
information functions, where we can then name it in a contextually-informed way.
--Larry Garfield
On Tue, Jun 10, 2025, at 2:45 PM, Dmitry Derepko wrote:
> Thanks for participating, Larry.
>
> On Mon, Jun 9, 2025 at 10:29 PM Larry Garfield wrote:
>> 2. Please link to a PR of your actual implementation. In context it looks
>> like your branch comparison link is to the ve
looks like
your branch comparison link is to the version you said didn't work, so it's not
that helpful.
3. The biggest question that has come up in the past (Ilija and I have
discussed it at length) is, naturally, autoloading. How if at all do you
address that?
4. The other big question was determining when to match a given "method" call
to an extension function, when the type of a variable is not always known at
compile time. How did you address this?
--Larry Garfield
this RFC was originally spun off from the hook-improvements RFC, as it
needed more discussion while the other half of that RFC was uncontroversial.
I've added a link to the prior thread for reference.
--Larry Garfield
As Nick has graciously provided an implementation, we would like to open
discussion on this very small RFC to allow `readonly` on backed properties even
if they have a hook defined.
https://wiki.php.net/rfc/readonly_hooks
--
Larry Garfield
la...@garfieldtech.com
}
Interface properties cannot be declared readonly today:
https://3v4l.org/cXgR0
Which I think is correct behavior.
Make sure to include a test based on the "lazy product" example from the RFC
text. That's the main sort of use case I'd expect we'd want to enable. :-)
--Larry Garfield
you're mapping your query results into an object
(please always do this), then you probably want to cast that into to a bool,
and currently weak mode would let you do that implicitly.
I can't think of a case where a string or float magically casting to a bool is
reasonable.
--Larry Garfield
ere was still an active discussion with Nicolas going on that seemed
rather important. Opening the vote while that was still going on is, as noted
above, problematic.
--Larry Garfield
On Tue, Jun 3, 2025, at 4:33 AM, Christoph M. Becker wrote:
> On 03.06.2025 at 03:36, Anton Smirnov wrote:
>
>> On 02/06/2025 20:01, Larry Garfield wrote:
>>
>>> The result of this RFC is that the following would no longer be an
>>> error, yes?
>>>
&
ation.
Also, Ilija is rather busy on other tasks at the moment, as am I. (Unless
someone else wants to jump in to implement it, which would be fine.)
--Larry Garfield
he trend/track
record has been squeezing the weirdness out of type juggling until weak mode
and strict mode are close enough to touch, and the language is better for it.
--Larry Garfield
But the
whole point of the RFC is to provide a native operator for concatenating
functions. Decomposing/deconcatenating an already composed function chain
is... not a thing.
> By the way, RFC describes userland "compose" function performance
> problems, but there is no suggestion to make it natively, why so?
Uh. That's the entire point of the RFC? Make a native compose operator that
isn't even a function.
--Larry Garfield
On Mon, Jun 2, 2025, at 3:28 PM, Rowan Tommins [IMSoP] wrote:
> On 02/06/2025 17:57, Larry Garfield wrote:
>> Well, now you're talking about something with a totally separate compile
>> step, which is not what Michael seemed to be describing at all. But it
>> seems li
=> htmlentities($data)”)
>
> - it will be possible to re-use the compose function along with the new
> operator $data |> compose(…$functions)
Pipe and compose are importantly different operations. I've had user-space
implementations of both available for years in crell/fp:
https://github.com/Crell/fp/blob/master/src/composition.php
I'd love to have a compose operator natively in PHP, too. The RFC for that is
already written, just needs code. I hope to formally propose it soon:
https://wiki.php.net/rfc/function-composition
--Larry Garfield
n time.
I don't mean to dissuade you from looking into the topic; I just want you to be
aware of the prior art so that we don't end up with multiple conflicting
half-baked approaches instead of a single fully baked approach.
--Larry Garfield
a conflict. I don't know how viable that
is off hand.
--Larry Garfield
d
The result of this RFC is that the following would no longer be an error, yes?
function test(): void {
print "test";
}
// This currently gives an error, but you propose that it
// would change to set $val to null?
$val = test();
--Larry Garfield
On Mon, Jun 2, 2025, at 9:44 AM, Rowan Tommins [IMSoP] wrote:
> On 2 June 2025 14:27:45 BST, Larry Garfield wrote:
>>Were we to do that, then the consumer container-loading needs to take any
>>potential module-definition into account. Eg, if one class from a module is
>>pu
On Sun, Jun 1, 2025, at 5:01 PM, Rowan Tommins [IMSoP] wrote:
> On 01/06/2025 17:05, Larry Garfield wrote:
>> I think there's a key assumption here still that is at the root of much of
>> the disagreement in this thread.
>>
>> Given that code from multiple fi
ing space that is build along
the boundaries established by the module/package authors already. (Note: This
still relies on all of those packages being modularized by their authors, but
again, I think that is a requirement.)
--Larry Garfield
1 - 100 of 1263 matches
Mail list logo
