>
> Again, that's the *how*, not the *why*. We only need to "get rid of" the
parentheses if there's some reason to type them in the first place.
>
I’ve already understood that. You mean it’s not the reason, but one of the
possible solutions.
But it’s one of the solutions that, from my point of vie
Hi
Am 2025-03-18 18:48, schrieb Paul M. Jones:
$iriPath = '/heads/' . rawurlencode($val) . '/tails/');
assert($iriPath === '/heads/fü bar/tails/'; // false
From my reading of RFC 3987 that result is incorrect. The space is
neither listed as `iunreserved`, not as `sub-delims`, thus isn't a val
Hi
Am 2025-03-20 21:04, schrieb Juris Evertovskis:
I'm not opposed to having a bottom type, but the `try`/`tryFrom` issue
feels caused by another shortcoming.
In my view`from` and `tryFrom` are factory methods that construct an
instance by being called on the class itself. As such they should
Hi
Am 2025-03-20 17:46, schrieb Paul M. Jones:
```php
function mb_rawurlencode(string $string, string $encode): string {}
```
Ah yes, you're right -- probably `?string $encode = null` to match with
mb_substr().
I am not sure if that signature makes sense and if the proposed
functionality f
On 21/03/2025 11:50, Tim Düsterhus wrote:
Am 2025-03-20 21:27, schrieb Matt Fonda:
If an interface adds a method but makes no promises about what
parameters
it accepts, then why is it part of the interface in the first place--why
add a method that can't be used?
It would more cleanly allow fo
>
> You already explicitly await all fibers spawned in the generateReport
function, you get all the data you need, any extra spawned fibers should
not interest you for the purpose of the logic of generateReport.
>
In this specific code, it only awaits the tasks it has launched itself.
So, if anot
>
> As I write more code examples, I'm starting to get annoyed by the verbosity
> of the `spawn in $scope` construct—especially in situations where all spawns
> need to happen within the same context.
>
> At the same time, in 80% of cases, it turns out that explicitly defining
> `$scope` is th
On Thu, Mar 20, 2025, at 6:02 PM, Daniel Scherzer wrote:
> On Thu, Mar 20, 2025 at 4:00 PM Larry Garfield wrote:
>> I have a use case for this in Serde, so would be in favor.
>>
>> We should not block this kind of improvement on the hope of generics. Worst
>> case, we have this plus generics so
On 2025-03-20 18:09, Gina P. Banyard wrote:
And another user [2] was basically suggesting my previous solution of
adding support for type classes/runtime implementation of interfaces.
Hey,
There are two ideas -- the `$object implements Iface` that you suggested
and the `SomeClass implements
Contributing to php-src with features and bug fixes,
https://github.com/DanielEScherzer
Hi internals.
On Fri, Mar 21, 2025 at 3:11 PM Daniel Scherzer
wrote:
> Contributing to php-src with features and bug fixes,
> https://github.com/DanielEScherzer
Since there wasn't much space in the form field to fill out the details,
I've been contributing to various parts of the code base, mo
Hi
Am 2025-03-20 21:12, schrieb Daniel Scherzer:
I recently found out that constructor property promotion cannot be
used
for final properties. I propose that it become allowed. Thoughts?
Would
this need an RFC, or is this minor enough to be acceptable with just a
mailing list discussion?
Gi
On Thursday, 20 March 2025 at 16:57, Larry Garfield
wrote:
> On Thu, Mar 20, 2025, at 11:24 AM, Gina P. Banyard wrote:
>
> > As the person that had the initial discussion in R11 with Jordan [1]
> > never as a parameter type for an interface actually is not the solution
> > for "poor man generic
On Fri, Mar 21, 2025 at 5:20 PM Daniel Scherzer
wrote:
> On Fri, Mar 21, 2025 at 4:07 AM Tim Düsterhus wrote:
>
>> Can you clarify if the following would result in constructor property
>> promotion or not:
>>
>> class Foo {
>> public function __construct(
>> final stri
Hi,
The voting has ended.
The RFC was accepted unanimously with 28 (Yes) to 0 (No) votes. Thank
you for your participation.
Kind regards,
Arnaud
On Wed, Mar 5, 2025 at 10:50 AM Arnaud Le Blanc wrote:
>
> Hi,
>
> I just started the vote on the "Add get_error_handler(),
> get_exception_handler()
On Fri, Mar 21, 2025 at 4:07 AM Tim Düsterhus wrote:
> Can you clarify if the following would result in constructor property
> promotion or not:
>
> class Foo {
> public function __construct(
> final string $bar,
> ) { }
> }
>
> Best regards
> Tim Düsterhu
Good day, everyone.
As I write more code examples, I'm starting to get annoyed by the verbosity
of the `spawn in $scope` construct—especially in situations where all
spawns need to happen within the same context.
At the same time, in 80% of cases, it turns out that explicitly defining
`$scope` is
Hi
Am 2025-03-20 17:00, schrieb Gina P. Banyard:
And again, ValueErrors are only ever added when it *easy* to check if
the condition is satisfied, and it very clearly points to a programming
error.
I still find it baffling that telling someone that the code they wrote,
even if it is decades
On Fri, Mar 21, 2025 at 9:45 AM Alexandru Pătrănescu
wrote:
>
> On Fri, Mar 21, 2025 at 5:20 PM Daniel Scherzer <
> daniel.e.scher...@gmail.com> wrote:
>
>> On Fri, Mar 21, 2025 at 4:07 AM Tim Düsterhus wrote:
>>
>>> Can you clarify if the following would result in constructor property
>>> promo
19 matches
Mail list logo
