Feature: Psalm pseudo-type for instantiable-object

[boesing]

Hey there,

not sure if thats already possible but is there a way to provide something like this?

https://psalm.dev/r/16e0076766

Foo::class is the Interface and thus matches the requirements of the template. But it wont be instantiable because its the interface and thus leads to runtime errors.

What I want to have is something like:

/**
 * @template T of instantiable<Foo>
 */

So instantiable would match for class names which provide either final __construct or anything else which is already verified by UnsafeInstantiation.

Is this something which could be achieved?

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/16e0076766

<?php

interface Foo
{
}

/**
 * @template T of Foo
 */
final class Bar
{
    /**
     * @psalm-var class-string<T>
     */
    private string $bar;
    
    /**
     * @psalm-param class-string<T> $bar
     */
    public function __construct(string $bar)
    {
        $this->bar = $bar;
    }
    
    /**
     * @psalm-return T
     */
    public function createInstance(): object
    {
        $className = $this->bar;
    	return new $className;
    }
}

$factory = new Bar(Foo::class);
$factory->createInstance();

Psalm output (using commit e93b37a):

No issues!

[weirdan]

This actually looks like a bug to me. Not only because we don't know whether the class-string is instantiable, but also because constructor signature is unknown. Even if it's instantiable, it may have required arguments and would still fail at runtime.

[muglug]

Yeah, in retrospect making interface names pass a class-string check was a mistake. I think that could be a major-version change.

[muglug]

actually it probably doesn't need to be a major-version change

[muglug]

This is quite a big refactor, I'll have a look at it this week

[muglug]

Actually this is more complex. I’m afraid introducing the change before a major version would induce gnashing of teeth.

I foresee this change happening in two steps: the first very minor step makes interface-string<X> a synonym for class-string<X>. We should ask library authors to add interface-string<Foo> wherever interface strings are acceptable (e.g in templates assertions) for forward-compatibility.

This will help prepare for the next step, which would happen in a major version change, changing the meaning of class-string to mean only classes.

[boesing]

Sounds reasonable and I'd be fine with that.

Shall we move this to a dedicated issue instead? This issue was initially meant to be a feature request which tells psalm that only classes are accepted which are safely instantiable without any __construct arguments.

So one can simply do new $className without being afraid that it crashes.

But I see the pitfalls, so maybe keeping it to track (even for me) so this can be probably achieved later on. But I'd be fine with closing this as wont do. But to have a clear issue ticket regarding the class-string, interface-string problematic would probably be more clear? What do you think?