Is it planned to have more flexible type inference from PHPdoc ?

[pounard]

For example, let's see the following methods:

class Foo
{
     public function hello() { echo "Hello !"; };
}

class Collection
{
    /** @var Foo[] */
    private array $data = [];
}

Most of the time, if I write somewhere in a method:

foreach ($this->data as $foo) {
    $foo->hello(); // Type inference here does not work (no auto-completion)
}

Type inference on foreach'ed $foo variable will not work (except in the case I do explicitely affect them in another method, see issue #74).

I'd expect PDT to infer objects on which I'm iterating with the Foo class.

Moreover, because PHP lacks generics, we most often emulate them by having some powered-up PHPdoc, at least it helps tools such as psalm, phpstan or simply users to know what they are doing. I'd love to know if you planned to support PHPdoc type inference using constructs such as:

• array<string, Foo>,
• Foo[],
• list<Foo>,
• ...

[zulus]

I'm not sure where is a problem. $this->data works fine, example in collection:

class Collection
{

    /** @var Foo[] */
    private array $data = [];

    public function test() {
        foreach ($this->data as $foo) {
            $foo->| //<-- cursor here
        }
    }
}

But to be honest, PHPDoc tags not always have correct precedence. PDT sometimes use type hint, sometimes just loose information during inferencing :/

I waited for PSR-5/PSR-19 and clear PHPDoc definition. There are also Psalm tags, used for example by most symfony libs.

Currently, until I finish fresh PHP model (without DLTK garbage) I haven't plan for bigger changes in this area. New model is required to clearly implement for example PHP 8 union types (current PDT implementation on PHPDoc level is horrible).

[pounard]

I'm not sure where is a problem. $this->data works fine, example in collection:

On my setup, it doesn't, or it does, but not always. It's more or less the same behaviour as #74 it only works when at least one value was explicitly assigned in the same class. This means that when I work with immutable objects whose properties are constructor injected, I don't have the auto-completion nor code navigation working.

[pounard]

Currently, until I finish fresh PHP model (without DLTK garbage) I haven't plan for bigger changes in this area. New model is required to clearly implement for example PHP 8 union types

Oh nice, so you're working in a new PHP model inside, I'll be patient and wait then. Thanks for taking time to answer.

I'll leave it to you to close this issue or not, thanks again.