Can I ask why you don't also support other types that can be cast to a string? e.g. everything but arrays and object that don't have __toString declared?

Can I ask why you don't also support other types that can be cast to a string? e.g. everything but arrays and object that don't have __toString declared?

I'm sorry I totally miss your question. There is no such thing as "supporting other types".

@ntzm (array), (int), (float) and (bool) casts do not go through magic methods: there has been a separate discussion about that at https://externals.io/message/105589

On purpose also, for BC, classes that implement __toString aren't required to declare the interface.
Such classes wouldn't pass the above union type, but that's expected, as that's the semantics of the language.

Is there any reason to keep the magic method __toString in new interface then?

Is there any reason to keep the magic method __toString in new interface then?

of course there is: we want to be sure, from a type pov, that the object implements the casting magic method.

But for example JsonSerializable does not require magic method.

Is there any reason to keep the magic method __toString in new interface then?
But for example JsonSerializable does not require magic method.

I think I don't understand your question. I have a few ideas about what you may mean but can't decide which one is the good one. Can you give examples of what you mean? Or more details, please?

Sure, I mean something like

interface Stringable
{
   function toString(): string;
}

seems this also solves the issue with return type and BC.

Is there an RFC for this. Maybe pose the two options for a vote, with three choices. No interface, option one, option two?

@GrahamCampbell it's way too early to think about voting options. There has been very little discussion on the matter, and there has been none on php-internals, which is still the only official way AFAIK.

Just as a heads up, I rebased and force pushed.

Regarding the automatic implementation of Stringable, I initially thought we could simply add this at the very end of inheritance ... but then I realized that this automatic implementation could be relevant for variance checks:

class Foo {
    public function test(): Stringable {}
}
class Bar extends Foo {
    public function test(): Bar {}
    public function __toString() {}
}

Which would be legal if Bar automatically implements Stringable. To allow that, we need to add it as a proper interface during initial compilation.

Thanks for the heads up.

we need to add it as a proper interface during initial compilation.

how do we achieve this? in zend_compile.c? Did you give it a try?

@nicolas-grekas I pushed a new commit that should do it for user classes.

Great, thank you! I'm going to update the RFC then.
About extensions, we're OK to let them add the interface explicitly, isn't it?

PR rebased to fix some conflicts reported by GitHub. RFC updated to mention that the interface is added automatically once __toString is found.

Vote is now open btw: https://wiki.php.net/rfc/stringable

@nikic Now that the RFC has been accepted, would you mind merging this PR, please? (or someone else with merge right?) Or do I need to do anything else before?

@nicolas-grekas I granted you php-src karma so you can merge it yourself[1], see the wiki here[2] for merging from Github.

It should take about 15min or so tops for these new karma rights to syncronize.

[1] http://svn.php.net/viewvc?view=revision&revision=349278
[2] https://wiki.php.net/vcs/gitworkflow

Thanks @KalleZ. Thank you everyone for the feedback here!