Thank you so much @nikic for giving this a try.

For the record, here is some real word situation where this would be super useful:
symfony/symfony#42714

I can see some usages where it makes sense to enforce the implementations return the same object.
It would be also useful if at some point we would be able to enforce returning a new object, like we need for PSR-7: and we could have something like static & !$this or even static - $this or static ^ $this.
Also, I'm not sure if this should be used instead of $this. But I'll wait for you to open the topic on the mailing list for more feedback.

@drealecs I don't think PSR-7 should defined its return type as static & !$this. If the request changed is a no-op on the value, it is totally fine to return $this as this does not break immutability.

Thank you @nikic and @nicolas-grekas for working on this. We've already achieved a lot with the static return type. I however do see the value in being able to distinguish withers from fluent interfaces. Being able to express this difference through the type system would be good improvement, imho.

Also, I'm not sure if this should be used instead of $this.

Seeing a dollar character in a type declaration also felt a bit odd to me at first. But I must admit that : $this feels intuitive. I know exactly what to expect from this declaration.

Using this instead would have the slight disadvantage that this would need to become a reserved keyword. Currently, it is legal to name a class this: https://3v4l.org/TuCoC

While in a pure type system this should not exist, it definitely mirrors the reality.

I also agree that it should be $this as we return a variable $this, not a type - the type of $this is static.

Hi :),

But I must admit that : $this feels intuitive.

We should not forget

method($this $param) {}

Sawing this, im wondering is reserving this too late?

edit: i've also shared this snippet with @nicolas-grekas, which is why i think this idea is generally fine (it already exists in practice in PHP, having real language semantics is for the better :))

We should not forget

method($this $param) {}

this won't happen. This type is only allowed in return types (just like static)

Sawing this, im wondering is reserving this too late?

edit: i've also shared this snippet with @nicolas-grekas, which is why i think this idea is generally fine (it already exists in practice in PHP, having real language semantics is for the better :))

I don't understand what you mean here. Typescript uses this as the type, but JS (and TS) also uses this as the variable name for the instance.

Sorry, i did not saw Cannot use $this as param type while scanning. That, eh, makes sense.

@stof i simply mean the concept seems legit in a typesystem. For PHP, im wondering if this would be preferred over $this.

This seems like an issue for static analysis and not for the language. On the one hand, this modification introduces a small changes, but on the other hand we introduce unnatural keyword for the PHP language and make solve an issue that can be solved by other ways.

It not seems there is an issue that cannot be solved due to lack of $this return type (excepts the problems with need of annoying PhpDocs).

Forgive my ignorance .. :} but isnt the language already staticly analyzing to a certain degree?

To me this is about supporting both flavors, that is tag(string $name): this vs . tag(string ...$name): void

Since a return type of $this has only one possible result, maybe worthwhile having functions with $this return type automatically return $this without a return statement at the end of the function? Would reduce boilerplate for fluent methods ...

Closing for now as it doesn't seem likely this will go anywhere.

The $this return type would be great.
I just saw the RFC https://wiki.php.net/rfc/this_return_type was inactive.

What was missing in order to going to vote ?