On Thu, Jan 22, 2026, at 10:26 AM, Rowan Tommins [IMSoP] wrote:
> On 22/01/2026 16:08, Tim Düsterhus wrote:
>> Yes, it certainly requires some getting used to it. It's the best we
>> could come up with, but if there are any better suggestions, we're
>> open to hearing those. I'd like to note the “Rejected Features”
>> section, since it lists some non-workable alternatives we considered.
>
>
> Looking at this:
>
> > PHP itself already has "ALGOL-style" declarations, for "const",
> "global", and "static".
>
> I'm reminded of placeholders in PostgreSQL; the type is needed to choose
> overloaded functions and operators, so this doesn't compile (without
> extra metadata):
>
> Select do_something(?) as result
>
> Instead, you can insert a dummy cast to indicate the type:
>
> Select do_something(?::int) as result
>
>
> The PHP equivalent would be something like this:
>
> $f = (DateTimeImmutable)?->format('c');
>
> Or, slightly more readable but less consistent with casts:
>
> $f = (? as DateTimeImmutable)->format('c');
>
>
> That doesn't solve the second part of the problem though:
>
> > It would also not allow to reorder the parameters in the resulting
> Closure, which is an explicit feature of Partial Function Application.
>
>
> I thought I'd throw it out there anyway in case it stimulates any other
> ideas.
More spitballing on my previous reply:
class Test {
public function stuff(int $a) {}
}
(Test)?->stuff(?);
Translates to:
fn(Test $__this, int $a) => $__this->stuff($a);
But if there's no partialing on the method side, it could get abbreviated to:
(?)->stuff(4);
Translates to:
fn(object $__this) => $__this->stuff(4);
Because we don't need to know the type at compile time, and a method-not-found
error would still happen at runtime anyway if necessary. That would then be a
lot easier to write in cases where you're just dropping a $this->stuff() call
into a pipe chain but want to receive $this.
I'm not sure if that would also allow for reading properties with the same
syntax?
--Larry Garfield